CVE-2026-31872: 
JavaScript vulnerability analysis and mitigation

CVE-2026-31872 is a protected fields bypass vulnerability in Parse Server, an open-source Node.js backend platform, that allows unauthenticated remote attackers to enumerate values of fields protected by class-level permissions (CLP). The vulnerability was disclosed on March 10, 2026, and affects Parse Server versions prior to 8.6.32 and versions 9.0.0 through 9.6.0-alpha.5. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Parse Server Advisory).

The root cause is improper access control (CWE-284) in how Parse Server evaluates query WHERE clause keys and sort parameters against protectedFields CLP configurations. When a field such as secretObj is marked as protected, the server failed to strip dot-notation sub-paths (e.g., secretObj.apiKey) before checking against the protected fields list, allowing the sub-field reference to bypass the restriction entirely. This flaw affects both MongoDB and PostgreSQL database backends. The fix, applied in the patched releases, extracts the root field name from any dot-notation path before performing the protected fields check, so a query on secretObj.apiKey is now correctly blocked when secretObj is protected (Parse Server Advisory, GitHub Advisory).

Successful exploitation allows an unauthenticated attacker to conduct a binary oracle attack — iteratively querying or sorting by sub-fields of a protected object field to infer its values character by character or through conditional responses. This results in a high confidentiality impact, as sensitive data stored in protected fields (e.g., API keys, tokens, or personal information) can be enumerated without authorization. There is no integrity or availability impact, and the vulnerability is scoped to the vulnerable Parse Server instance itself without lateral movement to subsequent systems (Parse Server Advisory, GitHub Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of active in-the-wild exploitation at this time (GitHub Advisory). The vulnerability requires no authentication, no user interaction, and no special privileges, making it trivially exploitable against any exposed Parse Server instance running a vulnerable version. The EPSS score is approximately 0.049% (16th percentile), indicating a currently low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify internet-facing Parse Server instances (e.g., via Shodan, Censys, or application fingerprinting) running versions prior to 8.6.32 or between 9.0.0 and 9.6.0-alpha.5.
2. Identify protected fields: Review the application's schema or infer protected field names through normal API interactions to determine which object fields are configured as protectedFields in the CLP.
3. Craft dot-notation query: Construct a Parse API query using dot-notation to reference a sub-field of a protected field — for example, send a WHERE clause filtering on secretObj.apiKey with a specific value guess (e.g., {"where": {"secretObj.apiKey": {"$gt": "m"}}}).
4. Binary oracle enumeration: Observe whether the query returns results or not. A result set indicates the condition is true; an empty result indicates false. Repeat with different values and comparison operators to progressively narrow down the exact value of the protected sub-field.
5. Exfiltrate sensitive data: After enumerating the protected field value (e.g., an API key or secret token), use the recovered data for further unauthorized access or lateral movement within the application ecosystem (Parse Server Advisory, GitHub Advisory).

• Network: Unusual volume of Parse API query requests (HTTP POST to /parse/classes/<ClassName>) from a single IP or user agent, particularly with repetitive WHERE clause patterns targeting the same field with incrementally varying values.
• Logs: Parse Server access logs showing repeated queries containing dot-notation field references (e.g., secretObj.apiKey, protectedField.subfield) in WHERE or sort parameters, especially with comparison operators like $gt, $lt, or $regex.
• Logs: High frequency of queries returning empty result sets from the same source, consistent with binary oracle enumeration behavior.
• Application: Queries referencing sub-fields of fields that are configured as protectedFields in the class-level permissions schema.

Parse Server has released patched versions addressing this vulnerability: 8.6.32 for the stable branch and 9.6.0-alpha.6 for the alpha branch, both released on March 10, 2026. There are no known workarounds — upgrading to a patched version is the only remediation. Administrators should also audit their protectedFields CLP configurations and monitor query logs for suspicious dot-notation access patterns as a defense-in-depth measure (Parse Server 8.6.32 Release, Parse Server 9.6.0-alpha.6 Release).