authentik is an open-source identity provider. Prior to 2026.2.6 and 2026.5.5, an inbound SAML Source configured with the non-default USERNAMELINK or EMAILLINK user-matching mode interprets an XML comment in a NameID differently from the identity provider's signed assertion. An attacker with an account on the source identity provider who can set the account's NameID can inject an XML comment that truncates the value used by authentik to the text before the comment while the signed assertion remains valid. A crafted NameID can therefore truncate to a victim's username or email and bind the attacker's external identity to the victim's existing account. This grants full takeover without the victim's password or the identity provider's private key, and the malicious link persists so later logins succeed without the comment. Sources using the default unique-identifier matching mode and authentik's outbound SAML Provider role are not affected. This issue is fixed in versions 2026.2.6 and 2026.5.5.

authentik is an open-source identity provider. Prior to 2026.2.6 and 2026.5.5, the Remote Access Control endpoint list returns every configured endpoint to any authenticated user regardless of which applications the user may access, and the response includes connection settings that can contain stored credentials. The endpoint listing does not apply the access controls governing the endpoints, and the connection flow does not confirm that an endpoint belongs to the Remote Access Control application through which it was launched. Any authenticated user can therefore read every endpoint together with its host and stored credentials and can open a connection to an endpoint belonging to another application. This exposes stored credentials for managed RDP, SSH, and VNC targets and grants interactive access to systems the user was never authorized to reach. Deployments that do not use the enterprise Remote Access Control provider are not affected. This issue is fixed in versions 2026.2.6 and 2026.5.5.

authentik is an open-source identity provider. Prior to versions 2025.12.6, 2026.2.4, and 2026.5.1, the Source stage can be bypassed by sending an empty POST. This issue has been patched in versions 2025.12.6, 2026.2.4, and 2026.5.1.

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. This issue has been patched in versions 2025.12.6, 2026.2.4, and 2026.5.1.

authentik is an open-source identity provider. Prior to versions 2025.12.5 and 2026.2.3, due to the implementation of stages in the SFE (Simple Flow Executor) in order to make the interface more compatible with legacy browsers, it was possible to use an XSS exploit in the AutosubmitStage. This issue has been patched in versions 2025.12.5 and 2026.2.3.

