CVE-2026-54730 in Authentik
Summary
by MITRE • 08/18/2026
authentik is an open-source identity provider. Prior to 2026.2.6 and 2026.5.5, the enterprise Google Chrome device-trust stages advance the flow without confirming that the out-of-band device attestation actually ran. Affected enterprise deployments place either a Google Chrome Endpoint stage with mode set to REQUIRED or the deprecated Google Chrome Device Trust Connector stage in an authentication flow. The device attestation occurs in a verification iframe that calls the Google Verified Access API and records the verified device on success, but the vulnerable stages treat the flow as passed as soon as the stage is submitted. An attacker who can reach such a stage, including after primary username and password authentication, can skip the verification iframe and authenticate from a device that was never verified. Where device trust is the only additional factor, that protection is fully bypassed, while other configured factors remain in force. This issue is fixed in versions 2026.2.6 and 2026.5.5.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified within authentik, a widely adopted open-source identity provider, represents a critical logic flaw in the implementation of enterprise-grade device trust mechanisms for Google Chrome environments. Specifically affecting versions prior to 2026.2.6 and 2026.5.5, this issue stems from an improper validation sequence during the authentication flow when utilizing either the Google Chrome Endpoint stage configured with a REQUIRED mode or the deprecated Google Chrome Device Trust Connector stage. In these configurations, the system is designed to enforce device attestation as part of the multi-factor authentication process, ensuring that only devices meeting specific security criteria are granted access. However, the underlying code fails to verify whether the out-of-band device attestation procedure actually completed successfully before advancing the user through the authentication pipeline. This architectural oversight creates a significant gap in identity assurance, allowing for potential unauthorized access under certain conditions.
Technically, the flaw resides in how the application handles state transitions during the verification phase. The intended security model relies on an iframe that communicates with the Google Verified Access API to perform device attestation. Upon successful verification, this process records the verified status of the device within the session context. Despite this requirement for explicit confirmation, the vulnerable stages are programmed to treat the authentication stage as passed immediately upon form submission by the user or client application, without waiting for or checking the asynchronous result from the Google Verified Access API. This race condition-like behavior means that if an attacker can intercept or manipulate the request flow at the point of stage submission, they can bypass the actual verification step entirely. The system erroneously assumes that because the stage was reached and submitted, the necessary checks have been performed, which is a fundamental violation of secure authentication principles where state must be explicitly confirmed rather than inferred from procedural progression.
The operational impact of this vulnerability is severe for organizations relying on device trust as their primary additional factor beyond standard username and password credentials. If an attacker gains access to such a stage, potentially after successfully completing the initial primary authentication with valid credentials, they can skip the verification iframe entirely. This allows them to authenticate from any device that has never undergone the required attestation process. In scenarios where device trust serves as the sole secondary factor, this flaw results in a complete bypass of the security control, effectively reducing multi-factor authentication back to single-factor authentication based solely on knowledge factors like passwords. Even when other factors are present, such as hardware tokens or mobile authenticators, the integrity of the device-based assurance is compromised, potentially allowing access from unmanaged, maliciously modified, or non-compliant devices that should have been blocked by the endpoint security policies.
This vulnerability aligns with CWE-287, which describes Improper Authentication, specifically relating to the failure to properly verify credentials or contextual factors during an authentication transaction. Furthermore, it relates to ATT&CK technique T1078, Valid Accounts, as it allows attackers to leverage legitimate but insufficiently verified accounts for unauthorized access. The flaw also touches upon CWE-693, Protection Mechanism Failure, where the system fails to prevent a specific attack despite having security controls in place due to implementation errors. For administrators and security teams managing authentik deployments, immediate action is required to mitigate this risk. The recommended mitigation involves upgrading to version 2026.2.6 or later for the stable branch, or version 2026.5.5 and above for the development branch, where these logic errors have been corrected to ensure that device attestation results are explicitly validated before advancing the authentication flow. Until such updates are applied, organizations should consider disabling Google Chrome device trust stages in critical flows or implementing additional compensating controls to verify device integrity through alternative means.