CVE-2026-30863: JWT Audience Validation Bypass in Parse Server Authentication Adapters

Parse Server provides authentication adapters to integrate third-party identity providers such as Google, Apple, and Facebook. These adapters handle the verification of JSON Web Tokens (JWT) submitted by clients to authenticate users within the Backend-as-a-Service (BaaS) ecosystem. The verification process inherently requires validating the cryptographic signature, expiration time, and audience claims within the token to ensure the credential was explicitly issued for the correct application.

CVE-2026-30863 identifies a critical flaw in this validation pipeline where the audience (aud) claim check is conditionally bypassed. The vulnerability manifests when server administrators omit the clientId or appIds parameters from the authentication adapter configuration. While the official Parse Server documentation states these parameters are required for secure operation, the software implementation fails to enforce their presence at runtime.

When the configuration parameters are missing, the authentication adapters skip the audience validation step entirely. The underlying JWT library verifies the cryptographic signature using the identity provider's public keys. This signature validation succeeds because the token is genuinely generated and signed by the identity provider (e.g., Google). The Parse Server then extracts the subject (sub) claim and authenticates the user, completely disregarding the intended recipient of the token.

This architectural oversight creates a direct path for Cross-Application Token Substitution attacks. An attacker can provision a valid token for an unrelated application they control and submit it to the vulnerable Parse Server. The server accepts the foreign token, resulting in an improper authentication sequence that grants the attacker unauthorized access to the application data.

The root cause of CVE-2026-30863 resides in an improper conditional evaluation within the verifyIdToken routines of the apple.js, google.js, and facebook.js authentication adapters. The code paths implement a logic flaw where the validation of the aud claim depends strictly on the truthiness of the expected audience configuration variable. If the expected audience is undefined, the validation block is skipped.

In standard deployment configurations, administrators provide a clientId string or appIds array representing their specific application registered with the identity provider. The vulnerable code evaluates if (clientId && jwtClaims.aud !== clientId) before rejecting a token. If clientId evaluates to false due to configuration omission, the statement short-circuits. Execution then continues to token acceptance, validating only the provider's signature and token expiration.

The Facebook authentication adapter contains an additional, more severe variant of this logic flaw. Within the Limited Login (OIDC) code path, the implementation entirely fails to pass the configured appIds to the underlying JWT verification utility. This results in a persistent audience validation bypass for Limited Login tokens, regardless of whether the administrator correctly configured the adapter.

These implementation defects violate the core principles of the OpenID Connect (OIDC) specification, which mandates strict audience validation to prevent token reuse across different relying parties. The failure to enforce required configuration parameters at initialization compounds the issue, transforming a common deployment misconfiguration into a critical security failure.

The vulnerable implementation in src/Adapters/Auth/google.js demonstrates the conditional bypass pattern clearly. The function receives the incoming token alongside the configuration object containing the clientId. The audience validation logic relies entirely on a conditional statement that requires clientId to be explicitly defined.

// VULNERABLE CODE: src/Adapters/Auth/google.js
if (clientId && jwtClaims.aud !== clientId) {
  throw new Parse.Error(
    Parse.Error.OBJECT_NOT_FOUND,
    `id token not authorized for this clientId.`
  );
}

The official patch introduced in Pull Request #10113 addresses this deficiency by enforcing the presence of the clientId before attempting any validation operations. The updated code throws a runtime error if the authentication adapter is invoked without proper configuration. This initialization check prevents the server from silently operating in an insecure state.

