authentik vulnerabilities

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, an account with delegated permission to manage a group, group membership, or a user can grant superuser status or assign an existing role to a group without holding the required permissions. Group hierarchy checks do not consistently account for inherited superuser status, and role assignment to a group lacks authorization checks.

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.

A privilege escalation vulnerability in Authentik through 2026.5.6 allows an attacker with a source-scoped SCIM provisioning token to take over any user account including superusers by provisioning a SCIM user that matches an existing local user by username. The SCIM user ingest function adopts pre-existing local accounts by username without validating scope boundaries.

A privilege escalation vulnerability in Authentik Security authentik through 2026.5.6 allows an attacker with a source-scoped SCIM provisioning token to gain superuser privileges by provisioning a SCIM group that matches an existing administrator group by name. The SCIM group ingest function adopts any existing group by name and replaces its membership without validating the source scope against the target group.

authentik is an open-source identity provider. Prior to versions 2025.12.6, 2026.2.4, and 2026.5.1, an attacker with the ability to change a source connection and an account in one of the configured sources can log into any account.

authentik, an open-source identity provider, prior to versions 2025.12.5, 2026.2.3, and 2026.5.1, is vulnerable to XML Signature Wrapping in the SAML Source ACS endpoint when validating upstream SAML responses. An attacker with any account at the upstream IdP can reuse a valid signed assertion to authenticate as another federated user.

In authentik before version 2026.2.3, the WS-Federation provider validates the wreply parameter using a raw string prefix check rather than proper URL parsing. An attacker can craft a login link with a wreply on a different origin that passes the check, causing the login response to be sent to attacker-controlled infrastructure.

authentik is an open-source identity provider. Prior to versions 2025.12.5 and 2026.2.3, the SAML source response processor (ResponseProcessor.parse()) does not validate the Conditions element on assertions. NotBefore, NotOnOrAfter, and AudienceRestriction are all ignored. This allows replay of expired assertions and acceptance of assertions intended for other service providers.

In authentik prior to versions 2025.12.5 and 2026.2.3, the PATCH /api/v3/core/users/{pk}/ API allows a caller with change_user permission to assign arbitrary groups, including groups with is_superuser=True, without requiring enable_group_superuser, leading to privilege escalation.

In authentik prior to versions 2025.12.5 and 2026.2.3, authenticated non-admin users with at least one OAuth2 access token can retrieve the client_secret of confidential OAuth2 providers they have previously authenticated against. This occurs via the GET /api/v3/oauth2/access_tokens/ API, which returns a nested provider object containing client_id and client_secret for providers with client_type: confidential.

Vulnerability in authentik (open-source identity provider) in versions up to 2025.12.4 and 2026.2.0-rc1 through 2026.2.2. An attacker can bypass authentication via SAML NameID XML Comment Injection, allowing access to other accounts if the attacker has an account on the SAML source and can modify NameID.

authentik is an open-source Identity Provider. Prior to versions 2025.8.5 and 2025.10.2, invitations were considered valid regardless of expiration, relying on background tasks to clean up expired ones, which can take up to 5 minutes or longer with a large backlog.

authentik is an open-source Identity Provider. Prior to versions 2025.8.5 and 2025.10.2, when authenticating with client_id and client_secret to an OAuth provider, authentik creates a service account for the provider. In previous authentik versions, authentication for this account was possible even when the account was deactivated. Other permissions are correctly applied and federation with other providers still take assigned policies correctly into account. authentik versions 2025.8.5 and 2025.10.2 fix this issue. A workaround involves adding a policy to the application that explicitly checks if the service account is still valid, and deny access if not.

In versions prior to 2023.4.3 and 2023.5.5, authentik does not verify the source of the X-Forwarded-For and X-Real-IP headers, which may lead to IP address spoofing in logs and downstream applications. Only authentik setups directly accessible by users are susceptible to this vulnerability.