Listen to this Post
The vulnerability stems from a flaw in how Parse Server scans incoming request payloads against the `requestKeywordDenylist` . This security control is designed to block specific keywords (like `$where` or $function) used in NoSQL operations to prevent injection attacks. The server’s scanning logic prematurely stops traversing the JSON object when it encounters a nested object or array. By placing a prohibited keyword after such a nested structure, an attacker can smuggle the dangerous keyword past the denylist . For example, a payload like `{“_nested”: {“a”: 1}, “$where”: “malicious code”}` would bypass the scan because the scanner exits after processing the nested `_nested` object and never checks the sibling `$where` key. Once the payload is processed, the blocked keyword is saved to the database, enabling further exploitation. This bypass can lead to prototype pollution because the malicious input can modify the properties of JavaScript object prototypes . This pollution can subsequently trigger remote code execution (RCE) through the MongoDB BSON parser . The vulnerable code resides in the `DatabaseController.js` file, where the unsafe deserialization occurs . The fix involves replacing the vulnerable recursive scanner with an iterative stack-based traversal that ensures all keys are checked . This issue affects all Parse Server deployments using versions before 4.10.19 and 5.3.2, as the `requestKeywordDenylist` is enabled by default . The vulnerability is critical as it allows unauthenticated attackers to achieve full system compromise . The primary attack vector is through Cloud Code Webhooks or Triggers .
dailycve form:
Platform: Parse Server
Version: <4.10.19, 5.0.0-5.3.1
Vulnerability : Denylist Bypass
Severity: Critical
date: Mar 7, 2026
Prediction: Patched Mar 10, 2026
What Undercode Say:
Analytics:
The vulnerability exploits a logic flaw in the recursive scanner. To test if your system is vulnerable, you can use a `curl` command to send a payload with a blocked keyword placed after a nested object. The example below attempts to use the blocked `$where` operator to inject a JavaScript sleep function, which would indicate a successful bypass if the response is delayed.
Example of a malicious payload attempting to bypass the denylist
curl -X POST \
http://your-parse-server.com/parse/classes/YourClass \
-H "X-Parse-Application-Id: YOUR_APP_ID" \
-H "Content-Type: application/json" \
-d '{
"nested": {"key": "value"},
"$where": "function() { sleep(10000); }"
}'
Exploit:
An attacker would first identify a target Parse Server endpoint. They would then craft a JSON payload containing a blocked keyword (like $where, $function, or a custom developer-defined term) placed after a benign nested object . When the server processes this, it bypasses the requestKeywordDenylist. The blocked keyword is then stored in the database . In a subsequent step, when the application performs a query that uses this stored data, the malicious BSON payload is deserialized. During deserialization, if the BSON data contains a `Code` type with a `functionString` property, the server’s `isolateEval` function will execute the arbitrary JavaScript code, granting the attacker Remote Code Execution .
Protection from this CVE:
- Immediate Patching: Upgrade Parse Server to version `8.6.12` or `9.5.1-alpha.1` or later, which contain the fix that replaces the recursive scanner with a safe iterative traversal .
- Firewall Restriction: If immediate patching is not possible, configure your firewall to restrict access to the Parse Server Cloud Code Webhooks API, allowing requests only from trusted servers .
- Input Validation: As a defense-in-depth measure, implement a `beforeSave` trigger in Cloud Code to manually validate and sanitize incoming data for all classes, stripping out any prohibited keywords that might have bypassed the denylist .
Impact:
A successful exploit allows an attacker to bypass core security controls, leading to prototype pollution . This can then be chained with other vulnerabilities, such as the MongoDB BSON parser issue, to achieve full Remote Code Execution (RCE) on the underlying server . This grants the attacker complete control over the server, including the ability to read, modify, or delete all data, and potentially pivot to other internal systems .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode

