Listen to this Post
Parse Server versions prior to 8.6.35 and 9.6.0-alpha.9 contain a vulnerability in the LiveQuery feature . The issue arises because the server fails to validate a subscription’s `WHERE` clause against a class’s `protectedFields` . An attacker can create a LiveQuery subscription that includes a condition referencing a protected field, using operators like `$regex` or dot-notation . By observing whether LiveQuery events are triggered, the attacker creates a boolean oracle to infer the values of these protected fields . This bypasses the intended access control, leaking sensitive information that should not be exposed to the client . The fix now applies the same validation to LiveQuery subscriptions that exists for REST API queries, rejecting any that reference protected fields .
dailycve form:
Platform: Parse Server
Version: <8.6.35, <9.6.0-alpha.9
Vulnerability :Protected Fields Bypass
Severity: Medium (CVSS:6.9)
date: March 11, 2026
Prediction: Patched versions released
What Undercode Say:
Analytics:
This vulnerability (CVE-2026-32098) is distinct from previous LiveQuery issues like CVE-2021-41109, which leaked session tokens directly . The current flaw is an information disclosure via a side-channel, specifically a boolean oracle. Its CVSS v4.0 score of 6.9 reflects a low complexity attack with no privileges required . The exploitability is high, as it only requires network access. However, the impact is limited to low confidentiality, with no integrity or availability impact . The vulnerability window spans multiple major versions, indicating a long-standing oversight in the LiveQuery protocol’s alignment with Class-Level Permissions (CLP).
Example: Checking your Parse Server version npm list parse-server Example: Updating to a patched version npm install [email protected] or for the 9.x branch (alpha) npm install [email protected]
How Exploit:
An attacker would first identify a class with both LiveQuery enabled and `protectedFields` set in its CLP. They would then craft a subscription request with a `WHERE` clause designed to test the value of a protected field. For example, to test if a field named `ssn` starts with a specific digit, they might use a regex. If the subscription is created successfully and they receive events for objects matching that criteria, they can infer the presence of that value, thereby leaking the protected data bit by bit.
// Example of a malicious subscription query (Conceptual)
const query = new Parse.Query('SensitiveClass');
// Attempting to guess the first digit of a protected 'ssn' field
query.matches('ssn', '^5', 'i');
const subscription = await query.subscribe();
subscription.on('create', (object) => {
// If this event fires, the attacker knows an object with an 'ssn' starting with '5' was created.
console.log('Object matched the secret criteria!');
});
Protection from this CVE:
Update Parse Server to version 8.6.35 or 9.6.0-alpha.9 (or later stable releases) immediately . As a workaround, administrators should disable LiveQuery for any class that utilizes `protectedFields` in its Class-Level Permissions . Alternatively, remove `protectedFields` configurations from classes that require LiveQuery functionality until the patch can be applied .
Impact:
Successful exploitation allows an attacker to systematically infer the contents of fields that were intended to be protected and hidden from clients. This compromises the confidentiality of sensitive data stored in these fields. The attack does not modify or delete data, but the information leak can be a precursor to more severe attacks, such as account takeover if the protected fields contain credentials or personal data.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
