Summary
An authentication flaw in authentik's email authenticator enrollment allows a supplied recipient address to override the address established by the authentication flow. An actor who knows a user's password may redirect the one-time code to an attacker-controlled address, enroll the factor, and obtain a session as the target.
Affected context
The issue occurs in authentik email authenticator enrollment during an authentication or enrollment flow when the implementation trusts the recipient address in the setup request rather than the address associated with the established user context. Exploitation is relevant when the target has not already enrolled the email factor; other authenticator types are not affected.
Exploit preconditions
- Attack surface: Authentik authentication or authenticator-enrollment flow
- Required access: Knowledge of the target user's password and ability to initiate the relevant flow
- Trigger point: Email authenticator setup using a recipient address supplied in the enrollment request
- Additional condition: The target must not already have an email authenticator enrolled
- Why exploitation is possible: The enrollment process accepts an attacker-controlled destination for the one-time code instead of enforcing the address established for the target account
Why this happens
The underlying bug is a trust-boundary failure in authentication factor enrollment. A security-sensitive recipient value supplied by the request is treated as authoritative even though the authentication flow has already established the intended account and contact address.
This maps primarily to CWE-287: Improper Authentication, because the system can complete factor enrollment without reliably authenticating the destination as belonging to the target. It also relates to CWE-807: Reliance on Untrusted Inputs in a Security Decision, since request-controlled data influences an identity and authorization decision.
Potential impact
- An attacker may complete enrollment of an email factor for the target account
- The attacker could obtain an authenticated session as the target
- The attacker may access single sign-on applications available to the account
- Account recovery, authorization, or audit assumptions could be undermined
- The compromise could persist until the unauthorized factor is removed
General mitigation guidance
Mitigation generally focuses on binding enrollment data to the authenticated identity and reducing trust in client-supplied security parameters.
Common defensive patterns include:
- Deriving the recipient address from the server-side flow and account context
- Rejecting or ignoring client-provided addresses for security-sensitive enrollment decisions
- Requiring explicit confirmation of the established address before factor activation
- Applying consistent ownership and identity checks before accepting one-time codes
- Limiting factor-enrollment permissions and requiring step-up authentication where appropriate
- Invalidating incomplete or suspicious enrollment sessions and recording security-relevant events
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review rules identifying request fields used to select authentication destinations
- Review of enrollment handlers for server-side binding between the flow identity, account, and recipient
- Tests that attempt to alter recipient-related parameters during factor setup
- Monitoring for email-factor enrollments followed by immediate sign-in or SSO access from unusual locations
- Policy enforcement requiring server-derived identity attributes for authentication and recovery operations
Automated security review tools may help identify request-controlled values that influence authentication decisions.
