parse-server: Denial of service via exponential-time processing of deeply nested query operatorsGHSA-cgxm-vr2f-6fj8
Fix: parse-community/parse-server#10511GHSA-cgxm-vr2f-6fj8 is a CWE-407 vulnerability in parse-server. A fix is available for parse-server — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-cgxm-vr2f-6fj8.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
parse-servernpmDescription
Impact
Parse Server is vulnerable to denial of service. A remote attacker can send a single, small query (~1 KB) containing deeply nested query condition operators. Parse Server processes the nested structure with exponential time complexity, which blocks the Node.js event loop and makes the server unresponsive to all clients for the duration of processing. A single request can occupy the event loop for many seconds, and the request is repeatable. The issue affects the REST API and LiveQuery query handling and is reachable in the default configuration. Exploitation requires only the public application identifier; no user authentication is needed.
Patches
The internal query-traversal helper that previously re-walked nested arrays — causing exponential-time processing of nested $or/$and/$nor operators — was corrected to traverse queries in linear time. Additionally, the optional requestComplexity.queryDepth limit was generalized so that nested logical operators are counted even when wrapped inside field-level operators (e.g. $elemMatch, $not) or plain field names, closing a bypass of the limit on both the REST API and LiveQuery.
Workarounds
There is no complete configuration-only workaround on affected versions. Setting requestComplexity.queryDepth to a small positive integer reduces exposure but does not fully prevent the issue, because the limit can be bypassed by nesting the operators inside a field-level operator. Upgrading is strongly recommended.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | parse-server | ≥ 9.0.0&&< 9.9.1-alpha.12 | 9.9.1-alpha.12npm install parse-server@9.9.1-alpha.12 |
| 📦npm | parse-server | all versions | 8.6.82npm install parse-server@8.6.82 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for parse-server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update parse-server to 9.9.1-alpha.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cgxm-vr2f-6fj8 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is GHSA-cgxm-vr2f-6fj8 in your dependencies?
Find it across npm, including transitive dependencies.