CVE-2026-27804 is a critical authentication flaw (CVSS 9.1) in Parse Server. An unauthenticated attacker can forge a Google authentication token and log in as any user linked to a Google account. Upgrade to 8.6.3 or 9.3.1-alpha.4. Until then, disable Google authentication. The record does not mark it as exploited in the wild.
What's affected
Parse Server, npm package parse-server. Per the GitHub security advisory:
- Affected: 8.6.2 and earlier on the 8.x line, and 9.0.0 through 9.3.1-alpha.3
- Fixed: 8.6.3 and 9.3.1-alpha.4
The NVD description gives the alpha fix as 9.1.1-alpha.4, while the advisory and release tag read 9.3.1-alpha.4. Use the advisory version, and confirm on the release page. Only deployments with Google authentication enabled are affected.
How to check if you're exposed
Check the installed version and whether Google login is configured.
npm ls parse-server
Then search your Parse Server configuration, including environment variables, for an auth option named google. If it is not there, this CVE does not apply to you, though you should still upgrade.
For containers, check the parse-server version inside the image rather than the image tag alone.
What to do now
- Upgrade parse-server to 8.6.3 on the 8.x line, or 9.3.1-alpha.4 or later on the 9.x line.
- If you cannot upgrade today, disable Google authentication, as the advisory suggests.
- Review sign-in logs for Google logins from accounts that do not normally use Google, and for sessions you cannot explain.
- Revoke sessions for any account you cannot account for after the upgrade.
- Run your lockfile through the free scan at https://gold.safeguard.sh/scan to see whether parse-server appears elsewhere in your estate.
Why it matters
The record says the server trusted the algorithm named in the token header, so a token with the algorithm set to none was accepted as valid. The fix hardcodes the expected RS256 algorithm and replaces the custom key fetcher with the jwks-rsa library, which rejects unknown key IDs. NVD classifies the flaw as CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) and CWE-345 (Insufficient Verification of Data Authenticity).
This is a well known JWT failure. The verifier, not the token, must decide which algorithm is acceptable and which keys are trusted.
How token verification should work
JSON Web Tokens carry a header that names the algorithm used to sign them. A verifier that believes the header lets the sender choose how the token is checked. The Parse Server fix removes that choice by hardcoding the expected RS256 algorithm for Google tokens.
The second part of the fix replaces the adapter's custom key fetcher with the jwks-rsa library, which rejects key IDs it does not know. Together the two changes mean a token is accepted only when it is signed by one of the provider's published keys with the expected algorithm.
Checking your own code
If you wrote custom authentication adapters or use JWTs elsewhere, look for the same pattern. Verification calls should state the allowed algorithms explicitly and should fail closed when the header says anything else. Tests should include a token with the algorithm set to none and a token signed with an unexpected key, and both should be rejected.
After upgrading
Confirm the version with npm ls parse-server in each environment. Re-enable Google authentication only after the upgrade if you disabled it. Review sessions created through Google login during the exposure window and invalidate any you cannot explain.
Give the upgrade the same priority you would give any authentication fix. An attacker needs no credentials, only knowledge of an account that is linked to Google, and the record says all deployments with Google authentication enabled are affected.
Why the rating is critical
The score of 9.1 reflects a network attack with no privileges and no user interaction that results in high confidentiality and integrity impact. Availability is not affected. In plain terms, a successful forgery means the attacker is treated as a real user, with whatever that user can read and change in your Parse Server data. Review the class level permissions and access controls on your most sensitive classes, because they decide how much damage a forged identity can do. Fewer rights per user means a smaller loss when authentication fails.
Writing it up for your team
A short internal note helps others act on this. State the package, the two fixed versions, the workaround of disabling Google authentication, and the owner for each affected service. List where parse-server runs, including staging and old projects that nobody has touched. Add a date for confirming the upgrade, and ask each owner to reply once the version check passes. Short notes with clear owners get done faster than long ones.
Try it yourself
See how a dependency inventory shows where a package like parse-server sits in your projects, including indirect ones.
Click through it at your own pace, or open it full screen.
Quick check
Do I need the Google adapter enabled to be affected?
Yes. The advisory says all deployments with Google authentication enabled are affected. Other login methods are not covered by this record.
Which version fixes it on 9.x?
9.3.1-alpha.4 per the GitHub advisory. Check the release page before upgrading, since the NVD text differs.
Sources
Last reviewed: 19 October 2026.