// PATCHED CODE: src/Adapters/Auth/google.js
async function verifyIdToken({ id_token: token, id }, { clientId, cacheMaxEntries, cacheMaxAge }) {
+  if (!clientId) {
+    throw new Parse.Error(
+      Parse.Error.OBJECT_NOT_FOUND,
+      'Google auth is not configured.'
+    );
+  }

Beyond the initialization check, the patch modifies the token verification process to explicitly pass the audience constraint to the underlying JWT library. By delegating the audience check to the standard verification function (e.g., jwt.verify(token, key, { audience: clientId })), the Parse Server guarantees that the token's aud claim strictly matches the configured parameters. This architectural shift eliminates the manual conditional bypass entirely.

Exploitation of CVE-2026-30863 requires the attacker to obtain a valid JWT issued by the target identity provider (Google, Apple, or Facebook). The attacker achieves this by registering their own application with the provider and generating a token for a user account they control. The token possesses a valid cryptographic signature, an accurate expiration time, and a correctly formatted payload.

The attacker submits this token to the target Parse Server's /users or /login HTTP endpoints, specifying the corresponding authentication provider in the authData payload. The server processes the authentication request using the vulnerable adapter. Because the adapter lacks the proper configuration, it skips the audience check and validates only the cryptographic signature against the provider's public JSON Web Key Set (JWKS).

Upon successful signature validation, the Parse Server reads the sub (subject) or email claim from the accepted token. It then queries the internal database for a user associated with that specific provider identity. If the user exists, the attacker assumes their session. If the user does not exist, the server configuration may dictate the creation of a new account linked to that identity, granting the attacker persistent access to the system.

A public proof-of-concept repository (Worthes/CVE-2026-30863-Exploit) demonstrates this attack methodology systematically. The exploit tool automates the submission of foreign tokens to Parse Server authentication endpoints. Security teams must monitor for anomalous authentication requests where the submitted token's audience payload does not match the organization's expected application identifiers.

Successful exploitation of this vulnerability yields a critical impact on the confidentiality and integrity of the Parse Server environment. The CVSS v4.0 base score of 9.3 reflects the severe consequences of unauthenticated remote access to user accounts. Attackers bypass primary authentication controls entirely without requiring any interaction or social engineering from the legitimate user.

Once authenticated, the attacker inherits the complete set of permissions associated with the compromised account. If the target account possesses administrative privileges or specific role-based access control (RBAC) grants, the attacker gains extensive control over the Parse Server instance. This access includes the capability to read, modify, or delete arbitrary database records, manipulate core server configurations, and invoke sensitive cloud code functions.

The vulnerability specifically affects servers where administrators missed a required configuration step, except for the Facebook Limited Login vector. The Facebook Limited Login path remains vulnerable regardless of correct configuration. This nuance expands the effective attack surface to include instances that administrators incorrectly believed were secure following standard deployment guidelines.

The Exploit Prediction Scoring System (EPSS) assigns a probability of 0.00066 (20.27th percentile) for active exploitation within the next 30 days. While the statistical probability remains relatively low, the availability of a public proof-of-concept repository significantly reduces the technical barrier to entry for threat actors. Organizations must treat this vulnerability as a high-priority remediation item due to the trivial nature of the exploit execution.

The primary remediation strategy requires upgrading the Parse Server package to a patched release. The maintainers resolved the vulnerability completely in versions 8.6.10 and 9.5.0-alpha.11. These updated releases enforce strict initialization checks and delegate the audience validation responsibility directly to the underlying JWT library, preventing manual logic bypasses.

Administrators who cannot immediately upgrade the software package must implement specific configuration workarounds for the Google and Apple adapters. Ensure the clientId parameter is explicitly defined and populated in the server's authentication adapter settings. Providing a valid clientId string forces the existing vulnerable conditional logic to execute the audience check, effectively mitigating the risk for these specific identity providers.

No operational workaround exists for the Facebook Limited Login vulnerability. The implementation flaw ignores the appIds configuration parameter entirely during the Limited Login token verification process. Organizations relying on Facebook authentication must upgrade the Parse Server package immediately to secure this vector against exploitation.

Following remediation actions, security teams should actively audit application logs for historical indicators of compromise. Review authentication events for signs of abnormal identity provider payloads or unexpected account creation patterns. Any accounts suspected of unauthorized access via foreign tokens must undergo immediate session revocation and credential rotation.