CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
1239 vulnerabilities reference this CWE, most recent first.
GHSA-PMXQ-PJ47-J8J4
Vulnerability from github – Published: 2023-09-08 12:19 – Updated: 2023-09-08 12:19Impact
The proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in Preventing proxying to and recording from specific target addresses. These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions.
The root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact.
Affected versions
- WireMock 3,x until 3.0.3 (security patch), on default settings in environments with access to the network
- WireMock 2.x until 2.35.1 (security patch), on default settings in environments with access to the network
- Python WireMock until 2.6.1
- WireMock Studio - all versions, this proprietary product was discontinued in 2022
Patches
- WireMock 3.0.3 + the 3.0.3-1 Docker image
- WireMock 2.35.1 + the 2.35.1-1 Docker image - backport to WireMock 2.x
- Python WireMock 2.6.1
Workarounds
For WireMock:
- Option 1: Configure WireMock to use IP addresses instead of the domain names in the outbound URLs subject to DNS rebinding
- Option 2: Use external firewall rules to define the list of permitted destinations
For WireMock Studio: N/A. Switch to another distribution, there will be no fix provided. The vendor of former WireMock Studio recommends migration to WireMock Cloud
References
- CVE-2023-41327 - Related issue in the WireMock Webhooks Extension
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.wiremock:wiremock-standalone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.wiremock:wiremock"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.github.tomakehurst:wiremock-jre8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.35.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.github.tomakehurst:wiremock-jre8-standalone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.35.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wiremock"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-41329"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-350"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-08T12:19:49Z",
"nvd_published_at": "2023-09-06T21:15:14Z",
"severity": "LOW"
},
"details": "### Impact\n\nThe proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in [Preventing proxying to and recording from specific target addresses](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions.\n\nThe root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact.\n\n### Affected versions\n\n- WireMock 3,x until 3.0.3 (security patch), on default settings in environments with access to the network\n- WireMock 2.x until 2.35.1 (security patch), on default settings in environments with access to the network\n- Python WireMock until 2.6.1\n- WireMock Studio - all versions, this proprietary product was discontinued in 2022\n\n\n### Patches\n\n- WireMock 3.0.3 + the 3.0.3-1 Docker image\n- WireMock 2.35.1 + the 2.35.1-1 Docker image - backport to WireMock 2.x\n- Python WireMock 2.6.1\n\n### Workarounds\n\nFor WireMock:\n\n- Option 1: Configure WireMock to use IP addresses instead of the domain names in the outbound URLs subject to DNS rebinding\n- Option 2: Use external firewall rules to define the list of permitted destinations\n\nFor WireMock Studio: N/A. Switch to another distribution, there will be no fix provided. The vendor of former WireMock Studio recommends migration to [WireMock Cloud](https://www.wiremock.io/product)\n\n### References\n\n- CVE-2023-41327 - Related issue in the WireMock Webhooks Extension\n",
"id": "GHSA-pmxq-pj47-j8j4",
"modified": "2023-09-08T12:19:49Z",
"published": "2023-09-08T12:19:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wiremock/wiremock/security/advisories/GHSA-pmxq-pj47-j8j4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41329"
},
{
"type": "PACKAGE",
"url": "https://github.com/wiremock/wiremock"
},
{
"type": "WEB",
"url": "https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Domain restrictions bypass via DNS Rebinding in WireMock and WireMock Studio webhooks, proxy and recorder modes"
}
GHSA-PP7X-83X2-99V7
Vulnerability from github – Published: 2026-07-22 15:31 – Updated: 2026-07-22 15:31In NLnet Labs Unbound 1.18.0 up to and including 1.25.1, when Unbound listens on a 'proxy-protocol-port' interface with 'answer-cookie: yes', the RFC 9018 server-cookie SipHash is computed over the proxy's wire address instead of the PROXYv2-declared client. One server cookie obtained through a given proxy node therefore validates for every PROXYv2-declared source behind that node. On a UDP+proxy-protocol front, an off-path attacker can harvest one cookie with a single legitimate query, then replay it under any spoofed source and pass DNS Cookie checks that were deployed to defeat this in the first place.
{
"affected": [],
"aliases": [
"CVE-2026-54478"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-22T14:17:21Z",
"severity": "LOW"
},
"details": "In NLnet Labs Unbound 1.18.0 up to and including 1.25.1, when Unbound listens on a \u0027proxy-protocol-port\u0027 interface with \u0027answer-cookie: yes\u0027, the RFC 9018 server-cookie SipHash is computed over the proxy\u0027s wire address instead of the PROXYv2-declared client. One server cookie obtained through a given proxy node therefore validates for every PROXYv2-declared source behind that node. On a UDP+proxy-protocol front, an off-path attacker can harvest one cookie with a single legitimate query, then replay it under any spoofed source and pass DNS Cookie checks that were deployed to defeat this in the first place.",
"id": "GHSA-pp7x-83x2-99v7",
"modified": "2026-07-22T15:31:25Z",
"published": "2026-07-22T15:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54478"
},
{
"type": "WEB",
"url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-54478.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PP9H-JMW7-X6CW
Vulnerability from github – Published: 2026-10-13 21:34 – Updated: 2026-10-13 21:34Improper privilege management in Windows Internet (wininet.dll) allows an authorized attacker to perform spoofing locally.
{
"affected": [],
"aliases": [
"CVE-2026-83845"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-13T19:20:33Z",
"severity": "HIGH"
},
"details": "Improper privilege management in Windows Internet (wininet.dll) allows an authorized attacker to perform spoofing locally.",
"id": "GHSA-pp9h-jmw7-x6cw",
"modified": "2026-10-13T21:34:59Z",
"published": "2026-10-13T21:34:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83845"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-83845"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PPP4-P6WJ-8GP8
Vulnerability from github – Published: 2025-03-04 06:30 – Updated: 2025-03-04 15:31The Admin and Site Enhancements (ASE) WordPress plugin before 7.6.10 retrieves client IP addresses from potentially untrusted headers, allowing an attacker to manipulate their value to bypass the login limit feature in the Admin and Site Enhancements (ASE) WordPress plugin before 7.6.10.
{
"affected": [],
"aliases": [
"CVE-2024-13685"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-04T06:15:27Z",
"severity": "MODERATE"
},
"details": "The Admin and Site Enhancements (ASE) WordPress plugin before 7.6.10 retrieves client IP addresses from potentially untrusted headers, allowing an attacker to manipulate their value to bypass the login limit feature in the Admin and Site Enhancements (ASE) WordPress plugin before 7.6.10.",
"id": "GHSA-ppp4-p6wj-8gp8",
"modified": "2025-03-04T15:31:48Z",
"published": "2025-03-04T06:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13685"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/72c61904-253d-42d1-9edd-7ea2162a2f85"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PR8C-F372-64CH
Vulnerability from github – Published: 2024-06-24 00:34 – Updated: 2024-11-21 21:33Click Studios Passwordstate Core before 9.8 build 9858 allows Authentication Bypass.
{
"affected": [],
"aliases": [
"CVE-2024-39337"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-24T00:15:09Z",
"severity": "MODERATE"
},
"details": "Click Studios Passwordstate Core before 9.8 build 9858 allows Authentication Bypass.",
"id": "GHSA-pr8c-f372-64ch",
"modified": "2024-11-21T21:33:30Z",
"published": "2024-06-24T00:34:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39337"
},
{
"type": "WEB",
"url": "https://www.clickstudios.com.au/passwordstate-changelog.aspx"
},
{
"type": "WEB",
"url": "https://www.clickstudios.com.au/security/advisories"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-PRJ2-J7V3-MHCV
Vulnerability from github – Published: 2026-10-12 09:31 – Updated: 2026-10-12 09:31The HTTP Basic Authentication modules in ((OTRS)) Community Edition 6 and prior accept the authenticated username from either the REMOTE_USER or HTTP_REMOTE_USER environment variable. In CGI and mod_perl based deployments, HTTP request headers may be mapped to corresponding HTTP_* environment variables. As a result, an unauthenticated remote attacker can supply a crafted Remote-User request header which is exposed to the application as HTTP_REMOTE_USER. When HTTP Basic Authentication is configured as the authentication backend, OTRS trusts this value as an already authenticated username and does not perform an additional password verification. An attacker may therefore authenticate through the Generic Interface as an existing agent or customer user without knowing the corresponding credentials.
The resulting privileges depend on the account being impersonated. Successful exploitation may allow access to confidential information and modification of data or configuration with the permissions of the affected user. Exploitation requires HTTP Basic Authentication to be configured as an authentication backend and a web server environment in which attacker-controlled HTTP headers are exposed through the corresponding HTTP_* environment variables.
OTRS 7 and later are not affected by this attack vector due to the use of Mojolicious/Hypnotoad and does not expose arbitrary request headers through %ENV in the manner required for exploitation. The supported REMOTE_USER mechanism additionally requires validation through the configured SSO shared secret. The unused HTTP_REMOTE_USER fallback has nevertheless been removed as a security-hardening measure.
Please note that ((OTRS)) Community Edition 6.x and before are vulnerable. Products based on the ((OTRS)) Community Edition also very likely to be affected
{
"affected": [],
"aliases": [
"CVE-2026-93582"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-12T07:16:37Z",
"severity": "CRITICAL"
},
"details": "The HTTP Basic Authentication modules in ((OTRS)) Community Edition 6 and prior accept the authenticated username from either the REMOTE_USER or HTTP_REMOTE_USER environment variable.\u00a0In CGI and mod_perl based deployments, HTTP request headers may be mapped to corresponding HTTP_* environment variables. As a result, an unauthenticated remote attacker can supply a crafted Remote-User request header which is exposed to the application as HTTP_REMOTE_USER.\u00a0When HTTP Basic Authentication is configured as the authentication backend, OTRS trusts this value as an already authenticated username and does not perform an additional password verification. An attacker may therefore authenticate through the Generic Interface as an existing agent or customer user without knowing the corresponding credentials.\n\nThe resulting privileges depend on the account being impersonated. Successful exploitation may allow access to confidential information and modification of data or configuration with the permissions of the affected user.\u00a0Exploitation requires HTTP Basic Authentication to be configured as an authentication backend and a web server environment in which attacker-controlled HTTP headers are exposed through the corresponding HTTP_* environment variables.\n\nOTRS 7 and later are not affected by this attack vector due to the\u00a0use of Mojolicious/Hypnotoad and does not expose arbitrary request headers through %ENV in the manner required for exploitation. The supported REMOTE_USER mechanism additionally requires validation through the configured SSO shared secret. The unused HTTP_REMOTE_USER fallback has nevertheless been removed as a security-hardening measure.\n\nPlease note that ((OTRS)) Community Edition 6.x and before are vulnerable. Products based on the ((OTRS)) Community Edition also very likely to be affected",
"id": "GHSA-prj2-j7v3-mhcv",
"modified": "2026-10-12T09:31:21Z",
"published": "2026-10-12T09:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93582"
},
{
"type": "WEB",
"url": "https://otrs.com/release-notes/otrs-security-advisory-2026-18"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-PW24-QQC3-7VPX
Vulnerability from github – Published: 2025-01-30 00:31 – Updated: 2025-01-30 00:31Authentication bypass by spoofing in Azure AI Face Service allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2025-21415"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-29T23:15:33Z",
"severity": "CRITICAL"
},
"details": "Authentication bypass by spoofing in Azure AI Face Service allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-pw24-qqc3-7vpx",
"modified": "2025-01-30T00:31:04Z",
"published": "2025-01-30T00:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21415"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21415"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PW26-HVCP-W6VJ
Vulnerability from github – Published: 2026-06-19 15:33 – Updated: 2026-06-23 15:32Authentication Bypass by Spoofing vulnerability in Apache APISIX.
The attacker can completely bypass authentication capitalising on certain configurations of jwt-auth plugin. This issue affects Apache APISIX: from v2.2 through v3.16.0.
Users are recommended to upgrade to version v3.17.0, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-39999"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-19T14:16:21Z",
"severity": "HIGH"
},
"details": "Authentication Bypass by Spoofing vulnerability in Apache APISIX.\n\nThe attacker can completely bypass authentication capitalising on certain configurations of jwt-auth plugin.\nThis issue affects Apache APISIX: from v2.2 through v3.16.0.\n\nUsers are recommended to upgrade to version v3.17.0, which fixes the issue.",
"id": "GHSA-pw26-hvcp-w6vj",
"modified": "2026-06-23T15:32:30Z",
"published": "2026-06-19T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39999"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/nfopt8cnxd3k0rs1oxtr7lzxrdw4mojq"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/19/5"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/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-PW3C-6W58-28W4
Vulnerability from github – Published: 2026-09-30 15:31 – Updated: 2026-09-30 15:31Apache WSS4J remembers the Nonce of each UsernameToken it accepts, so a captured token cannot be reused. It stored the Nonce as raw base64 text, but authentication decodes that text and uses the bytes.The same bytes can be written as base64 in several ways. An attacker who captured an authenticated request could re-send it with a space added to the Nonce: the password digest still verified, but the token no longer matched the remembered one, so the replay was accepted. Since a UsernameToken does not cover the message body, the captured token could then be reused on requests of the attacker's choosing until it expired. Affects deployments with a nonce replay cache configured, as Apache CXF has by default, and only tokens using a password digest. The cache is now keyed on the decoded Nonce. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue.
{
"affected": [],
"aliases": [
"CVE-2026-92899"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-30T13:17:21Z",
"severity": "MODERATE"
},
"details": "Apache WSS4J remembers the Nonce of each UsernameToken it accepts, so a captured token cannot be reused. It stored the Nonce as raw base64 text, but authentication decodes that text and uses the bytes.The same bytes can be written as base64 in several ways. An attacker who captured an authenticated request could re-send it with a space added to the Nonce: the password digest still verified, but the token no longer matched the remembered one, so the replay was accepted. Since a UsernameToken does not cover the message body, the captured token could then be reused on requests of the attacker\u0027s choosing until it expired. Affects deployments with a nonce replay cache configured, as Apache CXF has by default, and only tokens using a password digest. The cache is now keyed on the decoded Nonce.\u00a0Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue.",
"id": "GHSA-pw3c-6w58-28w4",
"modified": "2026-09-30T15:31:25Z",
"published": "2026-09-30T15:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92899"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/nrzngsz1xm2lztq3t873663xx9wnrwm7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/09/30/13"
}
],
"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"
}
]
}
GHSA-PWX7-FX9R-HR4H
Vulnerability from github – Published: 2026-03-24 21:50 – Updated: 2026-03-27 22:10Background
NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.
The nats-server offers a Nats-Request-Info: message header, providing information about a request.
Problem Description
The NATS message header Nats-Request-Info: is supposed to be a guarantee of identity by the NATS server, but the stripping of this header from inbound messages was not fully effective.
An attacker with valid credentials for any regular client interface could thus spoof their identity to services which rely upon this header.
Affected Versions
Any version before v2.12.6 or v2.11.15
Workarounds
None.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/nats-server/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/nats-server/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.12.0-RC.1"
},
{
"fixed": "2.12.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/nats-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33223"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T21:50:05Z",
"nvd_published_at": "2026-03-25T21:16:47Z",
"severity": "MODERATE"
},
"details": "### Background\n\nNATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.\n\nThe nats-server offers a `Nats-Request-Info:` message header, providing information about a request.\n\n### Problem Description\n\nThe NATS message header `Nats-Request-Info:` is supposed to be a guarantee of identity by the NATS server, but the stripping of this header from inbound messages was not fully effective.\n\nAn attacker with valid credentials for any regular client interface could thus spoof their identity to services which rely upon this header.\n\n### Affected Versions\n\nAny version before v2.12.6 or v2.11.15\n\n### Workarounds\n\nNone.",
"id": "GHSA-pwx7-fx9r-hr4h",
"modified": "2026-03-27T22:10:27Z",
"published": "2026-03-24T21:50:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-pwx7-fx9r-hr4h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33223"
},
{
"type": "WEB",
"url": "https://advisories.nats.io/CVE/secnote-2026-09.txt"
},
{
"type": "PACKAGE",
"url": "https://github.com/nats-io/nats-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "NATS Server: Incomplete Stripping of Nats-Request-Info Header Allows Identity Spoofing"
}
No mitigation information available for this CWE.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-476: Signature Spoofing by Misrepresentation
An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-667: Bluetooth Impersonation AttackS (BIAS)
An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.