authentik is an open-source identity provider. Prior to 2026.2.6 and 2026.5.5, the enterprise Google Chrome device-trust stages advance the flow without confirming that the out-of-band device attestation actually ran. Affected enterprise deployments place either a Google Chrome Endpoint stage with mode set to REQUIRED or the deprecated Google Chrome Device Trust Connector stage in an authentication flow. The device attestation occurs in a verification iframe that calls the Google Verified Access API and records the verified device on success, but the vulnerable stages treat the flow as passed as soon as the stage is submitted. An attacker who can reach such a stage, including after primary username and password authentication, 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, while other configured factors remain in force. This issue is fixed in versions 2026.2.6 and 2026.5.5.

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. In versions prior to 2025.12.5 and 2026.2.0-rc1 through 2026.2.2, the PATCH /api/v3/core/users/{pk}/ API allows a caller with changeuser on a target user to assign arbitrary groups through UserSerializer, including groups with issuperuser=True, without requiring enablegroupsuperuser, leading to privilege escalation. This bypasses the stricter permission model enforced in group-management paths and enables delegated user-management permissions to escalate target users to administrator-equivalent privilege. Users with permissions to update groups or permissions to update users are able to add themselves or other users they have permissions on to users which have superuser permissions. This issue has been fixed in versions 22025.12.5 and 2026.2.3.

authentik is an open-source identity provider. In versions prior to 2025.12.5 and 2026.2.0-rc1 through 2026.2.2, authenticated non-admin users with at least one OAuth2 access token can retrieve the clientsecret of confidential OAuth2 providers they have previously authenticated against, exposing sensitive information to users without the correct permissions. This logic is GET /api/v3/oauth2/accesstokens/. The API response includes a nested provider object containing clientid and clientsecret for providers configured with clienttype: confidential, which should not be accessible to low-privilege users. This issue has been fixed in versions 2025.12.5 and 2026.2.3.

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.

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.

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.

Hello list,

this report is about a remote timing attack in Authentik [1]. Authentik is a popular open source identity provider that can be self-hosted. SUSE IT is considering to use this software internally in the future and thus we have been asked to have a look at its security.

The Authentik version we examined was 2024.8.3. Beyond the finding in this report, we also discovered the possibility to access SSL private keys without authentication, but this was independently discovered and fixed in parallel [2] by upstream before we had a chance to report it. The only CVE-worthy finding that was left is discussed in the next section. Some general insights into the security of Authentik are given in section 2).

We also offer a rendered version of this report on our blog in [3].

1) Vulnerability Details ========================

The MetricsView, reachable via URL "/-/metrics/", implements HTTP basic auth in "authentik/root/monitoring.py:27" [4]. The expected username is hard-coded to be monitor. The expected password is the constant settings.SECRETKEY, which is the same as the AUTHENTIKSECRETKEY, generated when setting up Authentik. According to documentation it is used for cookie signing and in older versions also for "unique user IDs".

To verify the password, the implementation uses the regular Python "==" string comparison operator. This operator will optimize the string comparison, making it likely possible to employ timing attacks to guess the correct SECRETKEY. Security research has repeatedly shown that timing attacks are a realistic danger, even over the network.

Exploiting this vulnerability is likely complex, but a determined attacker might be able to develop a successful approach. We did not look in more detail into how to exploit the issue.

Upstream published a security advisory [5] and provides fixes for this issue in versions 2024.10.3 and 2024.8.5. It is also possible to employ a workaround by making the affected API endpoint inaccessible for remote users.

2) Review Summary =================

Authentik is a big project consisting of about 10,000 lines of Golang code and nearly 100,000 lines of Python code. It uses various web frameworks and a rather complex set of abstractions. Reviewing this in full with our limited resources is impossible. Thus we concentrated on inspecting the accessible REST API endpoints and tried to get a general feel for the robustness of the software.

The web frameworks and development style used in Authentik result in pretty robust REST API endpoints. Even when issues are found, the upstream project shows that it is well organized and manages to fix them quickly and transparently.

The sheer amount of features supported by Authentik in terms of network protocols, authentication mechanisms etc. is big and results in a level of complexity that is hard to manage. Keeping track of the interactions of all these features with client and third party systems is a challenge. Authentik also implements a complex permission framework of over 500 different privileges for controlling access to the system. We suggest to train administrators of such systems well to avoid that issues are introduced through bad configuration of the system.

A bit of a problematic area that we identified in Authentik is its deployment. It only offers Docker-Compose or Kubernetes based installation. No official bare-metal installation support exists. The minimum setup requires four containers that are connected via an isolated network. One container is running the Postgres database, one is running the Redis in-memory key/value store, another one is running the actual Authentik server components and an "Authentik Worker" container is running the celeryd task scheduler. We looked into the containers and noted the following aspects:

Two of the containers (Postgres and Redis) are based on Alpine Linux and the other two (Authentik Server and Worker) are based on Debian Linux. The local security within some of these containers is not fully maintained, e.g. in the Authentik Server container there exist globally accessible IPC sockets and unsafe temporary file permissions in /dev/shm. This means that the local security is only based on the container isolation. As soon as an attacker is able to run code in this container, there is little defense-in-depth. The file system hierarchy standard is violated in some of the containers, the / directory is cluttered with proprietary Authentik directories. A custom Python installation is placed there, for example.

Consequently, one must not only consider the security of Authentik itself, but also the security of at least four different Linux containers running two different Linux distributions and the customized Python stacks involved etc. Users have to rely on Authentik upstream to properly maintain the security of these components.

Offering a bare-metal installation could address the concerns in this area. Individual services on modern Linux can still benefit from isolation features (e.g. via protection settings in systemd service units [6]), while the system packages and distribution security are transparent and under full control of the Admin. Of course this likely makes things more complex for the upstream developers, when they no longer have full control of the Linux environment that Authentik is running in.

3) Timeline ===========

2024-10-25: We reported the finding to <security () goauthentik io>, offering coordinated disclosure. 2024-10-28: Upstream replied and confirmed the issue. 2024-11-13: Upstream obtained a CVE and informed us they would publish the issue within a week. 2024-11-21: Upstream published fixes and a security advisory [5].

4) References =============

[1]: https://github.com/goauthentik/authentik [2]: https://github.com/goauthentik/authentik/security/advisories/GHSA-qxqc-27pr-wgc8 [3]: https://security.opensuse.org/2024/11/26/authentik-timing-attack.html [4]: https://github.com/goauthentik/authentik/blob/fd1d252d44a010fad558bed2d315577a9d8d1f2b/authentik/root/monitoring.py#L27 [5]: https://github.com/goauthentik/authentik/security/advisories/GHSA-2xrw-5f2x-m56j [6]: https://documentation.suse.com/smart/security/html/systemd-securing/index.html

Regards

Matthias

-- Matthias Gerstner <matthias.gerstner () suse de> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

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.

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.