Description

Parse Server is an open-source backend server. In versions >= 9.0.0 < 9.10.1-alpha.10 and >= 8.0.2 < 8.6.91, the code-based authentication adapters (GitHub, Google Play Games, Instagram, LINE, LinkedIn, Microsoft, QQ, Spotify, WeChat, Weibo) verify the client's authorization code with the external provider on signup and on provider linking, but not when authentication data is supplied together with a username and password on the login endpoint. As a result, a low-privileged authenticated user can attach an arbitrary, unverified provider identity to their own account without the provider ever being contacted, spoofing an external identity toward application logic that trusts the linked provider ID. An attacker can also pre-hijack accounts: by claiming the provider ID of a victim who has not yet linked that provider, the victim's later legitimate sign-in with that provider resolves to the attacker's account. Only deployments configuring one of the affected code-based auth adapters are impacted. Versions 9.10.1-alpha.10 and 8.6.91 fix the issue by running the adapter's credential verification on the login and challenge endpoints and rejecting a provider identity already linked to another user. As a workaround, disable the affected code-based auth adapters.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-09-27T17:16:55.820Z",
  "pubdate": "2026-09-27T17:16:55.820Z",
  "executiveSummary": "This vulnerability involves an improper authentication verification flaw within the Parse Server backend, specifically affecting its code-based authentication adapters (GitHub, Google Play Games, Instagram, LINE, LinkedIn, Microsoft, QQ, Spotify, WeChat, Weibo).\nThe vulnerability allows an attacker to bypass critical identity verification steps during the login process, leading to the unauthorized linking of external provider identities to user accounts.\nThe impact is significant, enabling account pre-hijacking and identity spoofing. An attacker can link an arbitrary, unverified provider ID to their own account or claim an identity belonging to a victim before the victim initializes the link, effectively redirecting the victim's legitimate authentication to the attacker's controlled account.\nThis issue affects Parse Server versions >= 9.0.0 < 9.10.1-alpha.10 and >= 8.0.2 < 8.6.91.\nThe risk is heightened because the flaw resides in the handling of authentication data on the login endpoint, where credential verification is bypassed, unlike the signup or provider linking endpoints.",
  "technicalDetails": "The vulnerability originates from a failure to perform server-side credential verification with external identity providers during the login and challenge exchange processes. While Parse Server correctly mandates validation via external providers for signup and explicit account linking, it fails to enforce these same checks when authentication data is supplied alongside username and password credentials on the login endpoint.\nThe root cause is an inconsistent implementation of the auth adapter's verification logic. The server assumes that data provided at the login endpoint is already authenticated or trusted, lacking a secondary validation check to ensure the external provider identity corresponds to a genuine, authorized session.\nAttack flow for identity spoofing: An attacker submits a crafted authentication payload to the Parse Server login endpoint, including an arbitrary provider ID. Because the server omits the handshake with the external provider, the application logic accepts the spoofed provider ID as legitimate. This allows the attacker to associate a trusted external identity with their local user account.\nAttack flow for pre-hijacking: An attacker can register an account and proactively link a victim's external identifier. If the victim has not yet linked that specific identifier to their own account, the server permits the association. When the victim attempts to sign in via the legitimate provider, the application logic resolves the authentication to the account already containing that ID, which is the attacker's account.\nExploitation requires that the deployment utilizes one of the affected code-based auth adapters. The attack is executable by any user who can reach the login endpoint, requiring no advanced privileges to initiate the illegitimate association. The lack of server-side validation transforms the login endpoint into a vector for identity impersonation.\nSuccessful exploitation results in total compromise of account ownership contexts and allows attackers to bypass logical authorization checks that rely on the integrity of third-party identity providers. The fix implemented in versions 9.10.1-alpha.10 and 8.6.91 forces the server to execute the adapter-specific credential verification logic on both the login and challenge endpoints, and introduces a constraint to reject provider identities already registered to different user accounts."
}