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.

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 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.

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 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 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.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.

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. Prior to versions 2023.4.3 and 2023.5.5, authentik does not verify the source of the X-Forwarded-For and X-Real-IP headers, both in the Python code and the go code. Only authentik setups that are directly accessible by users without a reverse proxy are susceptible to this. Possible spoofing of IP addresses in logs, downstream applications proxied by (built in) outpost, IP bypassing in custom flows if used.

This poses a possible security risk when someone has flows or policies that check the user's IP address, e.g. when they want to ignore the user's 2 factor authentication when the user is connected to the company network. A second security risk is that the IP addresses in the logfiles and user sessions are not reliable anymore. Anybody can spoof this address and one cannot verify that the user has logged in from the IP address that is in their account's log. A third risk is that this header is passed on to the proxied application behind an outpost. The application may do any kind of verification, logging, blocking or rate limiting based on the IP address, and this IP address can be overridden by anybody that want to.

Versions 2023.4.3 and 2023.5.5 contain a patch for 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 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. 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.

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

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.

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 \..

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. 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.

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. 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. 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 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. 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 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.

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 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.

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. Versions prior to 2022.11.2 and 2022.10.2 are vulnerable to unauthorized user creation and potential account takeover. With the default flows, unauthenticated users can create new accounts in authentik. If a flow exists that allows for email-verified password recovery, this can be used to overwrite the email address of admin accounts and take over their accounts. authentik 2022.11.2 and 2022.10.2 fix this issue. As a workaround, a policy can be created and bound to the default-user-settings-flow flow with the contents return request.user.isauthenticated.

authentik is an open-source Identity Provider focused on flexibility and versatility. Versions prior to 2022.11.4 and 2022.10.4 are vulnerable to Improper Authentication. Token reuse in invitation URLs leads to access control bypass via the use of a different enrollment flow than in the one provided. The vulnerability allows an attacker that knows different invitation flows names (e.g. enrollment-invitation-test and enrollment-invitation-admin) via either different invite links or via brute forcing to signup via a single invitation url for any valid invite link received (it can even be a url for a third flow as long as it's a valid invite) as the token used in the Invitations section of the Admin interface does NOT change when a different enrollment flow is selected via the interface and it is NOT bound to the selected flow, so it will be valid for any flow when used. This issue is patched in authentik 2022.11.4,2022.10.4 and 2022.12.0. Only configurations that use invitations and have multiple enrollment flows with invitation stages that grant different permissions are affected. The default configuration is not vulnerable, and neither are configurations with a single enrollment flow. As a workaround, fixed data can be added to invitations which can be checked in the flow to deny requests. Alternatively, an identifier with high entropy (like a UUID) can be used as flow slug, mitigating the attack vector by exponentially decreasing the possibility of discovering other flows.