Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
8.7
CVE-2026-47138: Parse Server: Denial of Service via Client Header Backtracking
GHSA-38m6-82c8-4xfm
CVE-2026-47138
Summary
An attacker can send a specially crafted request that causes Parse Server to use up a lot of CPU, making it slow or unresponsive. This affects Parse Server deployments that use the default configuration. To fix this, a patch is available that removes the vulnerable code. Alternatively, you can use a reverse proxy or web application firewall to block or limit the malicious requests.
What to do
- Update parseadmin parse-server to version 9.9.1-alpha.1.
- Update parseadmin parse-server to version 8.6.77.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| npm | parseadmin | parse-server |
>= 9.0.0, < 9.9.1-alpha.1 < 8.6.77 Fix: upgrade to 9.9.1-alpha.1
|
Original title
Parse Server: Pre-authentication denial of service via client version header regex backtracking
Original description
### Impact
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.
### Patches
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.
### 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.
### Patches
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.
### 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.
ghsa CVSS4.0
8.7
Vulnerability type
CWE-1333
Inefficient Regular Expression Complexity (ReDoS)
Published: 23 May 2026 · Updated: 23 May 2026 · First seen: 23 May 2026