Description

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-13T17:17:25.063Z",
  "pubdate": "2026-08-13T17:17:25.063Z",
  "executiveSummary": "An improper authorization and state validation vulnerability exists in authentication mechanisms where OAuth2 sign-in workflows inadvertently reactivate administrator-deactivated accounts on specific authentication sources lacking refresh tokens.\nThis security flaw represents an incomplete fix for issue #38009, allowing suspended or explicitly disabled administrative or standard user accounts to regain system access simply by authenticating through an external OAuth2 provider.\nThe vulnerability impacts systems utilizing external OAuth2 integration alongside local or external user management where account deactivation states are not consistently enforced across all authentication pathways.\nThe primary risk implication is unauthorized access and privilege misuse, as security administrators lose the ability to permanently revoke access for compromised or terminated users if those users leverage an external identity provider mapped to their deactivated account.\nAn attacker with a previously deactivated account and valid credentials on the external OAuth2 identity provider can successfully exploit this flaw without requiring elevated privileges or complex pre-conditions.\nSuccessful exploitation bypasses administrative access controls and violates the security intent of account suspension mechanisms, potentially leading to unauthorized data access or persistence within the affected application.",
  "technicalDetails": "The root cause of this vulnerability lies in the flawed handling of account status validation during the OAuth2 federation and login callback sequence, serving as an incomplete remediation of the prior security defect referenced as #38009.\nWhen an administrator deactivates a user account within the application, the local database flags the user state as inactive or disabled. However, during the subsequent OAuth2 authentication flow, the system relies on identity mapping or user lookup logic that fails to verify the current deactivation status before issuing a valid session or updating the user record.\nSpecifically, authentication sources that do not utilize or support refresh tokens lack the continuous lifecycle state synchronization typically present in more robust token-granting integrations, causing the login routine to default to creating or reactivating the user profile upon successful external authentication.\nThe vulnerable component resides within the authentication state machine and OAuth2 callback handler functions responsible for reconciling external identity provider payloads with internal user records.\nAttack execution begins when an authenticated user whose account was previously deactivated by an administrator initiates an OAuth2 login flow using their external identity provider credentials.\nUpon successful authentication with the external provider, the application receives the authorization response, queries the internal user database based on email or unique identifier matching, and processes the login.\nBecause the validation check for the administrator-deactivated flag is omitted or improperly bypassed within the OAuth2 session establishment code path, the application updates the account state from inactive to active or bypasses the suspension block entirely.\nNetwork exposure is inherent to any system exposing an OAuth2 login endpoint to external users.\nAuthentication requirements are limited to possessing valid credentials on a configured external OAuth2 provider that maps to the target deactivated account.\nNo special privileges are required by the attacker beyond initiating the standard sign-in protocol.\nThe post-exploitation impact includes the restoration of unauthorized access, circumvention of administrative security controls, and potential re-establishment of persistent access for malicious or terminated actors."
}