authentik

authentik is an open-source identity provider. Versions 2025.12.4 and prior, and versions 2026.2.0-rc1 through 2026.2.2 were vulnerable to Authentication Bypass through SAML NameID XML Comment Injection. Due to how authentik extracted the NameID value from a SAML assertion, it was possible for an attacker to trick authentik into only seeing a part of the NameID value, potentially allowing an attacker to gain access to other accounts. This issue could be exploited on an authentik instance with a SAML Source, where the attacker had an account on the SAML Source and the ability to modify their NameID value (commonly username or E-mail), and XML Signing was enabled. The attacker could modify the SAML assertion given to authentik by injecting a comment within the NameID value, which effectively truncated the NameID value to the snippet before the comment, and gave the attacker access to any user account. This issue has been fixed in versions 2025.12.5 and 2026.2.3.

authentik is an open-source identity provider. Prior to 2025.8.6, 2025.10.4, and 2025.12.4, when using a SAML Source that has the option Verify Assertion Signature under Verification Certificate enabled and not Verify Response Signature, or does not have the Encryption Certificate setting under Advanced Protocol settings configured, it was possible for an attacker to inject a malicious assertion before the signed assertion that authentik would use instead. authentik 2025.8.6, 2025.10.4, and 2025.12.4 fix this issue.

authentik is an open-source identity provider. Prior to 2025.10.4 and 2025.12.4, with a malformed cookie it was possible to bypass authentication when using forward authentication in the authentik Proxy Provider when used in conjunction with Traefik or Caddy as reverse proxy. When a malicious cookie was used, none of the authentik-specific X-Authentik-* headers were set which depending on application can grant access to an attacker. authentik 2025.10.4 and 2025.12.4 fix this issue.

authentik is an open-source identity provider. From 2021.3.1 to before 2025.8.6, 2025.10.4, and 2025.12.4, when using delegated permissions, a User that has the permission Can view * Property Mapping or Can view Expression Policy is able to execute arbitrary code within the authentik server container through the test endpoint, which is intended to preview how a property mapping/policy works. authentik 2025.8.6, 2025.10.4, and 2025.12.4 fix this issue.

authentik is an open-source Identity Provider. Prior to versions 2025.8.5 and 2025.10.2, in previous authentik versions, invitations were considered valid regardless if they are expired or not, thus relying on background tasks to clean up expired ones. In a normal scenario this can take up to 5 minutes because the cleanup of expired objects is scheduled to run every 5 minutes. However, with a large amount of tasks in the backlog, this might take longer. authentik versions 2025.8.5 and 2025.10.2 fix this issue. A workaround involves creating a policy that explicitly checks whether the invitation is still valid, and then bind it to the invitation stage on the invitation flow, and denying access if the invitation is not valid.

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.

authentik is an open-source Identity Provider that emphasizes flexibility and versatility, with support for a wide set of protocols. In versions 2025.4.4 and earlier, as well as versions 2025.6.0-rc1 through 2025.6.3, deactivated users who registered through OAuth/SAML or linked their accounts to OAuth/SAML providers can still retain partial access to the system despite their accounts being deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application. To workaround this issue, developers can add an expression policy to the user login stage on the respective authentication flow with the expression of return request.context["pending_user"].is_active. This modification ensures that the return statement only activates the user login stage when the user is active. This issue is fixed in versions authentik 2025.4.4 and 2025.6.4.

authentik is an open-source identity provider. After authorizing access to a RAC endpoint, authentik creates a token which is used for a single connection and is sent to the client in the URL. This token is intended to only be valid for the session of the user who authorized the connection, however this check is missing in versions prior to 2025.6.3 and 2025.4.3. When, for example, using RAC during a screenshare, a malicious user could access the same session by copying the URL from the shown browser. authentik 2025.4.3 and 2025.6.3 fix this issue. As a workaround, it is recommended to decrease the duration a token is valid for (in the RAC Provider settings, set Connection expiry to `minutes=5` for example). The maintainers of authentik also recommend enabling the option Delete authorization on disconnect.