Skip to content

GHSA-38m6-82c8-4xfm BIT-parse-2026-47138 CVE-2026-47138

Parse Server: Pre-authentication denial of service via client version header regex backtracking

High npm
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.58%
Chance of exploitation in the next 30 days. Higher than 47.95% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-1333 Inefficient Regular Expression Complexity
Fix
9.9.1-alpha.1
Upgrade parse-server to this version or later

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.

Affected versions

npm

PackageVulnerableFixed in
parse-server
>= 9.0.0, < 9.9.1-alpha.1
9.9.1-alpha.1
parse-server
< 8.6.77
8.6.77

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

parse-server npm → 9.9.1-alpha.1

npm
npm install parse-server@9.9.1-alpha.1
yarn
yarn add parse-server@9.9.1-alpha.1
pnpm
pnpm add parse-server@9.9.1-alpha.1

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
None
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-1333: Inefficient Regular Expression Complexity

The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.

How to prevent it
  • Architecture and Design: Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
  • System Configuration: Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
  • Implementation: Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
  • Implementation: Limit the length of the input that the regular expression will process.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-r899-h629-j84r
Parse Server vulnerable to stored XSS via malformed Content-Type bypassing file upload extension blocklist
Low Also affects parse-server
GHSA-97pr-9hgg-3p8r
parse-server: LiveQuery discloses object data to a subscriber across an ACL read-access change
Low Also affects parse-server
GHSA-v8x7-r927-cc93
parse-server: Stored XSS via non-standard file extension bypassing file upload extension blocklist
Low Also affects parse-server
GHSA-cgxm-vr2f-6fj8
parse-server: Denial of service via exponential-time processing of deeply nested query operators
High Also affects parse-server
GHSA-wmwx-jr2p-4j4r
parse-server: Relation `$relatedTo` query bypasses `protectedFields` and owning-object ACL
Medium Also affects parse-server
GHSA-75v4-m273-5j49
parse-server: Endpoints `/login` and `/verifyPassword` disclose MFA secrets and protected fields when `_User` get is denied
Medium Also affects parse-server
GHSA-7wqv-xjf3-x35v
parse-server: Stored XSS via trailing-dot filename bypassing file upload extension blocklist
Low Also affects parse-server
GHSA-p84r-h6rx-f2xr
parse-server: Server option routeAllowList is bypassable through batch sub-requests
Medium Also affects parse-server
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor