Listen to this Post
The Google, Apple, and Facebook authentication adapters in Parse Server handle identity token validation using JWT. For a secure JWT verification process, the library must check the `audience (aud)` claim to ensure the token was intended for the specific application (the “client”) presenting it. The vulnerability arises because the adapters fail to enforce this check under certain configurations. For Google and Apple adapters, if the required `clientId` configuration option is not explicitly set, the JWT verification logic silently skips the audience validation step entirely, rather than rejecting the missing configuration as an error . For the Facebook Limited Login flow, the issue is more severe: the adapter’s code path for handling these specific JWT tokens never passed the configured `appIds` to the JWT verification function at all, even when they were set . This means a malicious actor could take a validly signed JWT token—one issued by Google, Apple, or Facebook for any other application—and present it to a vulnerable Parse Server. Because the server skips the audience check, it incorrectly assumes the token is meant for its own app and authenticates the user, effectively allowing the attacker to log in as any user on the target system .
dailycve form:
Platform: Parse Server
Version: <8.6.10, <9.5.0-alpha.11
Vulnerability: JWT audience bypass
Severity: critical
date: 2026-03-07
Prediction: Immediate patch available
What Undercode Say:
Analytics:
This vulnerability is rooted in improper authentication handling (CWE-287) within the social login flow . It allows for a complete authentication bypass, scoring a critical 9.3 on the CVSS v4 scale . The flaw has existed in the codebase for an unknown period and was only recently fixed in patched versions 8.6.10 and 9.5.0-alpha.11 . While Google and Apple adapters had a conditional bypass (only if `clientId` was missing), the Facebook Limited Login flow was vulnerable in all unpatched versions regardless of configuration . This is a high-priority issue to patch as it requires no user interaction and can be triggered over the network.
Exploit:
An attacker would need to obtain a valid JWT identity token from Google, Apple, or Facebook for any app other than the victim’s. This could be their own malicious app or a legitimate one they have access to. They would then send this token to the victim Parse Server’s authentication endpoint. Since the server does not validate the `aud` claim, it will accept the token and create a session for the corresponding user.
Hypothetical exploit using curl
1. Obtain a valid JWT from Google for a malicious app (client_id: MALICIOUS_APP_ID)
2. Send that token to the victim's Parse Server (which expects CLIENT_ID_VICTIM)
VICTIM_SERVER="https://victim.parse-server.com"
VALID_JWT_FROM_OTHER_APP="eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJNQUxJQ0lPVVNfQVBQX0lEIiwiaXNzIjoiaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tIiwic3ViIjoiMTIzNDU2Nzg5MCJ9.signature"
curl -X POST $VICTIM_SERVER/login \
-H "Content-Type: application/json" \
-d '{
"authData": {
"google": {
"id": "1234567890",
"access_token": "'$VALID_JWT_FROM_OTHER_APP'"
}
}
}'
The server (if vulnerable) will accept this token and authenticate the user with ID 1234567890.
Protection from this CVE:
- Immediate Upgrade: The primary and most effective mitigation is to upgrade Parse Server to version
8.6.10,9.5.0-alpha.11, or later . - Configuration Check (Partial): For users unable to upgrade immediately but using Google or Apple adapters, a temporary workaround is to explicitly set the `clientId` in the adapter configuration. This forces the JWT library to perform the audience validation even on vulnerable versions .
// Example of setting the required clientId in Parse Server configuration var api = new ParseServer({ appId: 'my_app_id', masterKey: 'my_master_key', serverURL: 'http://localhost:1337/parse', auth: { google: { clientId: 'YOUR_GOOGLE_CLIENT_ID.apps.googleusercontent.com' // MANDATORY for fix }, apple: { clientId: 'YOUR_APPLE_SERVICE_ID' // MANDATORY for fix } } }); - No Workaround for Facebook: There is no workaround for the Facebook Limited Login vulnerability other than upgrading, as the configuration option is ignored in the vulnerable code path .
Impact:
Successful exploitation allows a remote, unauthenticated attacker to bypass the login system completely. By presenting a token from a different application, the attacker can impersonate any user who has previously linked their account with that provider (e.g., Google, Apple, or Facebook) on the target Parse Server . This leads to a total loss of confidentiality and integrity for that user’s data, as the attacker gains full access to the account and its associated permissions .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
