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.
64 vulnerabilities reference this CWE, most recent first.
GHSA-QWC9-Q2F8-Q72Q
Vulnerability from github – Published: 2026-08-02 00:31 – Updated: 2026-08-02 00:31The WooCommerce - Social Login plugin for WordPress is vulnerable to Authentication Bypass in all versions up to and including 2.8.7. This is due to the plugin's Apple login handler accepting the Apple id_token and decoding only its base64 payload without verifying the JWT signature against Apple's public keys or validating the issuer, audience, or expiry claims, combined with the security nonce required to invoke the login flow being publicly exposed to unauthenticated users via a localized JavaScript object on the login page. This makes it possible for unauthenticated attackers to log in as any existing WordPress user — including administrators — by supplying a forged id_token whose payload contains the target user's email address, as that email is used without any role exclusion to resolve a WordPress account and immediately issue an authenticated session for it.
{
"affected": [],
"aliases": [
"CVE-2026-8457"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-02T00:16:23Z",
"severity": "CRITICAL"
},
"details": "The WooCommerce - Social Login plugin for WordPress is vulnerable to Authentication Bypass in all versions up to and including 2.8.7. This is due to the plugin\u0027s Apple login handler accepting the Apple id_token and decoding only its base64 payload without verifying the JWT signature against Apple\u0027s public keys or validating the issuer, audience, or expiry claims, combined with the security nonce required to invoke the login flow being publicly exposed to unauthenticated users via a localized JavaScript object on the login page. This makes it possible for unauthenticated attackers to log in as any existing WordPress user \u2014 including administrators \u2014 by supplying a forged id_token whose payload contains the target user\u0027s email address, as that email is used without any role exclusion to resolve a WordPress account and immediately issue an authenticated session for it.",
"id": "GHSA-qwc9-q2f8-q72q",
"modified": "2026-08-02T00:31:06Z",
"published": "2026-08-02T00:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8457"
},
{
"type": "WEB",
"url": "https://codecanyon.net/item/social-login-wordpress-woocommerce-plugin/8495883"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/53e83037-2cc5-4dc9-b55d-03829df12a65?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XFV7-H2QG-RJM7
Vulnerability from github – Published: 2024-11-20 12:30 – Updated: 2024-11-20 21:45A flaw was found in Moodle. When restricting access to a lesson activity with a password, certain passwords could be bypassed or less secure due to a loose comparison in the password-checking logic. This issue only affected passwords set to "magic hash" values.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0-beta"
},
{
"fixed": "4.2.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0-beta"
},
{
"fixed": "4.3.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.4.0-beta"
},
{
"fixed": "4.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45691"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-289"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-20T18:25:26Z",
"nvd_published_at": "2024-11-20T11:15:05Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Moodle. When restricting access to a lesson activity with a password, certain passwords could be bypassed or less secure due to a loose comparison in the password-checking logic. This issue only affected passwords set to \"magic hash\" values.",
"id": "GHSA-xfv7-h2qg-rjm7",
"modified": "2024-11-20T21:45:02Z",
"published": "2024-11-20T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45691"
},
{
"type": "WEB",
"url": "https://github.com/moodle/moodle/commit/3fc1073d304f660d2552b591c5fb92547ed01e92"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2309940"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=461897#p1854494"
},
{
"type": "WEB",
"url": "https://moodle.org/security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Moodle Lesson activity password bypass through PHP loose comparison"
}
GHSA-XHV7-44RM-J43C
Vulnerability from github – Published: 2026-07-30 18:31 – Updated: 2026-07-30 18:31IBM WebSphere Application Server 8.5, and 9.0 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.7 Traditional and Liberty could allow a remote attacker to bypass security constraints.
{
"affected": [],
"aliases": [
"CVE-2026-10842"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T16:16:53Z",
"severity": "HIGH"
},
"details": "IBM WebSphere Application Server 8.5, and 9.0 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.7 Traditional and Liberty could allow a remote attacker to bypass security constraints.",
"id": "GHSA-xhv7-44rm-j43c",
"modified": "2026-07-30T18:31:37Z",
"published": "2026-07-30T18:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10842"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7280131"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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.