CVE-2026-32248 is a critical account takeover in Parse Server, scored 9.8. An unauthenticated attacker can take over users created through an auth provider that does not validate the identifier format, such as anonymous auth, which is on by default. Upgrade to 8.6.38 or 9.6.0-alpha.12, or later.
What's affected
Parse Server before 8.6.38 on the 8.x line and before 9.6.0-alpha.12 on the 9.x alpha line. Both MongoDB and PostgreSQL backends are affected.
The advisory says any deployment that allows anonymous authentication is vulnerable, and anonymous authentication is enabled by default. That makes the default configuration the risky one.
Accounts that were created with a provider that never checks the shape of the user identifier are the ones that can be taken over.
How to check if you're exposed
Parse Server is usually installed from npm, so the quickest check is your lockfile or the installed package.
npm ls parse-server
If you run the official Docker image, read the image tag you deploy and compare it with the fixed releases. Then confirm which database you use. This issue only applies to deployments backed by PostgreSQL, so a MongoDB only install is outside its scope.
Then check which authentication providers you allow in your Parse Server configuration. If anonymous auth is on and you do not use it, note that in your change record. Turning it off can reduce exposure, but it is not a substitute for the upgrade.
What to do now
- Upgrade Parse Server to 8.6.38 or later, or 9.6.0-alpha.12 or later.
- Review the authentication providers enabled in your configuration and disable the ones you do not use.
- Look for sessions or logins that appear for accounts created through anonymous or similar providers, especially from unfamiliar addresses.
- Consider invalidating sessions for affected accounts after you patch, since the attacker obtains a valid session token.
- Add a regression check to your release pipeline so an old Parse Server version cannot ship again.
Why it matters
The weakness class is CWE-943, improper neutralization of special elements in data query logic. In plain words, the login request was able to turn an exact match lookup into a pattern matching lookup. A crafted identifier then matched somebody else's record, and the server handed back that person's session token.
What makes this one worth a fast patch is the combination of three facts from the advisory. No authentication is needed. The default configuration is vulnerable. And the result is a real session for another user, not a data leak that needs further work.
Account takeover bugs in backend platforms spread risk to every app built on them, because the app developer often never sees the login code. If you operate Parse Server for several apps, patch the shared deployment first and check each app's provider settings afterward.
The record does not flag this CVE as listed in CISA's Known Exploited Vulnerabilities catalog, and no advisory I read says it is exploited in the wild. Treat it as a patch to schedule promptly, not a fire drill, unless your own logs say otherwise.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is turning off anonymous auth enough?
It reduces exposure to the default path described in the advisory, but the fixed releases are the real remedy. Upgrade as well.
Does my database choice change anything?
No. The record says both MongoDB and PostgreSQL deployments are affected.
How do I know if someone already used this?
The advisory does not describe detection steps. Review login and session activity for accounts created with providers that skip identifier validation, and check the advisory for updates.
Sources
Last reviewed: 19 October 2026.
