Summary
authentik SAML Sources accept assertions after checking their signatures and validity periods without confirming that the assertion was issued for the specific Source or generated in response to its login request. An unauthenticated actor who obtains a valid assertion may authenticate as the user named in it, including by reusing an earlier assertion.
Affected context
The issue affects authentik deployments that use SAML Sources to authenticate users. It becomes risky when a valid assertion intended for another service provider, or an assertion previously accepted by the Source, can be presented to the SAML login endpoint without audience, request correlation, and replay protections being enforced. SAML Providers and non-SAML Source types are outside the described scope.
Exploit preconditions
- Attack surface: The SAML Source authentication endpoint
- Required access: Possession of a valid, signed SAML assertion; prior authentication to authentik is not necessarily required
- Trigger point: Submission of the assertion to the affected SAML Source
- Why exploitation is possible: The Source validates signature and time validity but does not sufficiently bind the assertion to the intended service provider, an originating login request, or prior acceptance state
Why this happens
The underlying defect is incomplete authentication-context validation. A SAML consumer must verify not only that an assertion is authentic and temporally valid, but also that its audience, recipient, issuer context, and request correlation match the expected Source and authentication transaction. Failure to enforce those relationships maps primarily to CWE-287: Improper Authentication and is related to CWE-345: Insufficient Verification of Data Authenticity. The absence of assertion tracking also permits replay of otherwise valid authentication material.
Potential impact
- An attacker may authenticate as the user identified by a captured assertion
- An attacker could gain unauthorized access to applications federated through the affected SAML Source
- A replayed assertion can result in repeated unauthorized sign-ins
- Account impersonation could enable access to sensitive data or privileged workflows
General mitigation guidance
Mitigation generally focuses on binding every accepted assertion to the intended SAML authentication context and preventing reuse.
Common defensive patterns include:
- Validate issuer, audience, recipient, destination, and assertion-consumer-service relationships against the configured Source
- Require correlation with an authentik-initiated login request where the flow supports request tracking
- Record assertion identifiers and reject previously accepted assertions within their validity window
- Enforce strict, short-lived assertion validity periods and reject unexpected clock or context conditions
- Apply least privilege to federated identities and avoid granting broader access than the asserted role requires
- Centralize SAML validation so all authentication paths use the same policy and trust checks
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for SAML consumers that validate signatures without audience, recipient, issuer, or request correlation checks
- Tests that submit assertions issued for another service provider or outside the current login transaction
- Replay testing using the same assertion more than once
- Authentication logs that correlate assertion identifiers, subjects, sources, request IDs, and acceptance timestamps
- Policy enforcement requiring one-time assertion handling and explicit SAML trust-context validation
Automated security review tools may help identify incomplete validation logic, but protocol-focused integration tests are important for confirming enforcement behavior.
