CVE-2026-32242: 
JavaScript vulnerability analysis and mitigation

CVE-2026-32242 is a race condition vulnerability in Parse Server's built-in OAuth2 authentication adapter, classified as "OAuth2 adapter shares mutable state across providers via singleton instance." The adapter exports a singleton instance reused across all OAuth2 provider configurations, meaning concurrent authentication requests for different providers can cause one provider's token validation to execute using another provider's configuration — potentially allowing a token rejected by one provider to be accepted by another. Affected versions include Parse Server (npm) < 8.6.37 and >= 9.0.0, < 9.6.0-alpha.11. The vulnerability was published on March 11, 2026, and assigned CVE-2026-32242. It carries a CVSS v3.1 score of 7.4 (High) and a CVSS v4.0 score of 9.1 (Critical) (Github Advisory, Parse Server Advisory).

The root cause is CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization / Race Condition). Parse Server's OAuth2 auth adapter was implemented as a singleton exported module, meaning the same adapter instance — including its mutable configuration state — was shared across all configured OAuth2 providers. When concurrent authentication requests arrive for different OAuth2 providers, a timing window exists where one provider's token validation routine may read or operate on the configuration state written by another provider's concurrent request. This cross-provider state contamination can cause a token that should fail validation under Provider A's policy to instead be validated against Provider B's (potentially more permissive) policy. The vulnerability only affects deployments that configure multiple OAuth2 providers using the oauth2: true flag; single-provider deployments are not susceptible to the race condition (Github Advisory, Parse Server Advisory).

Successful exploitation allows an attacker to bypass OAuth2 token validation controls, enabling unauthorized authentication to the Parse Server instance. A malicious or otherwise invalid token — one that should be rejected by a specific OAuth2 provider's policy — could be accepted when the singleton adapter is momentarily configured with a different provider's settings during a concurrent request. This results in high confidentiality and integrity impact: an attacker could gain unauthorized access to protected resources, user data, and application functionality managed by the Parse Server. Availability is not directly impacted by this vulnerability (Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Feedly). Exploitation requires specific timing conditions — concurrent authentication requests targeting different OAuth2 providers — which increases attack complexity. The EPSS score is approximately 0.066% (21st percentile), indicating a low near-term exploitation probability (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been reported.

1. Reconnaissance: Identify a Parse Server deployment (version < 8.6.37 or >= 9.0.0 and < 9.6.0-alpha.11) that is configured with multiple OAuth2 providers using the oauth2: true flag.
2. Obtain a token: Acquire a valid OAuth2 token from one provider (Provider A) that would normally be rejected by a second provider (Provider B) configured on the same Parse Server instance.
3. Trigger concurrent requests: Send simultaneous authentication requests to the Parse Server — one legitimate request authenticating via Provider B, and one malicious request using the Provider A token but targeting Provider B's endpoint — timed to overlap during the singleton adapter's configuration update window.
4. Race condition exploitation: If the timing is correct, the singleton OAuth2 adapter will process the malicious Provider A token while its internal state is temporarily set to Provider B's configuration (or vice versa), causing the token to pass validation it should fail.
5. Unauthorized access: Upon successful authentication bypass, the attacker receives a valid Parse Server session token, granting access to protected resources and data as if they were a legitimately authenticated user (Github Advisory, Parse Server Advisory).

• Logs: Parse Server authentication logs showing successful OAuth2 logins where the token's issuer or audience does not match the expected provider configuration for that session; repeated concurrent authentication requests from the same IP targeting different OAuth2 providers in rapid succession.
• Network: Bursts of simultaneous POST requests to Parse Server's /1/users or OAuth2 login endpoints from a single source, particularly with tokens from multiple different OAuth2 providers.
• Application Behavior: Unexpected user sessions authenticated via an OAuth2 provider that the user account is not registered with; authentication successes immediately following or overlapping with authentication attempts from a different provider.

Parse Community has released patched versions that fix this vulnerability by ensuring a new adapter instance is created for each OAuth2 provider rather than reusing the singleton, isolating each provider's configuration. Users should upgrade to Parse Server 8.6.37 (for the v8 branch) or Parse Server 9.6.0-alpha.11 (for the v9 branch) (Parse Server 8.6.37 Release, Parse Server 9.6.0-alpha.11 Release). There is no known configuration-based workaround; however, deployments using only a single OAuth2 provider are not susceptible to the race condition and are not at risk. Organizations unable to patch immediately should review authentication logs for anomalous concurrent OAuth2 activity and consider implementing rate limiting on authentication endpoints (Github Advisory).

The vulnerability was reported by security researcher fancymalware and coordinated by Parse Server maintainer mtrezza, who published the GitHub security advisory on March 11, 2026 (Parse Server Advisory). A community write-up describing the authentication bypass via race condition was published on dev.to shortly after disclosure (dev.to Write-up). General community reaction has been limited, consistent with the low EPSS score and absence of active exploitation.