EUVD-2026-86280Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain target's authentik password
-
DeliveryBegin auth/enrollment flow as target
-
ExploitSubmit email-factor setup with attacker-controlled address
-
ExecutionReceive one-time code at attacker inbox
-
PersistComplete email authenticator enrollment
-
ImpactAssume victim session and reach SSO applications
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK
2 techniques across 2 tactics: Defense Evasion, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires ALL of the following: the deployment enrolls the email authenticator during an authentication or enrollment flow (other authenticator types are not affected); the attacker already knows the target user's password; and the target has NOT yet enrolled the email factor. Given those, the attacker overrides the recipient address in the authenticator setup request to receive the OTP and complete enrollment. Limiting factors: prior knowledge of the victim's credentials is mandatory, the email factor must be un-enrolled, and only email-authenticator flows are impacted - there is no workaround other than upgrading (or not relying on the email authenticator until patched to 2026.2.7 / 2026.5.7 / 2026.8.2). |
| Impact | This is a genuine, high-value MFA-bypass / account-takeover flaw, but its real-world exploitability is meaningfully gated by preconditions that the raw 8.9 CVSS underplays. The vendor CVSS (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L) is network-reachable and rates PR:N, yet the description and GHSA-qgqp-xh8r-v73r make clear the attacker MUST already know the target's password - that dependency is what drives AC:H rather than being reflected as a privilege, so the 'unauthenticated' PR:N label is technically defensible but practically misleading. Impact is severe and well-justified: successful enrollment yields a full authenticated session as the victim plus lateral access to every SSO application behind that account (supporting C:H/I:H and the S:C scope change); A:L is the weakest-supported metric since the advisory describes takeover, not disruption, so A:N is arguably more accurate. No EPSS score, no CISA KEV entry, and no public exploit code are present in the provided intelligence - status is therefore 'no public exploit identified at time of analysis.' Net: a real priority for authentik operators who enroll the email authenticator during auth/enrollment flows, but it is a credential-dependent, precondition-heavy attack (password known AND email factor not yet enrolled), so it favors targeted abuse over mass, automatable exploitation. The absence of EPSS/KEV/POC signals should be read as 'not yet observed,' not 'low risk.' |
| Exploit ScenarioDerived | An attacker who has phished or credential-stuffed a target's authentik password begins an authentication or enrollment flow as that user, reaches the email-authenticator setup step, and supplies an attacker-controlled recipient address instead of the address the flow had established. The one-time code is delivered to the attacker's inbox, the attacker completes enrollment, and authentik grants a live session as the victim with access to all SSO-integrated applications. No public exploit code is identified, but the attack requires no special tooling beyond an HTTP client. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 24, 2026
Multi-factor authentication bypass in authentik (goauthentik) allows an attacker who already knows a target user's password to redirect the email authenticator's one-time code to an address they control, complete enrollment of the email factor as the victim, and obtain a session with access to any single sign-on applications behind the account. Only deployments that enroll the email authenticator during an authentication or enrollment flow are affected, and only where the target has not yet enrolled the email factor; other authenticator types are unaffected. Rated 8.9 by the vendor (independent re-assessment scores it slightly lower on availability impact), there is no public exploit identified at time of analysis and no CISA KEV listing, but the precondition of prior credential knowledge makes this a high-value account-takeover primitive for attackers who phish or reuse passwords. Fixed in 2026.2.7, 2026.5.7, and 2026.8.2.
RemediationAI
Upgrade to the fixed release for your track: authentik 2026.2.7 (for pre-2026.2.x deployments), 2026.5.7 (for the 2026.5.x line), or 2026.8.2 (for the 2026.8.x line) - this is a vendor-released patch and the exact versions above are derived from the advisory GHSA-qgqp-xh8r-v73r and the corrected upstream commits (PRs #25958/#25963/#25968/#25973). The vendor states there is no workaround, and explicitly recommends not relying on the email authenticator for MFA until the upgrade is applied. Concrete compensating controls if you cannot patch immediately: remove the email authenticator stage from authentication and enrolment flows (or disable email-based MFA for privileged accounts) so the vulnerable code path is unreachable - the trade-off is that you lose an MFA option and must fall back to TOTP/WebAuthn, which are unaffected; alternatively, where the flow design permits, pre-enrol or force-enrol the email factor for all accounts ahead of any login attempt, since the exploit requires the target not to have enrolled the factor yet - this removes the precondition but forces a user-wide enrolment exercise and does not protect accounts created afterwards; and tighten password controls (unique-credential enforcement, credential-stuffing/phishing-resistant authentication, alerting on email-factor enrolment events and on unexpected recipient addresses) because the attack still hinges on the actor already knowing the victim's password. Monitor authentik logs for authenticator-email enrolment events in which the code recipient diverges from the account's stored address. Reference advisories: the GitHub security advisory and the release notes linked above.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is an improper-authentication weakness (CWE-287) in authentik's email authenticator stage, a Django/Python component under authentik/stages/authenticator_email/. During an authentication or enrollment flow, the stage's challenge response handler read the recipient address directly from the submitted form data (attrs["email"]) and used it for both the device record (self.device.email) and the code dispatch (stage.validate_and_send()), instead of honouring the address the flow had already resolved and established for the user. Because the flow-executor endpoint is reachable without an authenticated authentik session (CVSS PR:N) and the stage accepted the request-supplied value, an actor in possession of the victim's password could supply an attacker-controlled address, receive the one-time code, and finalise enrolment of the factor under the victim's identity. The upstream fix (visible in PR #25958 and mirrored in #25963, #25968, #25973 with commits 01d4349, 1fcf986, c10ae83, ec41732) introduces a stage._has_email() check: when the flow has already established a destination address, that address is used and any request-supplied "email" value is ignored, with the code (re)sent to the established address; the fallback to attrs["email"] only applies when no address is established. The scope change in the CVSS vector (S:C) reflects that completion of the factor yields a session and downstream SSO access beyond the affected component.
Know when Authentik gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L
Network-reachable and needs no attacker account (PR:N), but hinges on knowing the victim's password and an un-enrolled factor (AC:H); account takeover with SSO reach yields C:H/I:H and S:C, while availability is not affected (A:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
authentik is an open-source identity provider. Prior to 2026.2.7, 2026.5.7, and 2026.8.2, authentik email authenticator enrollment during an authentication or enrollment flow accepts a recipient address supplied in the setup request instead of using the address already established by the flow. An actor who knows a target user's password can substitute an attacker-controlled address, receive the one-time code, and finish enrolling the factor as the target. The target must not have enrolled the email factor already. Successful enrollment gives the actor a session as the target and access to single sign-on applications behind the account. Other authenticator types are not affected. This issue is fixed in versions 2026.2.7, 2026.5.7, and 2026.8.2.
Technical POC Analysis
CWE-287 (Improper Authentication), with the advisory also tagging CWE-807 (Reliance on Untrusted Inputs in a Security Decision).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A multi-factor authentication bypass in authentik (goauthentik) lets an attacker who already holds a user's password take over that account by redirecting the email authenticator's one-time code to an address they control and completing enrollment of the email factor as the victim, yielding a session with access to every single sign-on application behind the account. Only deployments that enroll the email authenticator during an authentication or enrollment flow and whose target users have not yet enrolled the email factor are exposed; other authenticator types are unaffected. No public exploit or confirmed active exploitation was identified at time of analysis, but the requirement for prior credential knowledge makes this a high-value capability for attackers who phish or rely on password reuse, so leadership should treat authentik as a priority identity-platform remediation item.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
authentik is an open-source identity provider. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploi
authentik is an open-source Identity Provider focused on flexibility and versatility. Rated high severity (CVSS 8.8), th
authentik is an open-source Identity provider focused on flexibility and versatility. Rated medium severity (CVSS 6.4),
Authentication bypass in authentik identity provider (versions prior to 2025.12.6, 2026.2.4, and 2026.5.1) allows remote
authentik is an open-source Identity Provider. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploi
authentik is an open-source Identity Provider. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploi
authentik is an open-source identity provider. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploi
authentik is an open-source identity provider. After authorizing access to a RAC endpoint, authentik creates a token whi
Account takeover in authentik (goauthentik) identity provider before 2026.2.6 and 2026.5.5 allows an attacker holding an
Cross-site scripting in authentik identity provider versions prior to 2025.12.5 and 2026.2.3 allows remote attackers to
Code injection in authentik identity provider from 2021.3.1 through multiple versions. Users with delegated permissions
authentik is an open-source identity provider. Rated critical severity (CVSS 9.0), this vulnerability is remotely exploi
Exploit-DB