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.
60 vulnerabilities reference this CWE, most recent first.
GHSA-487P-QX68-5VJW
Vulnerability from github – Published: 2024-01-02 16:40 – Updated: 2024-11-22 17:59Impact
All Hail Batch clusters are affected. An attacker is able to:
- Create one or more accounts with Hail Batch without corresponding real accounts in the organization.
For example, a user could create a Microsoft or Google account and then change their email to "inconspicuous@example.org". This Microsoft or Google account can then be used to create a Hail Batch account in Hail Batch clusters whose organization domain is "example.org".
In Google, this attack is partially mitigated because Google requires users to verify ownership of their Google account. However, a valid user is able to create multiple distinct Hail Batch accounts by creating multiple distinct Google accounts using email addresses of the form "real_user_email_name+random_id@example.org".
In Microsoft, this attack requires Azure AD Administrator access to an Azure AD Tenant. The Azure AD Administrator is permitted to change the email address of an account to any other email address without verification. An attacker can create an Azure Tenant for free.
- The attacker does not have access to any private data (because the new service principals or service accounts are not granted any privileges).
- If trial Hail Batch billing projects are enabled, the attacker does have the ability to run jobs and thus spend money. An attacker can create as many accounts as Microsoft or Google permit.
- The attacker cannot impersonate another user because, in Azure, we use the
subfrom the OAuth2 response, and, in Google, Google does an email verification.
Remediation
- Apply this patch to prevent third-party attackers from creating accounts.
- Audit your users list https://auth.example.org/users for user accounts whose login ids are not valid login ids with your identity provider. Delete such users.
A forthcoming change will prevent users from creating multiple accounts using Google's + email redirection.
Workarounds
None.
References
- https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/
- https://www.descope.com/blog/post/noauth
- https://developers.google.com/identity/openid-connect/openid-connect#an-id-tokens-payload
- https://learn.microsoft.com/en-us/entra/identity-platform/access-token-claims-reference#payload-claims
[1] Hail Batch must separately stop using emails and start using the OAuth2 sub in Google. This is a known deficiency. In particular, if an email is re-used by the organization for a new user, the new user could access the old user's Hail Batch account.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "hail"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.127"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-51663"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-02T16:40:58Z",
"nvd_published_at": "2023-12-29T17:16:07Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nAll Hail Batch clusters are affected. An attacker is able to:\n\n1. Create one or more accounts with Hail Batch without corresponding real accounts in the organization.\n\nFor example, a user could create a Microsoft or Google account and then change their email to \"inconspicuous@example.org\". This Microsoft or Google account can then be used to create a Hail Batch account in Hail Batch clusters whose organization domain is \"example.org\".\n\nIn Google, this attack is partially mitigated because Google requires users to verify ownership of their Google account. However, a valid user is able to create multiple distinct Hail Batch accounts by creating multiple distinct Google accounts using email addresses of the form \"real_user_email_name+random_id@example.org\".\n\nIn Microsoft, this attack requires Azure AD Administrator access to an Azure AD Tenant. The Azure AD Administrator is permitted to change the email address of an account to any other email address without verification. An attacker can create an Azure Tenant for free.\n\n1. The attacker *does not* have access to any private data (because the new service principals or service accounts are not granted any privileges).\n3. If trial Hail Batch billing projects are enabled, the attacker *does* have the ability to run jobs and thus spend money. An attacker can create as many accounts as Microsoft or Google permit.\n4. The attacker *cannot* impersonate another user because, in Azure, we use the `sub` from the OAuth2 response, and, in Google, Google does an email verification.\n\n### Remediation\n\n1. Apply this patch to prevent third-party attackers from creating accounts.\n2. Audit your users list https://auth.example.org/users for user accounts whose login ids are not valid login ids with your identity provider. Delete such users.\n\nA forthcoming change will prevent users from creating multiple accounts using Google\u0027s `+` email redirection.\n\n### Workarounds\nNone.\n\n### References\n1. https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/\n2. https://www.descope.com/blog/post/noauth\n4. https://developers.google.com/identity/openid-connect/openid-connect#an-id-tokens-payload\n5. https://learn.microsoft.com/en-us/entra/identity-platform/access-token-claims-reference#payload-claims\n\n[1] Hail Batch must separately stop using emails and start using the OAuth2 `sub` in Google. This is a known deficiency. In particular, if an email is re-used by the organization for a new user, the new user could access the old user\u0027s Hail Batch account.",
"id": "GHSA-487p-qx68-5vjw",
"modified": "2024-11-22T17:59:30Z",
"published": "2024-01-02T16:40:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hail-is/hail/security/advisories/GHSA-487p-qx68-5vjw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51663"
},
{
"type": "WEB",
"url": "https://github.com/hail-is/hail/commit/0dcc17ff24564b6f5592261d7975e8afd0f95de7"
},
{
"type": "PACKAGE",
"url": "https://github.com/hail-is/hail"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/hail/PYSEC-2023-271.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Hail relies on OIDC email claims to verify the validity of a user\u0027s domain."
}
GHSA-4CJ5-G32W-86FV
Vulnerability from github – Published: 2025-12-16 06:30 – Updated: 2026-04-02 15:31A flaw was found in Keycloak. An IDOR (Broken Access Control) vulnerability exists in the admin API endpoints for authorization resource management, specifically in ResourceSetService and PermissionTicketService. The system checks authorization against the resourceServer (client) ID provided in the API request, but the backend database lookup and modification operations (findById, delete) only use the resourceId. This mismatch allows an authenticated attacker with fine-grained admin permissions for one client (e.g., Client A) to delete or update resources belonging to another client (Client B) within the same realm by supplying a valid resource ID.
{
"affected": [],
"aliases": [
"CVE-2025-14777"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T05:16:11Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Keycloak. An IDOR (Broken Access Control) vulnerability exists in the admin API endpoints for authorization resource management, specifically in ResourceSetService and PermissionTicketService. The system checks authorization against the resourceServer (client) ID provided in the API request, but the backend database lookup and modification operations (findById, delete) only use the resourceId. This mismatch allows an authenticated attacker with fine-grained admin permissions for one client (e.g., Client A) to delete or update resources belonging to another client (Client B) within the same realm by supplying a valid resource ID.",
"id": "GHSA-4cj5-g32w-86fv",
"modified": "2026-04-02T15:31:34Z",
"published": "2025-12-16T06:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14777"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6477"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6478"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-14777"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2422596"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4J4Q-473W-9Q2R
Vulnerability from github – Published: 2026-05-20 03:31 – Updated: 2026-05-20 03:31Rsync version 3.4.2 and prior contain an authorization bypass vulnerability in the rsync daemon's hostname-based access control list enforcement when configured with chroot. Attackers can bypass hostname-based deny rules by controlling the PTR record for their source IP address, allowing connections from hostnames that administrators intended to deny when reverse DNS resolution fails and defaults to UNKNOWN.
{
"affected": [],
"aliases": [
"CVE-2026-43617"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-20T02:16:36Z",
"severity": "MODERATE"
},
"details": "Rsync version\u00a03.4.2 and prior contain an authorization bypass vulnerability in the rsync daemon\u0027s hostname-based access control list enforcement when configured with chroot. Attackers can bypass hostname-based deny rules by controlling the PTR record for their source IP address, allowing connections from hostnames that administrators intended to deny when reverse DNS resolution fails and defaults to UNKNOWN.",
"id": "GHSA-4j4q-473w-9q2r",
"modified": "2026-05-20T03:31:33Z",
"published": "2026-05-20T03:31:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/RsyncProject/rsync/security/advisories/GHSA-rjfm-3w2m-jf4f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43617"
},
{
"type": "WEB",
"url": "https://github.com/RsyncProject/rsync/releases/tag/v3.4.3"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/rsync-authorization-bypass-via-hostname-resolution"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-59GP-8F8P-CR76
Vulnerability from github – Published: 2025-10-09 21:31 – Updated: 2025-10-10 15:31The authentication mechanism in Perfex CRM before 3.3.1 allows attackers to bypass login credentials due to insufficient server-side validation. By sending empty username and password parameters in the login request, an attacker can gain unauthorized access to user accounts, including administrative accounts, without providing valid credentials.
{
"affected": [],
"aliases": [
"CVE-2025-60375"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-09T21:15:39Z",
"severity": "HIGH"
},
"details": "The authentication mechanism in Perfex CRM before 3.3.1 allows attackers to bypass login credentials due to insufficient server-side validation. By sending empty username and password parameters in the login request, an attacker can gain unauthorized access to user accounts, including administrative accounts, without providing valid credentials.",
"id": "GHSA-59gp-8f8p-cr76",
"modified": "2025-10-10T15:31:28Z",
"published": "2025-10-09T21:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60375"
},
{
"type": "WEB",
"url": "https://github.com/AhamedYaseen03/CVE-2025-60375"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-62WC-JJ78-F4F6
Vulnerability from github – Published: 2026-01-20 21:31 – Updated: 2026-06-30 03:35A flaw in Node.js’s Permissions model allows attackers to bypass --allow-fs-read and --allow-fs-write restrictions using crafted relative symlink paths. By chaining directories and symlinks, a script granted access only to the current directory can escape the allowed path and read sensitive files. This breaks the expected isolation guarantees and enables arbitrary file read/write, leading to potential system compromise.
This vulnerability affects users of the permission model on Node.js v20, v22, v24, and v25.
{
"affected": [],
"aliases": [
"CVE-2025-55130"
],
"database_specific": {
"cwe_ids": [
"CWE-281",
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-20T21:16:03Z",
"severity": "HIGH"
},
"details": "A flaw in Node.js\u2019s Permissions model allows attackers to bypass `--allow-fs-read` and `--allow-fs-write` restrictions using crafted relative symlink paths. By chaining directories and symlinks, a script granted access only to the current directory can escape the allowed path and read sensitive files. This breaks the expected isolation guarantees and enables arbitrary file read/write, leading to potential system compromise.\nThis vulnerability affects users of the permission model on Node.js v20, v22, v24, and v25.",
"id": "GHSA-62wc-jj78-f4f6",
"modified": "2026-06-30T03:35:27Z",
"published": "2026-01-20T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55130"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-55130.json"
},
{
"type": "WEB",
"url": "https://nodejs.org/en/blog/vulnerability/december-2025-security-releases"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2431352"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-55130"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7387"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7386"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6431"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6402"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2899"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2864"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2783"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2782"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2781"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2768"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2767"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2422"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2421"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2420"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:1843"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:1842"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7VVX-296G-VP4G
Vulnerability from github – Published: 2024-05-06 00:30 – Updated: 2024-07-03 18:38Avantra Server 24.x before 24.0.7 and 24.1.x before 24.1.1 mishandles the security of dashboards, aka XAN-5367. If a user can create a dashboard with an auto-login user, data disclosure may occur. Access control can be bypassed when there is a shared dashboard, and its auto-login user has privileges that a dashboard visitor should not have.
{
"affected": [],
"aliases": [
"CVE-2024-34519"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-05T22:15:07Z",
"severity": "MODERATE"
},
"details": "Avantra Server 24.x before 24.0.7 and 24.1.x before 24.1.1 mishandles the security of dashboards, aka XAN-5367. If a user can create a dashboard with an auto-login user, data disclosure may occur. Access control can be bypassed when there is a shared dashboard, and its auto-login user has privileges that a dashboard visitor should not have.",
"id": "GHSA-7vvx-296g-vp4g",
"modified": "2024-07-03T18:38:57Z",
"published": "2024-05-06T00:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34519"
},
{
"type": "WEB",
"url": "https://docs.avantra.com/release-notes/24/changes.html"
},
{
"type": "WEB",
"url": "https://support.avantra.com/support/solutions/articles/44002516766-xan-5367-security-vulnerability-fix-for-dashboards"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8V5Q-RHF3-JPHM
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-09-16 21:34The Spring Security annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue when using @PreAuthorize and other method security annotations, resulting in an authorization bypass.
Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.
You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.
This CVE is published in conjunction with CVE-2025-41249 https://spring.io/security/cve-2025-41249 .
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.4.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.5.0"
},
{
"fixed": "6.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-41248"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-16T19:34:33Z",
"nvd_published_at": "2025-09-16T11:15:30Z",
"severity": "HIGH"
},
"details": "The Spring Security annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue when using @PreAuthorize\u00a0and other method security annotations, resulting in an authorization bypass.\n\nYour application may be affected by this if you are using Spring Security\u0027s @EnableMethodSecurity\u00a0feature.\n\nYou are not affected by this if you are not using @EnableMethodSecurity\u00a0or if you do not use security annotations on methods in generic superclasses or generic interfaces.\n\nThis CVE is published in conjunction with CVE-2025-41249 https://spring.io/security/cve-2025-41249 .",
"id": "GHSA-8v5q-rhf3-jphm",
"modified": "2025-09-16T21:34:17Z",
"published": "2025-09-16T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41248"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/issues/17898"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/issues/17899"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/commit/d0f93fa6d8338149943ae640c53db07de827867f"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/commit/e5694ac7b5e4394b920c6cab48b7bfbd871f84bd"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-security"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/releases/tag/6.4.10"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/releases/tag/6.5.4"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2025-41248"
}
],
"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"
}
],
"summary": "Spring Security annotation detection mechanism has authorization bypass"
}
GHSA-8WXX-35QC-VP6R
Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-10-25 22:07An authentication bypass in the SSH service of gost v2.11.5 allows attackers to intercept communications via setting the HostKeyCallback function to ssh.InsecureIgnoreHostKey
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/ginuerzh/gost"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.11.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39223"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-25T22:07:23Z",
"nvd_published_at": "2024-07-03T15:15:06Z",
"severity": "CRITICAL"
},
"details": "An authentication bypass in the SSH service of gost v2.11.5 allows attackers to intercept communications via setting the HostKeyCallback function to ssh.InsecureIgnoreHostKey",
"id": "GHSA-8wxx-35qc-vp6r",
"modified": "2024-10-25T22:07:23Z",
"published": "2024-07-03T18:48:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39223"
},
{
"type": "WEB",
"url": "https://github.com/ginuerzh/gost/issues/1034"
},
{
"type": "WEB",
"url": "https://gist.github.com/nyxfqq/a7242170b1118e78436a62dee4e09e8a"
},
{
"type": "PACKAGE",
"url": "https://github.com/ginuerzh/gost"
},
{
"type": "WEB",
"url": "https://github.com/ginuerzh/gost/blob/729d0e70005607dc7c69fc1de62fd8fe21f85355/ssh.go#L229"
}
],
"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"
}
],
"summary": "Missing key verification in gost"
}
GHSA-9HM7-RV43-3CHF
Vulnerability from github – Published: 2023-04-14 15:30 – Updated: 2023-04-14 15:30Authentication Bypass by Alternate Name vulnerability in DTS Electronics Redline Router firmware allows Authentication Bypass.This issue affects Redline Router: before 7.17.
{
"affected": [],
"aliases": [
"CVE-2023-1803"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-14T14:15:00Z",
"severity": "CRITICAL"
},
"details": "Authentication Bypass by Alternate Name vulnerability in DTS Electronics Redline Router firmware allows Authentication Bypass.This issue affects Redline Router: before 7.17.\n\n",
"id": "GHSA-9hm7-rv43-3chf",
"modified": "2023-04-14T15:30:29Z",
"published": "2023-04-14T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1803"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-23-0227"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9MRV-8PVF-HF4M
Vulnerability from github – Published: 2026-06-12 12:31 – Updated: 2026-07-10 12:31The JwtAccessTokenValidator class in Apache CXF fails to validate the 'aud' (Audience) claims of incoming JWT access tokens. This allows a JWT issued for one Resource Server to be successfully replayed against a completely different Resource Server, leading to Token Confusion/Routing attacks. Users are recommended to upgrade to versions 4.2.2 or 4.1.7, which fixes this issue.
{
"affected": [],
"aliases": [
"CVE-2026-50627"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-12T10:16:22Z",
"severity": "CRITICAL"
},
"details": "The JwtAccessTokenValidator class in Apache CXF fails to validate the \u0027aud\u0027 (Audience) claims of incoming JWT access tokens. This allows a JWT issued for one Resource Server to be successfully replayed against a completely different Resource Server, leading to Token Confusion/Routing attacks.\u00a0Users are recommended to upgrade to versions 4.2.2 or 4.1.7, which fixes this issue.",
"id": "GHSA-9mrv-8pvf-hf4m",
"modified": "2026-07-10T12:31:37Z",
"published": "2026-06-12T12:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50627"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37390"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-50627"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2488298"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/0jfzz9q992957b99tw7hodcqjfyxwb1m"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-50627.json"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/11/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.