authentik deactivated service accounts can authenticate to OAuth
Description
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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In authentik, deactivated OAuth service accounts could still authenticate via client credentials; fixed in versions 2025.8.5 and 2025.10.2.
Vulnerability
The vulnerability is an authorization bypass in authentik's OAuth2 provider. When using the client credentials grant type, authentik creates a service account for the provider. In versions prior to 2025.8.5 and 2025.10.2, the authentication check did not verify whether the service account was active, allowing deactivated accounts to obtain tokens [1][4].
Exploitation
Exploitation requires knowledge of a deactivated service account's client_id and client_secret. An attacker with valid credentials for a deactivated account can authenticate and receive an OAuth token, bypassing the intended deactivation [2]. The fix adds a filter for is_active=True in the user lookup during token generation [2].
Impact
The impact is that deactivated service accounts remain usable, violating the principle of least privilege and potentially allowing continued access for accounts that should be disabled. Other policies and permissions are correctly applied, so federation and other checks still work [1].
Mitigation
The issue is patched in authentik versions 2025.8.5 and 2025.10.2 [4]. As a workaround, administrators can add a policy to applications that explicitly checks request.user.is_active to deny access for deactivated accounts [4].
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
goauthentik.ioGo | < 0.0.0-20251119140106-9dbdfc3f1be0 | 0.0.0-20251119140106-9dbdfc3f1be0 |
Affected products
2- goauthentik/authentikv5Range: < 2025.10.2
Patches
19dbdfc3f1be0internal: Automated internal backport: 1498-oauth2-cc-user-active.sec.patch to authentik-main (#18265)
3 files changed · +50 −1
authentik/providers/oauth2/tests/test_token_cc_user_pw.py+24 −0 modified@@ -126,6 +126,30 @@ def test_no_provider(self): }, ) + def test_deactivate(self): + """test deactivated user""" + self.user.is_active = False + self.user.save() + response = self.client.post( + reverse("authentik_providers_oauth2:token"), + { + "grant_type": GRANT_TYPE_CLIENT_CREDENTIALS, + "scope": SCOPE_OPENID, + "client_id": self.provider.client_id, + "username": "sa", + "password": self.token.key, + }, + ) + self.assertEqual(response.status_code, 400) + self.assertJSONEqual( + response.content.decode(), + { + "error": "invalid_grant", + "error_description": TokenError.errors["invalid_grant"], + "request_id": response.headers["X-authentik-id"], + }, + ) + def test_permission_denied(self): """test permission denied""" group = Group.objects.create(name="foo")
authentik/providers/oauth2/views/token.py+1 −1 modified@@ -336,7 +336,7 @@ def __post_init_client_credentials_creds( self, request: HttpRequest, username: str, password: str ): # Authenticate user based on credentials - user = User.objects.filter(username=username).first() + user = User.objects.filter(username=username, is_active=True).first() if not user: raise TokenError("invalid_grant") token: Token = Token.filter_not_expired(
website/docs/security/cves/CVE-2025-64521.md+25 −0 added@@ -0,0 +1,25 @@ +# CVE-2025-64521 + +## Deactivated service account can authenticate to OAuth + +### Summary + +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. + +### 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.is_active +``` + +### For more information + +If you have any questions or comments about this advisory: + +- Email us at [security@goauthentik.io](mailto:security@goauthentik.io).
Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4- github.com/advisories/GHSA-xr73-jq5p-ch8rghsaADVISORY
- nvd.nist.gov/vuln/detail/CVE-2025-64521ghsaADVISORY
- github.com/goauthentik/authentik/commit/9dbdfc3f1be0f1be36f8efce2442897b2a54a71cghsax_refsource_MISCWEB
- github.com/goauthentik/authentik/security/advisories/GHSA-xr73-jq5p-ch8rghsax_refsource_CONFIRMWEB
News mentions
0No linked articles in our index yet.