CVE-2026-32098: Parse Server Information Disclosure Flaw

CVE-2026-32098 Overview

Parse Server, an open source backend that can be deployed to any infrastructure that can run Node.js, contains an information disclosure vulnerability in its LiveQuery subscription handling. Prior to versions 9.6.0-alpha.9 and 8.6.35, an attacker can exploit LiveQuery subscriptions to infer the values of protected fields without directly receiving them. By subscribing with a WHERE clause that references a protected field (including via dot-notation or $regex), the attacker can observe whether LiveQuery events are delivered for matching objects. This creates a boolean oracle that leaks protected field values.

Critical Impact

Attackers can bypass protectedFields security controls and infer sensitive data values through boolean oracle attacks on LiveQuery subscriptions.

Affected Products

• Parse Server versions prior to 9.6.0-alpha.9
• Parse Server versions prior to 8.6.35
• Any Parse Server deployment with both protectedFields configured in Class-Level Permissions and LiveQuery enabled

Discovery Timeline

• 2026-03-11 - CVE-2026-32098 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-32098

Vulnerability Analysis

This vulnerability is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The flaw exists in how Parse Server processes LiveQuery subscriptions that contain WHERE clause filters referencing protected fields.

Parse Server provides a protectedFields mechanism within Class-Level Permissions (CLP) to prevent certain fields from being returned in query results to unauthorized users. However, the LiveQuery system fails to properly enforce these protections when evaluating subscription filters. An attacker can craft subscription queries that reference protected fields, and by observing whether LiveQuery events are delivered, can determine if objects match their filter criteria—effectively creating a side-channel attack.

The attack vector is network-based and requires no authentication or user interaction. The vulnerability affects confidentiality by allowing unauthorized access to protected field values, though integrity and availability are not impacted.

Root Cause

The root cause is insufficient enforcement of Class-Level Permission protectedFields restrictions within the LiveQuery subscription evaluation logic. When a client subscribes to LiveQuery events with a WHERE clause, the server evaluates object changes against this filter before pushing updates. The server should reject or sanitize subscription filters that reference protected fields, but instead processes them normally, allowing attackers to infer protected values based on whether events are delivered.

Attack Vector

The attack exploits Parse Server's LiveQuery real-time subscription feature through a boolean oracle technique. An attacker subscribes to a class with protected fields configured, using carefully crafted WHERE clauses that test specific values or patterns in protected fields.

For example, an attacker could use $regex operators or exact match conditions on a protected field like socialSecurityNumber. By iterating through possible values and observing which subscriptions receive LiveQuery events when target objects are modified, the attacker can systematically extract protected field values character by character or through binary search patterns.

The attack requires the following conditions:

• Target class has protectedFields configured in Class-Level Permissions
• LiveQuery is enabled for the target class
• Attacker can establish WebSocket connections for LiveQuery subscriptions
• Objects in the target class are being created, updated, or deleted (triggering LiveQuery events)

Detection Methods for CVE-2026-32098

Indicators of Compromise

• Unusual volume of LiveQuery subscription requests from single clients or IP addresses
• LiveQuery subscriptions containing WHERE clauses with $regex operators targeting sensitive field names
• Patterns of rapid subscription/unsubscription cycles that may indicate enumeration attempts
• WebSocket connections making multiple subscription requests with incrementally varying filter conditions

Detection Strategies

• Monitor Parse Server logs for LiveQuery subscription requests that reference known protected field names
• Implement rate limiting on LiveQuery subscription creation to slow enumeration attacks
• Audit Class-Level Permissions configurations to identify classes with both protectedFields and LiveQuery enabled
• Deploy network monitoring to detect high-frequency WebSocket subscription patterns

Monitoring Recommendations

• Enable verbose logging for LiveQuery subscription events including the full WHERE clause
• Set up alerts for subscription queries that include pattern-matching operators ($regex, $in) on protected fields
• Monitor for abnormal LiveQuery connection patterns such as many short-lived subscriptions
• Review WebSocket connection metadata for suspicious client behavior patterns

How to Mitigate CVE-2026-32098

Immediate Actions Required

• Upgrade Parse Server to version 9.6.0-alpha.9 or 8.6.35 immediately
• Audit all classes to identify those with both protectedFields and LiveQuery enabled
• Consider temporarily disabling LiveQuery for classes containing highly sensitive protected fields until patches are applied
• Review recent LiveQuery subscription logs for signs of exploitation

Patch Information

Parse Server has released security patches addressing this vulnerability. Organizations should upgrade to the fixed versions as soon as possible:

• Version 8.6.35: Stable release with the security fix - GitHub Parse Server Release 8.6.35
• Version 9.6.0-alpha.9: Alpha release with the security fix - GitHub Parse Server Release 9.6.0-alpha.9

For complete details on the vulnerability and remediation, see the GitHub Security Advisory GHSA-j7mm-f4rv-6q6q.

Workarounds

• Disable LiveQuery for classes that have protectedFields configured until the patch can be applied
• Implement application-level filtering to reject LiveQuery subscriptions that reference protected field names
• Use network-level controls to restrict LiveQuery WebSocket access to trusted clients only
• Consider moving highly sensitive data to separate classes without LiveQuery enabled