Listen to this Post
The vulnerability arises from how Parse Server handles dot-notation in query `WHERE` clauses and `sort` parameters when class-level permissions (CLPs) for `protectedFields` are in effect. The `protectedFields` CLP is designed to prevent clients from reading specific fields on objects. However, the server only checked the top-level field name against the protected list. An attacker could bypass this by requesting a sub-field using dot-notation, such as `secretObj.apiKey` where `secretObj` is the protected parent. The server would see the key as a string containing a dot, fail to match it to the protected field secretObj, and return the data. This allows a binary oracle attack, where an attacker can systematically guess and enumerate the values of protected fields by observing query results or sort orders. The flaw exists in both MongoDB and PostgreSQL deployments because it is in the query parsing logic, not the database layer. The fix now extracts the root field from any dot-notated path before checking the protected fields list, blocking any query that targets a sub-document of a protected field .
DailyCVE Form:
Platform: Parse Server
Version: <8.6.32, 9.0.0-alpha.1-9.6.0-alpha.6
Vulnerability : ProtectedFields Bypass
Severity: High
Date: Mar 11, 2026
Prediction: Patch already released Mar 11
What Undercode Say:
Analytics:
The advisory was published to the GitHub Advisory Database on March 11, 2026, and subsequently published by the NVD three hours later. It was last updated 52 minutes ago, indicating active discussion and confirmation. The vulnerability affects two major version branches (<=8.x and 9.x), suggesting a wide potential impact. The fix was released simultaneously for both branches (8.6.32 and 9.6.0-alpha.6), showing a coordinated patch effort.
How Exploit:
An attacker exploits this by sending a REST API GET request with a dot-notated key in the `where` or `order` parameter.
Example of malicious query to guess a secret API key stored in a protected object
Assume 'User' class protects field 'secret', but has a sub-field 'secret.apiKey'
curl -X GET \
"http://your-parse-server.com/classes/User \
-H "X-Parse-Application-Id: YOUR_APP_ID" \
-H "X-Parse-REST-API-Key: YOUR_REST_KEY" \
--data-urlencode 'where={"secret.apiKey":{"$regex":"^A"}}'
If results are returned, the attacker knows the apiKey starts with "A"
The attacker can then brute force the value character by character using binary search logic via regex queries or sort differences.
Protection from this CVE:
- Immediate Patch: Update Parse Server to version 8.6.32 or 9.6.0-alpha.6 (or later stable releases) .
- Input Validation: While the patch fixes the logic, ensure that any custom middleware or cloud code does not reintroduce the issue by manually parsing dot-notation.
- Principle of Least Privilege: Review all `protectedFields` CLPs to ensure that sensitive data is not stored in sub-fields that could be indirectly exposed even after the patch.
Impact:
A successful exploit allows an unauthenticated or low-privileged attacker to read the contents of fields that are supposed to be protected by class-level permissions. This leads to a direct breach of data confidentiality. In cases where protected fields contain credentials, session tokens, or Personally Identifiable Information (PII), this can escalate to full account takeover or regulatory compliance violations. Because the attack is a binary oracle, it is stealthy and can be performed without triggering coarse-grained anomaly detection that looks for mass data exfiltration .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
