GHSA-p84r-h6rx-f2xr
parse-server: Server option routeAllowList is bypassable through batch sub-requests
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
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.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-p84r-h6rx-f2xr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-p84r-h6rx-f2xr is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-p84r-h6rx-f2xr. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-p84r-h6rx-f2xr in your dependencies?
O3 detects GHSA-p84r-h6rx-f2xr across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.