authentik is an open-source identity provider. Prior to version 2026.2.3, the WS-Federation provider validates the user-supplied wreply parameter using a raw string prefix check rather than proper URL parsing. An attacker who can craft a login link can supply a wreply value on a different origin that passes the check (e.g. https://portal.example.com.evil.tld/), causing the victim's browser to POST the signed WS-Federation login response to attacker-controlled infrastructure. This issue has been patched in version 2026.2.3.

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. This issue has been patched in versions 2025.12.5 and 2026.2.3.

Summary authentik's SAML Source ACS endpoint is vulnerable to XML Signature Wrapping 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. ### Patches authentik 2026.5.1, 2026.2.4 and 2025.12.6 fix this issue. ### Impact Affected: authentik deployments using a SAML Source for upstream SAML federation with signed assertions, or signed responses without signed assertions. Not affected: deployments that do not use SAML Source for upstream SAML federation. The SAML Source trusts that the verified XML signature belongs to the assertion or response that authentik later consumes. A crafted SAML response can make signature verification succeed against the attacker's original signed assertion while authentik reads identity data from a different forged assertion. An attacker first completes a legitimate login to the upstream IdP and captures the signed SAML response sent through their browser. They then submit a modified response to the ACS endpoint where the valid signature still verifies, but the consumed assertion contains a victim identifier or attacker-chosen attributes. The attacker can authenticate as a victim who has previously used the SAML Source, or as a local user matched by forged email or username when those matching modes are enabled. ### Workarounds Disable affected SAML Sources, or block access to their ACS endpoints. ### For more information If there are any questions or comments about this advisory: - Send an email to security@goauthentik.io

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.

Summary

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.

Patches

authentik 2025.8.5 and 2025.10.2 fix this issue; for other versions the workaround below can be used.

Workarounds

Users can create a policy that explicitly checks whether the invitation is still valid, and then bind it to the invitation stage on your invitation flow, and deny access if the invitation is not valid.

python return not context['flowplan'].context['invitation'].isexpired

For more information

If users have any questions or comments about this advisory:

- Email the authentik team at security@goauthentik.io.

Summary

When authenticating with clientid and clientsecret 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.

Patches

authentik 2025.8.5 and 2025.10.2 fix this issue, for other versions the workaround below can be used.

Workarounds

You can add a policy to your application that explicitly checks if the service account is still valid, and deny access if not.

python return request.user.isactive

For more information

If you have any questions or comments about this advisory:

- Email us at security@goauthentik.io.

Summary

Deactivated users that had either enrolled via OAuth/SAML or had their account connected to an OAuth/SAML account can still partially access authentik even if their account is 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.

Patches

authentik 2025.4.4 and 2025.6.4 fix this issue.

Workarounds

Adding an expression policy to the user login stage on the respective authentication flow with the expression of

py return request.context["pendinguser"].isactive

This expression will only activate the user login stage when the user is active.

For more information

If you have any questions or comments about this advisory:

- Email us at security@goauthentik.io.

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.

authentik is an open-source identity provider. Prior to versions 2024.12.4 and 2025.2.3, when authentik was configured to use the database for session storage (which is a non-default setting), deleting sessions via the Web Interface or the API would not revoke the session and the session holder would continue to have access to authentik. authentik 2025.2.3 and 2024.12.4 fix this issue. Switching to the cache-based session storage until the authentik instance can be upgraded is recommended. This will however also delete all existing sessions and users will have to re-authenticate.

Authentik project is vulnerable to Stored XSS attacks through uploading crafted SVG files that are used as application icons.  This action could only be performed by an authenticated admin user. The issue was fixed in 2024.10.4 release.

authentik is an open-source identity provider. When using the clientcredentials or devicecode OAuth grants, it was possible for an attacker to get a token from authentik with scopes that haven't been configured in authentik. authentik 2024.8.5 and 2024.10.3 fix this issue.

authentik is an open-source identity provider. Redirect URIs in the OAuth2 provider in authentik are checked by RegEx comparison. When no Redirect URIs are configured in a provider, authentik will automatically use the first redirecturi value received as an allowed redirect URI, without escaping characters that have a special meaning in RegEx. Similarly, the documentation did not take this into consideration either. Given a provider with the Redirect URIs set to https://foo.example.com, an attacker can register a domain fooaexample.com, and it will correctly pass validation. authentik 2024.8.5 and 2024.10.3 fix this issue. As a workaround, When configuring OAuth2 providers, make sure to escape any wildcard characters that are not intended to function as a wildcard, for example replace . with \..

authentik is an open-source identity provider. Due to the usage of a non-constant time comparison for the /-/metrics/ endpoint it was possible to brute-force the SECRETKEY, which is used to authenticate the endpoint. The /-/metrics/ endpoint returns Prometheus metrics and is not intended to be accessed directly, as the Go proxy running in the authentik server container fetches data from this endpoint and serves it on a separate port (9300 by default), which can be scraped by Prometheus without being exposed publicly. authentik 2024.8.5 and 2024.10.3 fix this issue. Since the /-/metrics/ endpoint is not intended to be accessed publicly, requests to the endpoint can be blocked by the reverse proxy/load balancer used in conjunction with authentik.

authentik is an open-source identity provider. Prior to versions 2024.8.3 and 2024.6.5, access tokens issued to one application can be stolen by that application and used to impersonate the user against any other proxy provider. Also, a user can steal an access token they were legitimately issued for one application and use it to access another application that they aren't allowed to access. Anyone who has more than one proxy provider application with different trust domains or different access control is affected. Versions 2024.8.3 and 2024.6.5 fix the issue.

authentik is an open-source identity provider. A vulnerability that exists in versions prior to 2024.8.3 and 2024.6.5 allows bypassing password login by adding X-Forwarded-For header with an unparsable IP address, e.g. a. This results in a possibility of logging into any account with a known login or email address. The vulnerability requires the authentik instance to trust X-Forwarded-For header provided by the attacker, thus it is not reproducible from external hosts on a properly configured environment. The issue occurs due to the password stage having a policy bound to it, which skips the password stage if the Identification stage is setup to also contain a password stage. Due to the invalid X-Forwarded-For header, which does not get validated to be an IP Address early enough, the exception happens later and the policy fails. The default blueprint doesn't correctly set failureresult to True on the policy binding meaning that due to this exception the policy returns false and the password stage is skipped. Versions 2024.8.3 and 2024.6.5 fix this issue.

Summary

Several API endpoints can be accessed by users without correct authentication/authorization.

The main API endpoints affected by this:

- /api/v3/crypto/certificatekeypairs/<uuid>/viewcertificate/ - /api/v3/crypto/certificatekeypairs/<uuid>/viewprivatekey/ - /api/v3/.../usedby/

Note that all of the affected API endpoints require the knowledge of the ID of an object, which especially for certificates is not accessible to an unprivileged user. Additionally the IDs for most objects are UUIDv4, meaning they are not easily guessable/enumerable.

Patches

authentik 2024.4.4, 2024.6.4 and 2024.8.0 fix this issue.

Workarounds

Access to the API endpoints can be blocked at a Reverse-proxy/Load balancer level to prevent this issue from being exploited.

For more information

If you have any questions or comments about this advisory:

- Email us at security@goauthentik.io

authentik is an open-source Identity Provider. Access restrictions assigned to an application were not checked when using the OAuth2 Device code flow. This could potentially allow users without the correct authorization to get OAuth tokens for an application and access it. This issue has been patched in version(s) 2024.6.0, 2024.2.4 and 2024.4.3.

authentik is an open-source Identity Provider that emphasizes flexibility and versatility. Authentik API-Access-Token mechanism can be exploited to gain admin user privileges. A successful exploit of the issue will result in a user gaining full admin access to the Authentik application, including resetting user passwords and more. This issue has been patched in version(s) 2024.2.4, 2024.4.2 and 2024.6.0.

Summary

PKCE is a very important countermeasure in OAuth2 , both for public and confidential clients. It protects against CSRF attacks and code injection attacks. Because of this bug, an attacker can circumvent the protection PKCE offers.

Patches

authentik 2023.8.7 and 2023.10.7 fix this issue.

Details

There is a bug in our implementation of PKCE that allows an attacker to circumvent the protection that PKCE offers. PKCE adds the codechallenge’ parameter to the authorization request and adds the codeverifier’ parameter to the token request. We recently fixed a downgrade attack (in v2023.8.5 and 2023.10.4) where if the attacker removed the codeverifier’ parameter in the token request, authentik would allow the request to pass, thus circumventing PKCE’s protection. However, in the latest version of the software, another downgrade scenario is still possible: if the attacker removes the codechallenge’ parameter from the authorization request, authentik will also not do the PKCE check.

Note that this type of downgrade enables an attacker to perform a code injection attack, even if the OAuth client is using PKCE (which is supposed to protect against code injection attacks). To start the attack, the attacker must initiate the authorization process without that codechallenge’ parameter in the authorization request. But this is easy to do (just use a phishing site or email to trick the user into clicking on a link that the attacker controls – the authorization link without that codechallenge’ parameter).

The OAuth BCP (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) explicitly mentions this particular attack in section 2.1.1: “Authorization servers MUST mitigate PKCE Downgrade Attacks by ensuring that a token request containing a codeverifier parameter is accepted only if a codechallenge parameter was present in the authorization request, see Section 4.8.2 for details.”

For more information

If you have any questions or comments about this advisory:

- Email us at security@goauthentik.io

Authentik is an open-source Identity Provider. Authentik is a vulnerable to a reflected Cross-Site Scripting vulnerability via JavaScript-URIs in OpenID Connect flows with responsemode=formpost. This relatively user could use the described attacks to perform a privilege escalation. This vulnerability has been patched in versions 2023.10.6 and 2023.8.6.

authentik is an open-source identity provider. When initialising a oauth2 flow with a codechallenge and codemethod (thus requesting PKCE), the single sign-on provider (authentik) must check if there is a matching and existing codeverifier during the token step. Prior to versions 2023.10.4 and 2023.8.5, authentik checks if the contents of codeverifier is matching only when it is provided. When it is left out completely, authentik simply accepts the token request with out it; even when the flow was started with a codechallenge. authentik 2023.8.5 and 2023.10.4 fix this issue.

authentik is an open-source Identity Provider. Prior to versions 2023.8.4 and 2023.10.2, when the default admin user has been deleted, it is potentially possible for an attacker to set the password of the default admin user without any authentication. authentik uses a blueprint to create the default admin user, which can also optionally set the default admin users' password from an environment variable. When the user is deleted, the initial-setup flow used to configure authentik after the first installation becomes available again. authentik 2023.8.4 and 2023.10.2 fix this issue. As a workaround, ensure the default admin user (Username akadmin) exists and has a password set. It is recommended to use a very strong password for this user, and store it in a secure location like a password manager. It is also possible to deactivate the user to prevent any logins as akadmin.

Summary Using a recovery flow with an identification stage an attacker is able to determine if a username exists.

Impact Only setups configured with a recovery flow are impacted by this. Anyone with a user account on a system with the recovery flow described above is susceptible to having their username/email revealed as existing.

Details

An attacker can easily enumerate and check users' existence using the recovery flow, as a clear message is shown when a user doesn't exist. Depending on configuration this can either be done by username, email, or both.

The invalid and valid usernames should both show the same message and always send an email. Article for reference here: https://postmarkapp.com/guides/password-reset-email-best-practices#how-to-make-sure-your-password-reset-emails-are-secure

For more information

If you have any questions or comments about this advisory:

- Email us at security@goauthentik.io