CVE-2026-94609

authentik before versions 2026.2.6 and 2026.5.5 contains a vulnerability in SAML Source configuration with USERNAME_LINK or EMAIL_LINK user-matching mode. An attacker can inject an XML comment into NameID, leading to account takeover.

Vulnerability in authentik (identity provider) prior to versions 2025.12.6, 2026.2.4, and 2026.5.1 allows bypassing the Source stage by sending an empty POST request.

XSS vulnerability in the AutosubmitStage component in authentik (open-source identity provider) prior to versions 2025.12.5 and 2026.2.3, allowing an attacker to inject malicious scripts.

In authentik before 2026.2.7, 2026.5.7, and 2026.8.2, an unauthenticated attacker can submit a malformed SAML message to an installation using SAML in either the identity-provider or SAML source role. The message can stop the worker handling /application/saml/* or /source/saml/*, causing assigned requests to fail. Continued malicious messages can cause a sustained share of legitimate traffic to fail. Other protocols are not affected.

In authentik before 2026.2.7, 2026.5.7, and 2026.8.2, a SAML Source verifies an assertion's signature and validity period but does not ensure that the identity provider issued the assertion for that Source or in response to a login request from that Source. It also does not record already accepted assertions, allowing replay. An unauthenticated actor possessing a valid assertion can use it to authenticate as the user named in the assertion. Only SAML Sources are affected.

In authentik before 2026.2.7, 2026.5.7, and 2026.8.2, API serializers return stored credentials when an account has view permission on an affected configuration, even without authorization to change it or read secrets. Affected configurations include one-time code delivery, outbound provisioning, device trust, identity sources, Kubernetes outpost, and applications using secrets. Deployments are at risk when view permission is granted to accounts not intended to read these credentials.

In authentik before 2026.2.7, 2026.5.7, and 2026.8.2, email authenticator enrollment during an authentication or enrollment flow accepts a recipient address supplied in the setup request instead of using the established address. An attacker who knows the target's password can substitute an attacker-controlled address, receive the one-time code, and finish enrolling the factor as the target. Successful enrollment gives the attacker a session as the target and access to SSO applications.

authentik before versions 2026.2.6 and 2026.5.5 returns every configured Remote Access Control endpoint to any authenticated user regardless of application access, and the response includes connection settings that may contain stored credentials. Any authenticated user can read all endpoints with host and credentials and open connections to endpoints belonging to other applications, exposing credentials for managed RDP, SSH, and VNC targets and granting interactive access to unauthorized systems.

authentik is an open-source identity provider. Prior to 2026.2.6 and 2026.5.5, a diagnostic action on the LDAP Source API does not enforce the object-level read-authorization filter used by the rest of the API. Any party able to reach the API, including an unauthenticated client, can invoke the diagnostic action against a configured LDAP Source. The server then connects to the upstream directory using the source's configured bind credentials and returns a bounded set of directory entries. The response exposes the distinguished names of those entries and the names of the attributes present on them, revealing directory structure, naming conventions, and the existence of specific accounts and groups, but not attribute values. Deployments without a configured LDAP Source are not affected. This issue is fixed in versions 2026.2.6 and 2026.5.5.

authentik before versions 2026.2.6 and 2026.5.5 in enterprise Google Chrome device-trust stages advance the flow without confirming that the out-of-band device attestation actually ran. An attacker who can reach such a stage 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.