GHSA-q6wc-xx4m-92fj: Improper Authorization in PowerSync Service Sync Streams

PowerSync is a framework designed to synchronize data between a central PostgreSQL database and local SQLite databases on client devices. The service relies on defined 'sync rules' to determine which rows in the central database should be replicated to a specific authenticated user. These rules typically take the form of SQL queries with WHERE clauses that filter data based on the user's identity.

In version 1.20.0, PowerSync introduced a new sync stream architecture, enabled via config.edition: 3. This update contained a logic flaw in the query parser responsible for applying security filters. Specifically, the engine failed to apply 'gating' filters—conditions that determine whether a user should access a table at all—when those filters relied on subqueries. While direct row-level partitioning (e.g., user_id = auth.user_id()) functioned correctly, broad access controls were silently dropped from the execution plan.

This vulnerability manifests as an Information Disclosure (Improper Authorization). An authenticated user connecting to the service effectively receives a full table dump for affected queries, bypassing the intended access control logic defined by the developer.

The root cause lies in the differentiation between partitioning filters and gating filters within the config.edition: 3 execution engine. Partitioning filters are used to slice data (e.g., returning only rows owned by the user), whereas gating filters often act as boolean switches (e.g., allowing access to a table only if the user belongs to a specific group).

The vulnerability specifically affects non-partitioning subqueries. When the query planner encountered a WHERE clause containing a subquery that did not directly correlate a row column to the user ID but instead checked a global condition, the filter was omitted. The engine erroneously treated these complex predicates as non-binding or resolved them to TRUE for all users.

For example, a rule intended to restrict a table to administrators often uses a subquery to check the user's role. Because this subquery does not partition the data by row ID but rather gates the entire dataset, the flawed logic in 1.20.0 discarded the check. Consequently, the query executed without the restriction, synchronizing the entire dataset to any user with a valid session.

The following SQL patterns demonstrate the specific failure modes observed in version 1.20.0. The core issue is the semantic handling of subqueries in the WHERE clause.

1. Admin Gating (Vulnerable)

In this scenario, the developer intends to sync the sensitive_table only if the requesting user is present in the admins table. The vulnerability causes the WHERE clause to be ignored, resulting in a SELECT * FROM sensitive_table for all users.

-- Vulnerable Query Pattern
SELECT * 
FROM sensitive_table 
WHERE auth.user_id() IN (
    SELECT user_id 
    FROM admins
);

2. Table-List Gating (Vulnerable)

A common pattern involves checking a permissions table to see if a specific resource is allowed. This logic also fails because it relies on a subquery that does not partition the target table directly.

-- Vulnerable Query Pattern
SELECT * 
FROM sensitive_table 
WHERE 'sensitive_table' IN (
    SELECT table_name 
    FROM synced_table_permissions 
    WHERE "user" = auth.user_id()
);

3. Partitioning (Not Affected)

Standard row-level security patterns that directly compare columns remain effective. The engine correctly processes these because they are identified as partitioning keys.

-- Secure Query Pattern (Unaffected)
SELECT * 
FROM sensitive_table 
WHERE owner_id = auth.user_id();

> [!NOTE] > The vulnerability is specific to config.edition: 3. Configurations using the older config.edition: 2 or standard bucket definitions are not impacted.

Exploitation of this vulnerability requires no specialized tools or complex attack chains. It is an architectural failure that occurs automatically during the normal synchronization process.

Prerequisites

1. Authentication: The attacker must possess a valid, authenticated user session for the PowerSync Service.
2. Configuration: The target service must be running version 1.20.0 with config.edition: 3 enabled.
3. Vulnerable Rules: The application must define sync rules using subqueries for access control (gating) rather than row-level partitioning.

Attack Path

1. An attacker authenticates to the application as a standard, low-privilege user.
2. The client application (PowerSync SDK) initiates a sync connection to the backend service.
3. The backend evaluates the sync rules. Due to the vulnerability, the WHERE clause restricting access to sensitive tables (e.g., admin_audit_logs) is ignored.
4. The service streams the complete contents of the restricted table to the attacker's local SQLite database.
5. The attacker inspects their local database to access unauthorized information.

The primary impact is Confidentiality Loss. The severity depends on the nature of the data protected by the affected sync rules. In many applications, these 'gating' queries are used for high-privileged data, such as:

• Administrative Logs: Visibility into system actions and user behaviors.
• Configuration Secrets: System-wide settings intended only for admin viewing.
• Tenant Data: In multi-tenant systems where subqueries determine tenant isolation (though direct partitioning is more common here), cross-tenant leakage could occur.

CVSS v3.1 Analysis:

• Vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (Score: 6.5)
• Attack Vector (Network): Exploitable remotely.
• Privileges Required (Low): Any authenticated user can trigger the leak.
• Confidentiality (High): Total disclosure of the affected table's data.
• Integrity/Availability (None): The vulnerability does not allow modification of data or denial of service.