CVE-2026-86117 in Coolify
Summary
by MITRE • 09/05/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability identified in Coolify versions up to 4.3.17 represents a critical flaw within the application’s identity management subsystem, specifically targeting the OpenID Connect or OAuth callback handler mechanism. This component is responsible for finalizing the login process after an external Identity Provider has authenticated a user and returned credentials to the relying party. In this specific implementation, the system exhibits a fundamental failure in binding the asserted identity from the third-party provider to the local application account with sufficient cryptographic integrity checks. Instead of validating that the email address provided by the OAuth provider matches the expected subject identifier or verifying the signature integrity against the user's existing session context, the software relies exclusively on the email string as the primary key for account lookup and authentication state creation. This design choice creates a severe logical bypass where the application trusts external assertions without ensuring they are legitimately associated with the intended local identity during the initial binding phase.
From an operational perspective, this flaw allows for complete authentication bypass by malicious actors who can register or control accounts on any enabled OAuth provider using a victim’s email address. By doing so, an attacker initiates an OAuth flow that directs Coolify to look up the user based solely on the provided email string. Since the application does not verify whether the incoming identity assertion corresponds to the same entity as the local account record beyond this single attribute match, it automatically logs in as the victim without requiring a password or challenging for multi-factor authentication tokens. This effectively neutralizes all layered security controls including strong passwords and two-factor authentication mechanisms that are configured on the target account. The attacker gains full administrative access equivalent to the compromised user, potentially leading to unauthorized data exfiltration, configuration tampering, or lateral movement within environments where Coolify manages containerized workloads.
This vulnerability aligns closely with Common Weakness Enumeration (CWE) categories such as CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity. The root cause lies in the failure to enforce strict identity binding between the external provider’s assertion and the local user entity, which is a classic instance of account enumeration combined with authentication bypass logic errors. In terms of MITRE ATT&CK framework mapping, this behavior corresponds to T1078 Valid Accounts, specifically the technique where attackers use valid credentials obtained through social engineering or credential stuffing on third-party services to gain initial access without triggering standard security alerts associated with password brute-forcing. The lack of verification for provider assertions also touches upon CWE-613 Insufficient Session Expiration, as the session is established based on flawed identity resolution rather than robust cryptographic proof of user intent.
Mitigation strategies must prioritize immediate patching to version 4.3.18 or later where this logic has been corrected to enforce strict email verification and provider assertion binding. Until an update can be applied, administrators should consider disabling OAuth authentication methods entirely if they are not strictly required for the deployment environment. If OAuth remains necessary, implementing additional controls such as requiring manual account linking through a secure in-application workflow rather than automatic silent login based on email matching is essential. Furthermore, enabling strict logging and monitoring for new session creations originating from unexpected IP addresses or geographic locations can help detect exploitation attempts in real-time. Security teams should also audit all OAuth provider configurations to ensure that only trusted providers are enabled and that the application’s callback handlers enforce rigorous validation of state parameters and nonce values to prevent replay attacks alongside this identity binding flaw.