CWE-289
AllowedAuthentication Bypass by Alternate Name
Abstraction: Base · Status: Incomplete
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
81 vulnerabilities reference this CWE, most recent first.
GHSA-XR73-JQ5P-CH8R
Vulnerability from github – Published: 2025-11-19 18:13 – Updated: 2025-11-19 18:59Summary
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.
return request.user.is_active
For more information
If you have any questions or comments about this advisory:
- Email us at security@goauthentik.io.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "goauthentik.io"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20251119140106-9dbdfc3f1be0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64521"
],
"database_specific": {
"cwe_ids": [
"CWE-286",
"CWE-289"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-19T18:13:03Z",
"nvd_published_at": "2025-11-19T17:15:52Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen 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.\n\n### Patches\n\nauthentik 2025.8.5 and 2025.10.2 fix this issue, for other versions the workaround below can be used.\n\n### Workarounds\n\nYou can add a policy to your application that explicitly checks if the service account is still valid, and deny access if not.\n\n```python\nreturn request.user.is_active\n```\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Email us at [security@goauthentik.io](mailto:security@goauthentik.io).",
"id": "GHSA-xr73-jq5p-ch8r",
"modified": "2025-11-19T18:59:53Z",
"published": "2025-11-19T18:13:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/goauthentik/authentik/security/advisories/GHSA-xr73-jq5p-ch8r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64521"
},
{
"type": "WEB",
"url": "https://github.com/goauthentik/authentik/commit/9dbdfc3f1be0f1be36f8efce2442897b2a54a71c"
},
{
"type": "PACKAGE",
"url": "https://github.com/goauthentik/authentik"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "authentik allows a deactivated Service account to authenticate to OAuth"
}
Mitigation MIT-44
Strategy: Input Validation
Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-20
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
No CAPEC attack patterns related to this CWE.