CVE-2026-47138

Workarounds

Deploy a reverse proxy or WAF in front of Parse Server that strips or strictly size-limits the X-Parse-Client-Version header AND the _ClientVersion field in JSON request bodies on every /parse/* route before forwarding to the server. A header-size cap alone is insufficient: the body-field variant requires inspection of JSON content. Upgrading to the patched version is the recommended remediation.

An unauthenticated attacker who knows a publicly-known Parse Application ID can submit a single HTTP request whose client SDK version field contains adversarial input that triggers polynomial backtracking in a request-header parser. The parsing runs before session authentication and before rate limiting on every /parse/* request, so the request consumes seconds to minutes of synchronous CPU on a Node.js worker before any access control evaluates it. A small number of concurrent requests can saturate a worker; a single large request via the body-field variant can pin a worker for minutes. Production deployments running the default configuration are affected.

A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use. Typical impact: denial of service when input is crafted to trigger backtracking.

Kodem intelligence

The client SDK version capture and parsing have been removed entirely. The Parse JS SDK compatibility table defines a strict version-pinned contract between Parse Server and the Parse JS SDK; server-side adaptation to client SDK version is an obsolete pattern that contradicts that contract. The vulnerable parser, the clientSDK parameter that threaded its output through routers, and the legacy code path it gated are all removed. The X-Parse-Client-Version header and _ClientVersion JSON body field are now silently ignored on every request; supported Parse SDKs are unaffected.

1. What is CVE-2026-47138? CVE-2026-47138 is a high-severity inefficient regular expression (ReDoS) vulnerability in parse-server (npm), affecting versions >= 9.0.0, < 9.9.1-alpha.1. It is fixed in 9.9.1-alpha.1, 8.6.77. A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use.
2. Which versions of parse-server are affected by CVE-2026-47138? parse-server (npm) versions >= 9.0.0, < 9.9.1-alpha.1 is affected.
3. Is there a fix for CVE-2026-47138? Yes. CVE-2026-47138 is fixed in 9.9.1-alpha.1, 8.6.77. Upgrade to this version or later.
4. Is CVE-2026-47138 exploitable, and should I be worried? Whether CVE-2026-47138 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-47138 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-47138?
   • Upgrade parse-server to 9.9.1-alpha.1 or later
   • Upgrade parse-server to 8.6.77 or later