CVE-2026-34532 is a critical (CVSS 9.1) access control bypass in Parse Server. Adding a suffix to a Cloud Function name in the URL skips its validator, so unauthenticated callers can run protected functions. Fixed versions are 8.6.67 and 9.7.0-alpha.11. Arrow function handlers are not affected.
What's affected
The project's advisory (GHSA-vpj2-qq7w-5qq6) lists the npm package parse-server below 8.6.67 on the 8.x line, and from 9.0.0 up to before 9.7.0-alpha.11 on the 9.x line. Patched versions are 8.6.67 and 9.7.0-alpha.11.
The condition is narrow. The handler must be declared with the function keyword and its validator must be a plain object or an arrow function. In that case, the code that finds the handler walks the function's own prototype chain, while the code that finds the validator does not, so validator checks are skipped. Validators such as requireUser, requireMaster or custom logic then do not run.
The advisory's workaround is to use arrow functions for Cloud Function handlers, which have no prototype property.
How to check if you're exposed
npm ls parse-server
Compare the version with 8.6.67 or 9.7.0-alpha.11. Then read your Cloud Code. Find handlers declared with function that rely on object or arrow validators. Those are the exposed functions. Also check server logs for Cloud Function calls whose name carries an odd suffix.
Paste a lockfile or manifest into the free in-browser dependency scan to see whether the package is in your tree, including as a transitive dependency. Reachability analysis then helps you judge whether your code calls the affected path, so you can order the work sensibly.
Test the behavior directly in a staging copy. For each protected Cloud Function, call it without a session token and confirm it is refused. Then repeat for the variants you care about. Automate this as part of your test suite so a future change cannot silently remove a validator.
Also check which release line you run. The 9.x fix is listed as an alpha, 9.7.0-alpha.11. If you are on a stable 9.x release, check the project's release notes for the first stable build that includes the fix. The advisory does not name one, so confirm before you assume.
What to do now
- Upgrade Parse Server to 8.6.67 or 9.7.0-alpha.11 or later.
- List Cloud Functions that use
functionhandlers with object or arrow validators. - As a stopgap, convert those handlers to arrow functions, as the advisory suggests.
- Add checks inside sensitive functions, such as verifying
request.userorrequest.master, so one failed gate is not the only one. - Review logs for calls to protected functions from unauthenticated clients.
- Add a test that calls each protected function without credentials and expects a refusal.
- Add an automated test that calls every protected Cloud Function without credentials and expects a refusal.
Why it matters
The weakness is CWE-863, incorrect authorization. The access check existed, but the lookup that found the check did not follow the same path as the lookup that found the handler. When two tables are walked differently, an input can match in one and miss in the other, and a missing validator reads as no validator.
This fails open, like many bypasses. A missing rule should deny. A test that sends unauthenticated requests to every protected function would catch this class of issue.
The patch makes the traversal check that each step is a real store object, and stop at a function. The record does not mark this CVE as exploited and it is not on the CISA KEV list.
The mechanism is subtle but easy to follow. Cloud Functions are registered by name in one store, and their validators are registered in a second store. When a request arrives, the first store is walked by name, including dotted segments. A name with a suffix that points into the function's own prototype chain resolves to the same handler. The second store, walked a different way, finds nothing for that name, so no validator is applied.
The consequence is that access rules were not checked at all for those requests. Validators such as requireUser and requireMaster are the control that many Parse Server apps rely on for their most sensitive functions, so a bypass is serious even though the entry condition is narrow.
Defense in depth helps here. Inside any function that changes data or reads private data, check the caller explicitly, for example confirm that request.user exists or that request.master is set. That duplicates the validator on purpose. If a lookup bug ever skips one, the other still stands.
Finally, keep an eye on code that resolves names from user input, in your own code as well. Any time a request string is used as a key into an object, remember that objects have inherited properties, and prefer maps with explicit membership checks.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which handlers are affected?
Those declared with the function keyword whose validator is a plain object or arrow function. Arrow function handlers are not affected, per the advisory.
Sources
Last reviewed: 19 October 2026.
