CVE-2026-32242: Authentication Bypass via Race Condition in Parse Server OAuth2 Adapter

Parse Server exposes a built-in OAuth2 authentication adapter to handle third-party logins via providers like Google, Apple, and LinkedIn. This adapter processes incoming authentication tokens by validating them against the respective provider's configuration endpoints. Deployments utilizing multiple OAuth2 providers rely on this component to multiplex authentication requests securely.

CVE-2026-32242 identifies a critical race condition (CWE-362) within this authentication adapter. The vulnerability stems from the improper reuse of a singleton adapter instance across concurrent authentication requests. When multiple requests target different OAuth2 providers simultaneously, the shared instance state is overwritten.

This state overwrite causes validation logic intended for one provider to execute using the configuration parameters of another. Consequently, an attacker can bypass authentication checks. The impact includes unauthorized access to user accounts and potential privilege escalation within the application context.

The core issue resides in the loadAuthAdapter function located in src/Adapters/Auth/index.js. This function is responsible for initializing and configuring the authentication adapter for a specific OAuth2 provider. During initialization, the code checks if the defaultAdapter is an instance of AuthAdapter.

If the check passes, the application reuses the existing defaultAdapter instance rather than instantiating a new object. The function then applies provider-specific configuration options, such as tokenIntrospectionEndpointUrl and appIds, to this shared instance using Object.assign().

Because JavaScript execution in Node.js handles asynchronous operations concurrently, the Object.assign() call mutates the shared singleton state while other asynchronous validation tasks are suspended in the event loop. If two authentication requests for different providers arrive closely together, the second request mutates the adapter state before the first request's asynchronous validation completes.

The first request resumes execution and utilizes the newly mutated state containing the second provider's configuration. This cross-contamination of configuration parameters fundamentally undermines the token validation process, allowing invalid tokens to pass validation under the wrong provider's rules.

Reviewing the vulnerable code in src/Adapters/Auth/index.js reveals the direct assignment to the shared adapter reference. The implementation explicitly retains the defaultAdapter instance if it matches the AuthAdapter prototype.

function loadAuthAdapter(provider, authOptions) {
  // Vulnerable implementation reusing the singleton instance
  const adapter =
    defaultAdapter instanceof AuthAdapter ? defaultAdapter : Object.assign({}, defaultAdapter);
 
  if (authOptions[provider]) {
    // Mutates the shared instance state for all concurrent operations
    Object.assign(adapter, authOptions[provider]);
  }
  return { adapter };
}

The patch introduced in PR #10184 corrects this behavior by instantiating a fresh object for every provider call. By invoking the constructor on the defaultAdapter, the fix ensures memory isolation between concurrent requests.

function loadAuthAdapter(provider, authOptions) {
  // Patched implementation creates a new instance
  const adapter =
    defaultAdapter instanceof AuthAdapter ? new defaultAdapter.constructor() : Object.assign({}, defaultAdapter);
 
  if (authOptions[provider]) {
    // Mutates an isolated instance state safely
    Object.assign(adapter, authOptions[provider]);
  }
  return { adapter };
}

This architectural change removes the shared state condition entirely. Each authentication request now receives an isolated adapter instance, preventing concurrent requests from polluting the configuration space of unrelated OAuth2 providers.

Exploitation of CVE-2026-32242 requires precise timing and a target deployment configured with multiple OAuth2 providers. An attacker initiates two concurrent authentication requests targeting different providers, such as Provider A and Provider B.

The attacker provides an invalid or carefully crafted token for Provider A, while simultaneously sending a request to Provider B. The application begins processing Provider A's request, suspending execution to perform external token validation or database lookups.

During this suspension, the application processes Provider B's request, executing the loadAuthAdapter function. This execution overwrites the singleton's configuration with Provider B's parameters, including permissive application IDs or different user identification fields.

When Provider A's request resumes, it continues validation using Provider B's configuration. If the attacker crafts the initial token to align with the substituted validation parameters, the token passes the checks. This logic confusion grants the attacker authenticated access to the system without possessing valid credentials for the targeted user account.

The vulnerability carries a CVSS 4.0 score of 9.1, reflecting its critical nature and high impact on confidentiality and integrity. Successful exploitation allows an unauthenticated remote attacker to gain unauthorized access to user accounts.

Once authenticated, the attacker assumes the privileges of the compromised user. Depending on the targeted account, this grants the ability to read sensitive data, modify database records, or execute further privilege escalation attacks within the Parse Server environment.

The attack complexity is rated as high due to the strict timing requirements necessary to trigger the race condition reliably. However, in high-traffic environments or through automated exploitation tools, an attacker can issue a large volume of concurrent requests to increase the probability of a successful state overwrite.

The scope remains unchanged as the vulnerability affects only the Parse Server instance itself. The lack of required user interaction and the absence of prior authentication prerequisites further elevate the severity of this authentication bypass flaw.

The primary remediation strategy is updating Parse Server to a patched version. Administrators must upgrade deployments to version 8.6.37 or 9.6.0-alpha.11, which contain the architectural fix isolating adapter instances.

For environments where immediate patching is unfeasible, administrators should review their OAuth2 provider configurations. Disabling unused or non-essential OAuth2 providers reduces the attack surface, as the vulnerability requires multiple active providers to trigger the state confusion.

Defenders can implement monitoring to detect potential exploitation attempts. Analyzing authentication logs for concurrent login requests originating from the same source IP but targeting different providers indicates anomalous behavior.

Additionally, monitoring for elevated rates of OAuth2 validation failures or discrepancies between the requested provider and the validated token parameters aids in identifying ongoing attacks. Implementing strict rate limiting on authentication endpoints increases the difficulty of executing the required concurrent requests.