Description

Coolify through 4.3.17 contains an authentication bypass vulnerability in the OAuth callback handler that signs users into existing accounts based solely on email address without verifying provider assertions or binding OAuth identities. Attackers can register a victim's email address on any enabled OAuth provider to obtain authenticated sessions as that user, bypassing password requirements and two-factor authentication.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-05T10:16:42.860Z",
  "pubdate": "2026-09-05T10:16:42.860Z",
  "executiveSummary": "Coolify versions through 4.3.17 are susceptible to a critical authentication bypass vulnerability within the OAuth callback handler.\nThe flaw stems from an insecure session initialization process where the application trusts the email address provided by an OAuth provider without verifying the underlying identity assertion or enforcing a secure binding between the OAuth identity and the local account.\nAn unauthenticated attacker can exploit this by registering a target victim's email address on any OAuth provider supported by the Coolify instance.\nUpon performing the callback flow, Coolify assumes the legitimacy of the email and grants the attacker an authenticated session as the victim.\nThis vulnerability effectively bypasses traditional password-based authentication and existing two-factor authentication (2FA) mechanisms, allowing unauthorized access to any user account, including administrative accounts, solely through email knowledge.\nThe risk is severe as it allows for full account takeover without requiring the victim's credentials or interaction, providing attackers with immediate unauthorized access to the application instance.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the OAuth callback handler in Coolify versions through 4.3.17. The application logic is designed to map an incoming authenticated session to an existing local user account based exclusively on the 'email' field returned by the OAuth identity provider.\nIn a secure OAuth implementation, the application should verify the cryptographic signatures of the identity assertion and, ideally, bind the local account to a unique, immutable identifier provided by the OAuth provider (such as a sub or provider-specific ID) rather than relying on a mutable or potentially spoofable email address.\nBecause Coolify fails to validate the provider's assertion or perform account binding, the authentication flow becomes susceptible to identity impersonation via email collision.\nThe attack flow proceeds as follows: 1) The attacker identifies a target victim's email address registered on an OAuth provider enabled within the Coolify instance (e.g., GitHub, Google). 2) The attacker creates a new account on that same OAuth provider using the victim's email address, or uses an existing account they control if they can manipulate the email attributes. 3) The attacker initiates the login process on the target Coolify instance via the compromised/controlled OAuth provider. 4) The Coolify callback handler receives the identity payload, extracts the email address, and queries the local database for an account associated with that email. 5) Finding a match, the application generates a session token for that account, effectively authenticating the attacker as the victim. 6) The attacker is granted full access to the victim's account, bypassing both the victim's password and any 2FA protections associated with the local account credentials, as these checks are bypassed by the assumed legitimacy of the OAuth callback.\nThis vulnerability allows for complete account takeover, granting the attacker the same privileges as the victim, which can lead to unauthorized configuration changes, deployment modifications, or access to sensitive environmental variables and keys if an administrative account is targeted."
}