[Vulnerability] parse-community/parse-server: Authentication State Contamination

[github-actions]

Potential Security Vulnerability Detected

Repository: parse-community/parse-server
Commit: 6009bc1
Author: Manuel
Date: 2026-03-11T16:37:14Z

Commit Message

fix: OAuth2 adapter shares mutable state across providers via singleton instance ([GHSA-2cjm-2gwv-m892](https://github.com/parse-community/parse-server/security/advisories/GHSA-2cjm-2gwv-m892)) (#10183)

Pull Request

PR: #10183 - fix: OAuth2 adapter shares mutable state across providers via singleton instance (GHSA-2cjm-2gwv-m892)
Labels: state:released-alpha

Description:

Pull Request

• Report security issues [confidentially](https://github.com/parse-community/parse-server/security/policy).
• Any contribution is under this [license](https://github.com/parse-community/parse-server/blob/alpha/LICENSE).

Issue

OAuth2 adapter shares mutable state across providers via singleton instance ([GHSA-2cjm-2gwv-m892](GHSA-2cjm-2gwv-m892))

Tasks

• Add tests
• Add changes to documentation (...

Analysis

Vulnerability Type: Authentication State Contamination
Severity: High

Description

The OAuth2 adapter before the patch used a singleton instance shared across different OAuth2 providers, causing mutable state to be shared concurrently. This allowed attackers to exploit state leakage or contamination between providers, leading to authentication bypass or privilege escalation by confusing provider-specific tokens and configurations. The patch ensures that each provider gets an isolated adapter instance, preventing cross-contamination during concurrent authentications.

Affected Code

const adapter =
  defaultAdapter instanceof AuthAdapter ? defaultAdapter : Object.assign({}, defaultAdapter);

Proof of Concept

1. Configure two OAuth2 providers (providerA and providerB) with distinct client IDs and token introspection endpoints.
2. Initiate concurrent authentication requests using providerA's token but intercepted to use providerB's adapter instance state.
3. Due to shared singleton, the mutable config of providerB overwrites providerA's, causing authentication to accept tokens for providerB as valid for providerA.

Specifically:
- User logs in with providerA using a token.
- Before completion, another login with providerB modifies the singleton adapter state.
- The first login's adapter now uses providerB's config, enabling attacker to authenticate as providerA user by reusing providerB's token.

This leads to flawed authentication boundary allowing cross-provider token acceptance and potential privilege escalation.

---

This issue was automatically created by Vulnerability Spoiler Alert.
Detected at: 2026-03-11T18:03:01.134Z