CVE-2026-50008 — parse-server
Fix: parse-community/parse-server#10482CVE-2026-50008 is a CWE-863 vulnerability in parse-server. A fix is available for parse-server — see the affected versions and patch details below.
Parse Server: Server option routeAllowList is bypassable through batch sub-requests
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 CVE-2026-50008.
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
The routeAllowList server option restricts external client access to a configured list of REST API routes. The check is only enforced as Express middleware against the outer HTTP request URL, so the /batch handler dispatches each sub-request to the internal router without re-running the allow-list check. An external caller whose outer route matches batch can issue batch sub-requests to any REST API route that the operator omitted from the allow-list.
Authentication, ACL, CLP, and other inner-route authorization controls still apply — only the operator-configured route firewall is bypassed.
Patches
routeAllowList is now re-enforced for each batch sub-request inside the batch handler before dispatch, mirroring the existing per-sub-request rate-limit enforcement pattern. The path-normalization and regex-match logic was extracted into a shared helper used by both the outer middleware and the batch handler. Master and maintenance keys bypass the per-sub-request check on the same terms as the outer middleware.
Workarounds
Operators who use routeAllowList and have allowlisted batch can mitigate without upgrading by explicitly including every inner route they intend to allow via batch in the allow-list (for example, routeAllowList: ['batch', 'classes/Public.*', 'functions/allowedFunction']). This approach makes those inner routes reachable as direct REST requests as well, so it is broader than the post-patch behavior, but it eliminates the bypass.
Operators who do not configure routeAllowList are not affected. Parse Server v8 LTS is not affected because routeAllowList was introduced in v9.8.0.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | parse-server | ≥ 9.8.0&&< 9.9.1-alpha.3 | 9.9.1-alpha.3npm install parse-server@9.9.1-alpha.3 |
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.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-50008 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is CVE-2026-50008 in your dependencies?
Find it across npm, including transitive dependencies.