CWE-436
Allowed-with-ReviewInterpretation Conflict
Abstraction: Class · Status: Incomplete
Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
289 vulnerabilities reference this CWE, most recent first.
GHSA-FF7Q-6VWH-V9M4
Vulnerability from github – Published: 2024-06-28 00:33 – Updated: 2024-06-28 18:57In phpseclib before 1.0.22, 2.x before 2.0.46, and 3.x before 3.0.33, some characters in Subject Alternative Name fields in TLS certificates are incorrectly allowed to have a special meaning in regular expressions (such as a + wildcard), leading to name confusion in X.509 certificate host verification.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpseclib/phpseclib"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpseclib/phpseclib"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.46"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpseclib/phpseclib"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.0.33"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-52892"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-28T18:57:31Z",
"nvd_published_at": "2024-06-27T22:15:10Z",
"severity": "HIGH"
},
"details": "In phpseclib before 1.0.22, 2.x before 2.0.46, and 3.x before 3.0.33, some characters in Subject Alternative Name fields in TLS certificates are incorrectly allowed to have a special meaning in regular expressions (such as a + wildcard), leading to name confusion in X.509 certificate host verification.",
"id": "GHSA-ff7q-6vwh-v9m4",
"modified": "2024-06-28T18:57:31Z",
"published": "2024-06-28T00:33:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52892"
},
{
"type": "WEB",
"url": "https://github.com/phpseclib/phpseclib/issues/1943"
},
{
"type": "WEB",
"url": "https://github.com/phpseclib/phpseclib/commit/6cd6e8ceab9f2b55c8cd81d2192bf98cbeaf4627"
},
{
"type": "PACKAGE",
"url": "https://github.com/phpseclib/phpseclib"
},
{
"type": "WEB",
"url": "https://github.com/phpseclib/phpseclib/releases/tag/3.0.33"
},
{
"type": "WEB",
"url": "https://github.com/x509-name-testing/name_testing_artifacts"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Name confusion in x509 Subject Alternative Name fields"
}
GHSA-FM3M-JRGM-5PPG
Vulnerability from github – Published: 2025-08-04 20:46 – Updated: 2025-08-06 14:12Summary
- When an attacker obtains the backend login path of RatPanel (including but not limited to weak default paths, brute-force cracking, etc.), they can execute system commands or take over hosts managed by the panel without logging in.
- In addition to this remote code execution (RCE) vulnerability, the flawed code also leads to unauthorized access.
Details
In Go, r.URL.Path retrieves the part of the URL that comes after the port and before the query parameters or anchor symbols. For example, in the URL http://localhost:8080/api/ws/ssh?id=1, the retrieved path would be /api/ws/ssh.
However, if the request is made to http://localhost:8080//api/ws/ssh?id=1, the parsed r.URL.Path would be //api/ws/ssh.
RatPanel uses the CleanPath middleware provided by github.com/go-chi/chi package to clean URLs, The route path inside the chi router will be cleaned to /api/ws/ssh, but this middleware does not process r.URL.Path, so the path is still //api/ws/ssh.
In the must_login middleware, RatPanel uses r.URL.Path to match the hard-coded prefix whitelist, because /api/ws does not match //api/ws. The must_login middleware will allow the request, but //api/ws has been cleaned to /api/ws in the chi router. This inconsistency leads to authentication bypass and accessing the dangerous interfaces such as /api/ws/exec and /api/ws/ssh.
But there are some limitations. Before exploiting this interface, the attacker must first identify the correct backend address of ratpanel to activate session legitimacy—specifically, to ensure sess.Put("verify_entrance", true). That said, accessing /api/ws only requires activating the session and does not require completing further authentication or login steps. Therefore, this is assessed to be a remotely exploitable command execution vulnerability with moderate severity.
PoC
I first carried session=......, accessed the backend login page normally(without completing the authentication process), activated the session, and then used the _wsdump.py script provided by the Python websocket-client library to complete the authentication and exploit the vulnerability.
Because of the authorization code
// internal/http/middleware/must_login.go
if slices.Contains(whiteList, r.URL.Path) || !strings.HasPrefix(r.URL.Path, "/api") {
next.ServeHTTP(w, r)
return
}
This vulnerability affects the authorization mechanism across all APIs, for example
This authentication vulnerability appears to affect versions v2.3.19 to v2.5.5.
Data packet
GET //api/...... HTTP/2
Host: IP:PORT
Cookie: session=XXXXXX
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=UTF-8
Connection: close
python _wsdump.py wss://ip:port//api/ws/exec --headers "Cookie: session=xxxxxx" -n
Impact
Users running Ratpanel versions v2.3.19 to v2.5.5—especially those who have exposed their admin panel login URL or use weak login URL paths—are vulnerable to unauthorized access. Additionally, versions v2.5.1 to v2.5.5 are susceptible to server and hosted machine takeover.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tnborg/panel"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.19"
},
{
"fixed": "2.5.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tnborg/panel"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-20241111062800-91ecd04c2700"
},
{
"fixed": "0.0.0-20250707071915-4985eb2e1f38"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-53534"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-305",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-04T20:46:32Z",
"nvd_published_at": "2025-08-05T21:15:38Z",
"severity": "HIGH"
},
"details": "### Summary\n\n* When an attacker obtains the backend login path of RatPanel (including but not limited to weak default paths, brute-force cracking, etc.), they can execute system commands or take over hosts managed by the panel **without logging in**.\n* In addition to this **remote code execution (RCE) vulnerability**, the flawed code also leads to **unauthorized access**.\n\n### Details\n\nIn Go, `r.URL.Path` retrieves the part of the URL that comes after the port and before the query parameters or anchor symbols. For example, in the URL `http://localhost:8080/api/ws/ssh?id=1`, the retrieved path would be `/api/ws/ssh`.\n\nHowever, if the request is made to `http://localhost:8080//api/ws/ssh?id=1`, the parsed `r.URL.Path` would be `//api/ws/ssh`. \n\nRatPanel uses the `CleanPath` middleware provided by `github.com/go-chi/chi` package to clean URLs, The route path inside the chi router will be cleaned to `/api/ws/ssh`, but this middleware does not process `r.URL.Path`, so the path is still `//api/ws/ssh`.\n\n\n\nIn the `must_login` middleware, RatPanel uses `r.URL.Path` to match the hard-coded prefix whitelist, because `/api/ws` does not match `//api/ws`. The `must_login` middleware will allow the request, but `//api/ws` has been cleaned to `/api/ws` in the chi router. This inconsistency leads to authentication bypass and accessing the dangerous interfaces such as `/api/ws/exec` and `/api/ws/ssh`.\n\n\n\nBut there are some limitations. Before exploiting this interface, the attacker must first identify the correct backend address of ratpanel to activate session legitimacy\u2014specifically, to ensure `sess.Put(\"verify_entrance\", true)`. That said, accessing `/api/ws` only requires activating the session and does not require completing further authentication or login steps. Therefore, this is assessed to be a remotely exploitable command execution vulnerability with moderate severity.\n\n\n### PoC\n\nI first carried `session=......`, accessed the backend login page normally` (without completing the authentication process)`, activated the session, and then used the [_wsdump.py](https://github.com/websocket-client/websocket-client/blob/master/websocket/_wsdump.py) script provided by the Python websocket-client library to complete the authentication and exploit the vulnerability.\n\n\n\n\n\nBecause of the authorization code\n\n```golang\n// internal/http/middleware/must_login.go\nif slices.Contains(whiteList, r.URL.Path) || !strings.HasPrefix(r.URL.Path, \"/api\") {\n next.ServeHTTP(w, r)\n return\n}\n```\n\nThis vulnerability affects the authorization mechanism across all APIs, for example\n\n\n\n\nThis authentication vulnerability appears to affect versions **v2.3.19 to v2.5.5**.\n\n---\n\nData packet\n\n```text\nGET //api/...... HTTP/2\nHost: IP:PORT\nCookie: session=XXXXXX\nAccept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2\nAccept-Encoding: gzip, deflate\nContent-Type: application/json; charset=UTF-8\nConnection: close\n\n\n```\n\n```cmd\npython _wsdump.py wss://ip:port//api/ws/exec --headers \"Cookie: session=xxxxxx\" -n\n```\n\n### Impact\n\nUsers running Ratpanel versions v2.3.19 to v2.5.5\u2014especially those who have exposed their admin panel login URL or use weak login URL paths\u2014are vulnerable to unauthorized access. Additionally, versions v2.5.1 to v2.5.5 are susceptible to server and hosted machine takeover.",
"id": "GHSA-fm3m-jrgm-5ppg",
"modified": "2025-08-06T14:12:21Z",
"published": "2025-08-04T20:46:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tnborg/panel/security/advisories/GHSA-fm3m-jrgm-5ppg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53534"
},
{
"type": "WEB",
"url": "https://github.com/tnborg/panel/commit/4985eb2e1f388ecd6faf331941c13cb97368ec1d"
},
{
"type": "WEB",
"url": "https://github.com/tnborg/panel/commit/91ecd04c270061429f9df5ec19cd6b96a9f595f2"
},
{
"type": "WEB",
"url": "https://github.com/tnborg/panel/commit/ed5c74c7534230ba685273504af4c1e1e3598ff1"
},
{
"type": "PACKAGE",
"url": "https://github.com/tnborg/panel"
},
{
"type": "WEB",
"url": "https://github.com/tnborg/panel/releases/tag/v2.5.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "RatPanel can perform remote command execution without authorization"
}
GHSA-FQC7-9XJW-JRH3
Vulnerability from github – Published: 2026-06-09 21:58 – Updated: 2026-06-09 21:58Description
CVE-2024-50340 (GHSA-x8vp-gf4q-mw5j) addressed an issue where, with register_argc_argv=On, a crafted query string let an unauthenticated GET change the kernel environment and debug flag by feeding --env/--no-debug through $_SERVER['argv']. The fix shipped in symfony/runtime 5.4.46 / 6.4.14 / 7.1.7 gated the argv read on empty($_GET) as a proxy for "is this a CLI invocation".
That proxy is unsafe: parse_str() (which builds $_GET) and the web SAPI (which builds $_SERVER['argv'] from the raw query when register_argc_argv=On) do not agree on every input, so an attacker can craft a query that leaves $_GET empty while $_SERVER['argv'] carries the attacker's flags. SymfonyRuntime::getInput() then parses them, restoring the exact primitive CVE-2024-50340 was meant to prevent.
Preconditions and impact match the original CVE: web SAPI, register_argc_argv=On, app booted through symfony/runtime; from an unauthenticated GET an attacker can flip APP_ENV and toggle APP_DEBUG.
Resolution
SymfonyRuntime now gates the argv read on isset($_SERVER['QUERY_STRING']) rather than on empty($_GET). QUERY_STRING is the same input the SAPI uses to build argv, so the security check and the thing it protects no longer parse different sources. Worker SAPIs (FrankenPHP / RoadRunner / Swoole) keep working because the runtime constructor runs once at boot when QUERY_STRING is unset.
The patch for this issue is available here for branch 5.4.
Credits
SymfonyRuntime would like to thank 0xEr3n for reporting the issue and Nicolas Grekas for providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/runtime"
},
"ranges": [
{
"events": [
{
"introduced": "5.4.46"
},
{
"fixed": "5.4.52"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/runtime"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.14"
},
{
"fixed": "6.4.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/runtime"
},
"ranges": [
{
"events": [
{
"introduced": "7.1.7"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/runtime"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "5.4.46"
},
{
"fixed": "5.4.52"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.14"
},
{
"fixed": "6.4.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.1.7"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47767"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-436",
"CWE-74"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-09T21:58:11Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\n\nCVE-2024-50340 (GHSA-x8vp-gf4q-mw5j) addressed an issue where, with `register_argc_argv=On`, a crafted query string let an unauthenticated GET change the kernel environment and debug flag by feeding `--env`/`--no-debug` through `$_SERVER[\u0027argv\u0027]`. The fix shipped in `symfony/runtime` 5.4.46 / 6.4.14 / 7.1.7 gated the argv read on `empty($_GET)` as a proxy for \"is this a CLI invocation\".\n\nThat proxy is unsafe: `parse_str()` (which builds `$_GET`) and the web SAPI (which builds `$_SERVER[\u0027argv\u0027]` from the raw query when `register_argc_argv=On`) do not agree on every input, so an attacker can craft a query that leaves `$_GET` empty while `$_SERVER[\u0027argv\u0027]` carries the attacker\u0027s flags. `SymfonyRuntime::getInput()` then parses them, restoring the exact primitive CVE-2024-50340 was meant to prevent.\n\nPreconditions and impact match the original CVE: web SAPI, `register_argc_argv=On`, app booted through `symfony/runtime`; from an unauthenticated GET an attacker can flip `APP_ENV` and toggle `APP_DEBUG`.\n\n### Resolution\n\n`SymfonyRuntime` now gates the argv read on `isset($_SERVER[\u0027QUERY_STRING\u0027])` rather than on `empty($_GET)`. `QUERY_STRING` is the same input the SAPI uses to build argv, so the security check and the thing it protects no longer parse different sources. Worker SAPIs (FrankenPHP / RoadRunner / Swoole) keep working because the runtime constructor runs once at boot when `QUERY_STRING` is unset.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/3228c3806ee511008bea19a95084d460b17e5d25) for branch 5.4.\n\n### Credits\n\nSymfonyRuntime would like to thank 0xEr3n for reporting the issue and Nicolas Grekas for providing the fix.",
"id": "GHSA-fqc7-9xjw-jrh3",
"modified": "2026-06-09T21:58:11Z",
"published": "2026-06-09T21:58:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-fqc7-9xjw-jrh3"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SymfonyRuntime CVE-2024-50340 Patch Bypass: Web Requests Can Still Set APP_ENV/APP_DEBUG via parse_str/SAPI Argv Mismatch"
}
GHSA-FVF3-54P5-JG2M
Vulnerability from github – Published: 2026-10-14 15:32 – Updated: 2026-10-14 15:32Description NGINX JavaScript (njs) has a vulnerability where the njs XML module exposes entity-backed XML attributes inconsistently with libxml2 canonicalization. In both the built-in njs and QuickJS backends during the canonicalization process, the $attr$Name getter may return undefined for an explicitly present attribute containing an internal entity reference. The $attrs getter may return a value derived only from the first attribute child. This may allow an unauthenticated attacker that invests significant effort in obtaining a genuinely signed document to skip validation while signature verification succeeds. An nginx-saml deployment is a confirmed affected consumer when run with the built-in njs backend.
Impact In affected signed-XML consumers, an unauthenticated attacker can cause security-relevant attributes to appear absent or truncated while signature verification succeeds. In nginx-saml, this can bypass expiry, Destination, and request-correlation checks, enabling replay or acceptance of a response outside its intended context. It does not permit signature or identity forgery, or a direct availability impact. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2026-101019"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-14T15:17:01Z",
"severity": "HIGH"
},
"details": "Description\nNGINX JavaScript (njs) has a vulnerability where the njs XML module exposes entity-backed XML attributes inconsistently with libxml2 canonicalization. In both the built-in njs and QuickJS backends during the canonicalization process, the $attr$Name getter may return undefined for an explicitly present attribute containing an internal entity reference. The $attrs getter may return a value derived only from the first attribute child. This may allow an unauthenticated attacker that invests significant effort in obtaining a genuinely signed document to skip validation while signature verification succeeds. An nginx-saml deployment is a confirmed affected consumer when run with the built-in njs backend.\n\nImpact\nIn affected signed-XML consumers, an unauthenticated attacker can cause security-relevant attributes to appear absent or truncated while signature verification succeeds. In nginx-saml, this can bypass expiry, Destination, and request-correlation checks, enabling replay or acceptance of a response outside its intended context. It does not permit signature or identity forgery, or a direct availability impact.\u00a0There is no control plane exposure; this is a data plane issue only.\n\n\n\n\u00a0Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-fvf3-54p5-jg2m",
"modified": "2026-10-14T15:32:22Z",
"published": "2026-10-14T15:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101019"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K000162615"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/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-G34J-R48H-5PMJ
Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30Softing Secure Integration Server Interpretation Conflict Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Softing Secure Integration Server. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.
The specific flaw exists within the web server. The issue results from an inconsistency in URI parsing between NGINX and application code. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-20551.
{
"affected": [],
"aliases": [
"CVE-2023-39481"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T03:15:14Z",
"severity": "MODERATE"
},
"details": "Softing Secure Integration Server Interpretation Conflict Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Softing Secure Integration Server. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.\n\nThe specific flaw exists within the web server. The issue results from an inconsistency in URI parsing between NGINX and application code. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-20551.",
"id": "GHSA-g34j-r48h-5pmj",
"modified": "2024-05-03T03:30:56Z",
"published": "2024-05-03T03:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39481"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-23-1063"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G4QM-M288-5CP9
Vulnerability from github – Published: 2026-10-08 17:51 – Updated: 2026-10-08 17:51Summary
Coraza's cookie parser (internal/cookies.ParseCookies) does not strip ASCII control characters (CTLs) from the edges of a cookie name/value before they're matched against REQUEST_COOKIES / REQUEST_COOKIES_NAMES. When a CTL sits directly next to the = separator, Coraza absorbs it into the adjacent name or value, while several backend cookie parsers trim it away — so the WAF and the application disagree about the cookie it just received.
Root cause
ParseCookies(internal/cookies/cookies.go:17,26,31) trims vianet/textproto.TrimString, which strips only space (0x20) and tab (0x09).- RFC 6265 §4.1.1 defines cookie
nameas an HTTPtokenandvalueascookie-octet, both excluding the full C0 control range (0x00–0x1F,0x7F) — not just space/tab. - Input
a\v=\t'(vertical tab\vnext to=) keeps\vin the name (a\v), yielding name=a\v, value=\t'.
Confirmed divergence from real backends
| Implementation | Name | Value |
|---|---|---|
| Coraza (< 3.8.0) | a\v |
\t' |
Python http.cookies, and the Werkzeug/Flask version in the report below |
a |
' |
PHP $_COOKIE |
a |
\t' |
Node.js cookie package |
a\v |
' |
RFC 6265 itself calls this exact cookie-pair invalid, so there's no single spec-correct reference — but Coraza's boundary handling diverges from 2 of these 3 widely-used backends.
Correction (2026-10-02): current Werkzeug (3.1.9, checked during review of the 3.8.1 follow-up) keeps a\v as the name, like Node's cookie package. The name divergence therefore applies to PHP and to Python's http.cookies, not to every Werkzeug version.
Impact
An attacker can pad a Cookie header with a CTL adjacent to = so Coraza indexes a different name/value than the backend application does. A SecRule scoped to a specific cookie name or value can then miss the cookie the application actually processes — a WAF bypass for cookie-carried attacks.
Affected component
internal/cookies.ParseCookies, consumed via REQUEST_COOKIES / REQUEST_COOKIES_NAMES.
Fix
Trim the full CTL range (not just space/tab) from both ends of the extracted name and value, treating a boundary-adjacent CTL as a delimiter rather than token content — aligning with RFC 6265's token/cookie-octet grammar.
The fix does not attempt to resolve what happens when a CTL lands in the interior of an otherwise-plausible name (e.g. ab\vcd). That case is disputed among the backends themselves — Python's http.cookies rejects the whole pair, PHP strips the CTL from the middle, Node's cookie package keeps it — so there is no consensus to converge on. It is left as a separate follow-up rather than guessed at here.
Implementation note
The trim is deliberately hand-rolled (a byte-wise scan on b <= ' ' || b == 0x7f, which covers octets 0x00–0x20 plus 0x7F) rather than delegated to the standard library. This is a conscious choice on a security hot path and should not be "simplified" away later:
strings.TrimFuncwas measured and rejected. It invokes its predicate through a func value once per byte scanned, which Go cannot devirtualize throughstrings.indexFunc. On an Apple M2, parsing a 64 KiB CTL-saturatedCookieheader costs 167.6 µs viaTrimFuncversus 33.9 µs byte-wise — a ~5× CPU amplification handed to an attacker, on input that is attacker-controlled and parsed on every request. Allocation counts are identical either way; the cost is purely the per-byte indirect call.strings.TrimSpaceis not a substitute. It misses most of the CTL range (0x00–0x08,0x0E–0x1F,0x7F) and additionally trimsU+0085andU+00A0, whose multi-byte UTF-8 encodings a backend would not strip — reintroducing the very parser-disagreement class this advisory closes.
The byte-wise implementation was verified equivalent to a TrimFunc-based one across all 16,843,009 byte strings of length 0–3, including invalid UTF-8, with zero mismatches. BenchmarkParseCookies/CTLFlood guards the hot path against a future regression to a per-byte indirect call.
Proof of Concept (original report)
Hi, @fzipi, i hope you doing well, i'm RelunSec from InsiteTech.jp
we discovered a parser confusion in cookie parser, i used a simple flask app that print the cookies
```py from flask import Flask, request
app = Flask(name)
@app.route('/') def index(): # 1. Print all cookies as a dictionary to your terminal console print("All cookies:", request.cookies)
return "Cookies logged in terminal!"if name == 'main': app.run(debug=True) ```
and a go setup
```go package cookies
import ( "fmt" "testing" )
func TestParseCookie(t *testing.T) { inputs := []string{ "a\v=\t'", }
fmt.Println("\n==========================================") fmt.Println(" COOKIE PARSE DIRECT LOCAL RUN ") fmt.Println("==========================================")
for _, input := range inputs { // Calling the exact lowercase function name from the repo cookies := ParseCookies(input)
fmt.Printf("-> Input: %q\n", input) fmt.Printf(" Output: %q\n", cookies) fmt.Println("------------------------------------------")} fmt.Println("==========================================") } ```
i runned the go program as you can see
```go relunsec@relunsec:~/software/coraza/internal/cookies$ go test
========================================== COOKIE PARSE DIRECT LOCAL RUN ========================================== -> Input: "a\v=\t'" Output: map["a\v":["\t'"]]
========================================== PASS ok github.com/corazawaf/coraza/v3/internal/cookies 0.003s ```
and then i sended a curl request to the python flask web app
bash relunsec@relunsec:~/software/coraza/internal/cookies$ curl 127.0.0.1:5000 -H $'Cookie: a\v=\t' Cookies logged in terminal!and then i saw in the running flask app terminal
python All cookies: ImmutableMultiDict([('a', "'")])as you can see python see that as the a cookie and the value of it is
', while coraza see it in a different name and a valuean attacker can craft a crafted payload that evade cookie inspection and then perfom their attack
Patched in 3.8.1
The 3.8.0 fix was incomplete. 3.8.1 completes it: trimming control characters in 3.8.0 turned a cookie whose name is only control characters (\x01=payload) into a cookie with an empty name, and empty names have always been skipped, so its value was no longer inspected. Node's cookie package ({"\x01": "payload"}, {"": "payload"}) and Werkzeug still pass such pairs to the application. 3.8.1 keeps them in REQUEST_COOKIES under the name "". This is an intentional deviation from ModSecurity v2 and v3, which skip empty names. Upgrade to 3.8.1; 3.8.0 is listed as affected.
Severity (revised 2026-10-02)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N (4.0, Medium).
Unchanged vector; precondition stated per the project's triage guidance. Attack Complexity is High because the bypass depends on a specific backend cookie parser: the original trim discrepancy affects backends that split a\v as a (PHP's $_COOKIE, Python's http.cookies) and only rules keyed on a cookie name, and the 3.8.0 regression affects backends that pass empty or control-character-only cookie names to the application (Node's cookie package, Werkzeug for \x01).
Impact metrics follow the convention used across Coraza's WAF-bypass advisories: the vulnerable component is Coraza, but the impact lands on the protected application, so Scope is Changed. The bypass hides a payload from inspection; the application still has to be vulnerable to it, so Integrity is Low and Confidentiality is not scored separately.
AI involvement in this section: Claude Opus 5.5 (Anthropic), via Claude Code, re-derived the CVSS vector from the project's triage guidance (AGENTS.md, "CVSS preconditions get verified, not copied from the report") and drafted this text. A human maintainer (fzipi) chose the S:C/I:L impact convention and directed this update.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/corazawaf/coraza/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T17:51:30Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\nCoraza\u0027s cookie parser (`internal/cookies.ParseCookies`) does not strip ASCII control characters (CTLs) from the edges of a cookie name/value before they\u0027re matched against `REQUEST_COOKIES` / `REQUEST_COOKIES_NAMES`. When a CTL sits directly next to the `=` separator, Coraza absorbs it into the adjacent name or value, while several backend cookie parsers trim it away \u2014 so the WAF and the application disagree about the cookie it just received.\n\n## Root cause\n- `ParseCookies` (`internal/cookies/cookies.go:17,26,31`) trims via `net/textproto.TrimString`, which strips only space (`0x20`) and tab (`0x09`).\n- RFC 6265 \u00a74.1.1 defines cookie `name` as an HTTP `token` and `value` as `cookie-octet`, both excluding the full C0 control range (`0x00\u20130x1F`, `0x7F`) \u2014 not just space/tab.\n- Input `a\\v=\\t\u0027` (vertical tab `\\v` next to `=`) keeps `\\v` in the name (`a\\v`), yielding name=`a\\v`, value=`\\t\u0027`.\n\n## Confirmed divergence from real backends\n| Implementation | Name | Value |\n|---|---|---|\n| Coraza (\u003c 3.8.0) | `a\\v` | `\\t\u0027` |\n| Python `http.cookies`, and the Werkzeug/Flask version in the report below | `a` | `\u0027` |\n| PHP `$_COOKIE` | `a` | `\\t\u0027` |\n| Node.js `cookie` package | `a\\v` | `\u0027` |\n\nRFC 6265 itself calls this exact cookie-pair invalid, so there\u0027s no single spec-correct reference \u2014 but Coraza\u0027s boundary handling diverges from 2 of these 3 widely-used backends.\n\nCorrection (2026-10-02): current Werkzeug (3.1.9, checked during review of the 3.8.1 follow-up) keeps `a\\v` as the name, like Node\u0027s `cookie` package. The name divergence therefore applies to PHP and to Python\u0027s `http.cookies`, not to every Werkzeug version.\n\n## Impact\nAn attacker can pad a `Cookie` header with a CTL adjacent to `=` so Coraza indexes a different name/value than the backend application does. A `SecRule` scoped to a specific cookie name or value can then miss the cookie the application actually processes \u2014 a WAF bypass for cookie-carried attacks.\n\n## Affected component\n`internal/cookies.ParseCookies`, consumed via `REQUEST_COOKIES` / `REQUEST_COOKIES_NAMES`.\n\n## Fix\nTrim the full CTL range (not just space/tab) from both ends of the extracted name and value, treating a boundary-adjacent CTL as a delimiter rather than token content \u2014 aligning with RFC 6265\u0027s `token`/`cookie-octet` grammar.\n\nThe fix does not attempt to resolve what happens when a CTL lands in the *interior* of an otherwise-plausible name (e.g. `ab\\vcd`). That case is disputed among the backends themselves \u2014 Python\u0027s `http.cookies` rejects the whole pair, PHP strips the CTL from the middle, Node\u0027s `cookie` package keeps it \u2014 so there is no consensus to converge on. It is left as a separate follow-up rather than guessed at here.\n\n### Implementation note\nThe trim is deliberately hand-rolled (a byte-wise scan on `b \u003c= \u0027 \u0027 || b == 0x7f`, which covers octets `0x00\u20130x20` plus `0x7F`) rather than delegated to the standard library. This is a conscious choice on a security hot path and should not be \"simplified\" away later:\n\n- **`strings.TrimFunc` was measured and rejected.** It invokes its predicate through a func value once per byte scanned, which Go cannot devirtualize through `strings.indexFunc`. On an Apple M2, parsing a 64 KiB CTL-saturated `Cookie` header costs **167.6 \u00b5s** via `TrimFunc` versus **33.9 \u00b5s** byte-wise \u2014 a ~5\u00d7 CPU amplification handed to an attacker, on input that is attacker-controlled and parsed on every request. Allocation counts are identical either way; the cost is purely the per-byte indirect call.\n- **`strings.TrimSpace` is not a substitute.** It misses most of the CTL range (`0x00\u20130x08`, `0x0E\u20130x1F`, `0x7F`) and additionally trims `U+0085` and `U+00A0`, whose multi-byte UTF-8 encodings a backend would not strip \u2014 reintroducing the very parser-disagreement class this advisory closes.\n\nThe byte-wise implementation was verified equivalent to a `TrimFunc`-based one across all 16,843,009 byte strings of length 0\u20133, including invalid UTF-8, with zero mismatches. `BenchmarkParseCookies/CTLFlood` guards the hot path against a future regression to a per-byte indirect call.\n\n## Proof of Concept (original report)\n\n\u003e Hi, @fzipi, i hope you doing well, i\u0027m RelunSec from InsiteTech.jp\n\u003e\n\u003e we discovered a parser confusion in cookie parser, i used a simple flask app that print the cookies\n\u003e\n\u003e ```py\n\u003e from flask import Flask, request\n\u003e\n\u003e app = Flask(__name__)\n\u003e\n\u003e @app.route(\u0027/\u0027)\n\u003e def index():\n\u003e # 1. Print all cookies as a dictionary to your terminal console\n\u003e print(\"All cookies:\", request.cookies)\n\u003e\n\u003e return \"Cookies logged in terminal!\"\n\u003e\n\u003e if __name__ == \u0027__main__\u0027:\n\u003e app.run(debug=True)\n\u003e ```\n\u003e\n\u003e and a go setup\n\u003e\n\u003e ```go\n\u003e package cookies\n\u003e\n\u003e import (\n\u003e \t\"fmt\"\n\u003e \t\"testing\"\n\u003e )\n\u003e\n\u003e func TestParseCookie(t *testing.T) {\n\u003e \tinputs := []string{\n\u003e \"a\\v=\\t\u0027\",\n\u003e \t}\n\u003e\n\u003e \tfmt.Println(\"\\n==========================================\")\n\u003e \tfmt.Println(\" COOKIE PARSE DIRECT LOCAL RUN \")\n\u003e \tfmt.Println(\"==========================================\")\n\u003e\n\u003e \tfor _, input := range inputs {\n\u003e \t\t// Calling the exact lowercase function name from the repo\n\u003e \t\tcookies := ParseCookies(input)\n\u003e\n\u003e \t\tfmt.Printf(\"-\u003e Input: %q\\n\", input)\n\u003e \t\tfmt.Printf(\" Output: %q\\n\", cookies)\n\u003e \t\tfmt.Println(\"------------------------------------------\")\n\u003e \t}\n\u003e \tfmt.Println(\"==========================================\")\n\u003e }\n\u003e ```\n\u003e\n\u003e i runned the go program as you can see\n\u003e\n\u003e ```go\n\u003e relunsec@relunsec:~/software/coraza/internal/cookies$ go test\n\u003e\n\u003e ==========================================\n\u003e COOKIE PARSE DIRECT LOCAL RUN\n\u003e ==========================================\n\u003e -\u003e Input: \"a\\v=\\t\u0027\"\n\u003e Output: map[\"a\\v\":[\"\\t\u0027\"]]\n\u003e ------------------------------------------\n\u003e ==========================================\n\u003e PASS\n\u003e ok \tgithub.com/corazawaf/coraza/v3/internal/cookies\t0.003s\n\u003e ```\n\u003e\n\u003e and then i sended a curl request to the python flask web app\n\u003e\n\u003e ```bash\n\u003e relunsec@relunsec:~/software/coraza/internal/cookies$ curl 127.0.0.1:5000 -H $\u0027Cookie: a\\v=\\t\u0027\n\u003e Cookies logged in terminal!\n\u003e ```\n\u003e\n\u003e and then i saw in the running flask app terminal\n\u003e\n\u003e ```python\n\u003e All cookies: ImmutableMultiDict([(\u0027a\u0027, \"\u0027\")])\n\u003e ```\n\u003e\n\u003e as you can see python see that as the a cookie and the value of it is `\u0027`, while coraza see it in a different name and a value\n\u003e\n\u003e an attacker can craft a crafted payload that evade cookie inspection and then perfom their attack\n\n### Patched in 3.8.1\n\nThe 3.8.0 fix was incomplete. 3.8.1 completes it: trimming control characters in 3.8.0 turned a cookie whose name is only control characters (`\\x01=payload`) into a cookie with an empty name, and empty names have always been skipped, so its value was no longer inspected. Node\u0027s `cookie` package (`{\"\\x01\": \"payload\"}`, `{\"\": \"payload\"}`) and Werkzeug still pass such pairs to the application. 3.8.1 keeps them in `REQUEST_COOKIES` under the name `\"\"`. This is an intentional deviation from ModSecurity v2 and v3, which skip empty names. Upgrade to 3.8.1; 3.8.0 is listed as affected.\n\n\n### Severity (revised 2026-10-02)\n\n`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N` (4.0, Medium).\n\nUnchanged vector; precondition stated per the project\u0027s triage guidance. Attack Complexity is High because the bypass depends on a specific backend cookie parser: the original trim discrepancy affects backends that split `a\\v` as `a` (PHP\u0027s `$_COOKIE`, Python\u0027s `http.cookies`) and only rules keyed on a cookie name, and the 3.8.0 regression affects backends that pass empty or control-character-only cookie names to the application (Node\u0027s `cookie` package, Werkzeug for `\\x01`).\n\nImpact metrics follow the convention used across Coraza\u0027s WAF-bypass advisories: the vulnerable component is Coraza, but the impact lands on the protected application, so Scope is Changed. The bypass hides a payload from inspection; the application still has to be vulnerable to it, so Integrity is Low and Confidentiality is not scored separately.\n\n_AI involvement in this section: Claude Opus 5.5 (Anthropic), via Claude Code, re-derived the CVSS vector from the project\u0027s triage guidance (AGENTS.md, \"CVSS preconditions get verified, not copied from the report\") and drafted this text. A human maintainer (fzipi) chose the `S:C/I:L` impact convention and directed this update._",
"id": "GHSA-g4qm-m288-5cp9",
"modified": "2026-10-08T17:51:31Z",
"published": "2026-10-08T17:51:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-g4qm-m288-5cp9"
},
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/commit/0b940e197ad9983fb3aa36e84f1f81ff985461af"
},
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/commit/9f8521398d1ff023b958fad0b944cac265763866"
},
{
"type": "PACKAGE",
"url": "https://github.com/corazawaf/coraza"
},
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Coraza has Cookie Parser Confusion"
}
GHSA-G4W6-VMGF-XQVX
Vulnerability from github – Published: 2026-06-30 18:09 – Updated: 2026-06-30 18:09Summary
@cedar-policy/authorization-for-expressjs is an open-source Express.js middleware that integrates Cedar authorization into Express applications by mapping HTTP requests to Cedar actions and evaluating authorization policies before allowing requests to proceed. An issue exists where, under certain circumstances, the middleware matches incoming requests against Cedar action mappings using req.originalUrl, which includes the query string, while Express routes requests using only the path component.
Impact
The middleware uses req.originalUrl to match incoming requests against Cedar action mappings. In Express, req.originalUrl includes the query string, while route matching uses only the path. This creates a divergence between what Cedar authorizes and what Express executes.
When an application defines separate actions for overlapping path prefixes with different authorization requirements (for example, GET /users for listing all users with admin-only access, and GET /users/{id} for retrieving a single user with any authenticated user access), an actor can append a query string to bypass the more restrictive policy. Sending GET /users/?x=1 causes the middleware to match against /users/{id} (with id parameter set to ?x=1) and evaluate the less restrictive action, while Express routes the request to the /users list handler. This allows inappropriate access to the more restrictive endpoint.
Impacted versions
<= 0.2.0
Patches
This issue has been addressed in @cedar-policy/authorization-for-expressjs version 0.3. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Validate and sanitize incoming request paths before they reach the authorization middleware. Ensure that applications do not rely solely on the middleware for authorization when defining multiple actions on overlapping path prefixes with different permission levels.
References
If you have any questions or comments about this advisory, AWS asks that you contact AWS Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.2.0"
},
"package": {
"ecosystem": "npm",
"name": "@cedar-policy/authorization-for-expressjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49473"
],
"database_specific": {
"cwe_ids": [
"CWE-436",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T18:09:13Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n@cedar-policy/authorization-for-expressjs is an open-source Express.js middleware that integrates Cedar authorization into Express applications by mapping HTTP requests to Cedar actions and evaluating authorization policies before allowing requests to proceed. An issue exists where, under certain circumstances, the middleware matches incoming requests against Cedar action mappings using req.originalUrl, which includes the query string, while Express routes requests using only the path component.\n\n### Impact\nThe middleware uses req.originalUrl to match incoming requests against Cedar action mappings. In Express, req.originalUrl includes the query string, while route matching uses only the path. This creates a divergence between what Cedar authorizes and what Express executes.\n\nWhen an application defines separate actions for overlapping path prefixes with different authorization requirements (for example, GET /users for listing all users with admin-only access, and GET /users/{id} for retrieving a single user with any authenticated user access), an actor can append a query string to bypass the more restrictive policy. Sending GET /users/?x=1 causes the middleware to match against /users/{id} (with id parameter set to ?x=1) and evaluate the less restrictive action, while Express routes the request to the /users list handler. This allows inappropriate access to the more restrictive endpoint.\n\n### Impacted versions\n\u003c= 0.2.0\n\n### Patches\nThis issue has been addressed in @cedar-policy/authorization-for-expressjs version 0.3. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.\n\n### Workarounds\nValidate and sanitize incoming request paths before they reach the authorization middleware. Ensure that applications do not rely solely on the middleware for authorization when defining multiple actions on overlapping path prefixes with different permission levels.\n\n### References\nIf you have any questions or comments about this advisory, AWS asks that you contact AWS Security via the vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.",
"id": "GHSA-g4w6-vmgf-xqvx",
"modified": "2026-06-30T18:09:13Z",
"published": "2026-06-30T18:09:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cedar-policy/authorization-for-expressjs/security/advisories/GHSA-g4w6-vmgf-xqvx"
},
{
"type": "PACKAGE",
"url": "https://github.com/cedar-policy/authorization-for-expressjs"
},
{
"type": "WEB",
"url": "https://github.com/cedar-policy/authorization-for-expressjs/releases/tag/v0.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "@cedar-policy/authorization-for-expressjs has an authorization bypass via query string manipulation"
}
GHSA-G57G-F23G-4646
Vulnerability from github – Published: 2026-09-29 23:44 – Updated: 2026-09-29 23:44Summary
Nodemailer's address parser can produce an unexpected recipient address when an RFC 5322 comment follows the domain of an address whose local-part is a quoted string.
For example:
"user"@example.com(x)evil.com
is parsed as:
{
address: "user@example.com evil.com",
name: ""
}
The resulting address therefore contains additional attacker-controlled domain text separated by a literal space.
The parsed .address value is subsequently propagated into the SMTP envelope:
src/addressparser/index.ts
↓
recipient.address
↓
src/mime-node/index.ts
↓
envelope.to
The envelope construction uses the parsed address without another strict address validation step.
This appears to be a variant of the RFC 5322 comment parsing issue addressed by GHSA-cc9r-2j5m-2m83, but it follows a different parser path when the local-part is quoted.
Reproduction
Input:
"user"@example.com(x)evil.com
Observed parser output:
address: "user@example.com evil.com"
name: ""
A second example:
"a"@b.com(c)d.com(e)f.com
produces:
address: "a@b.com d.com f.com"
name: ""
For comparison, the corresponding unquoted form:
user@example.com(x)evil.com
takes a different code path and is handled by the existing protection differently.
Technical Details
The issue is caused by different parsing behavior for quoted and unquoted local-parts.
The quoted-local-part variant allows the comment-separated trailing domain atoms to remain in the resulting .address value.
That value is then used when constructing the message envelope:
envelope.to = recipients.map(to => to.address as string)
No additional strict recipient validation is performed at this boundary.
Security Impact
The confirmed impact is that attacker-controlled comment content can result in a malformed/ambiguous recipient address being accepted by the parser and propagated into envelope.to.
The reporter did not confirm successful delivery to an unintended recipient through a real SMTP server using this exact quoted-local-part variant.
The remaining question is how real SMTP servers and other Nodemailer transports handle an envelope recipient containing a value such as:
user@example.com evil.com
An end-to-end SMTP test is required to determine whether this parser behavior results in an exploitable delivery or recipient-validation bypass.
Relationship to GHSA-cc9r-2j5m-2m83
This report is intended as a potential variant/follow-up to GHSA-cc9r-2j5m-2m83.
The existing advisory addresses RFC 5322 comment handling in email domains. This report identifies a separate parser path involving quoted local-parts that can preserve additional domain-like content in the normalized address.
Please evaluate whether this behavior is already covered by the existing fix or represents a remaining parser variant.
Suggested Fix
The parser should consistently reject or correctly terminate addresses containing trailing domain atoms after RFC 5322 comments, regardless of whether the local-part is quoted.
In particular:
"user"@example.com(x)evil.com
should not result in:
user@example.com evil.com
The envelope-generation layer should also avoid assuming that a parser-produced address is safe for SMTP delivery without appropriate validation.
Verification Status
Confirmed:
- Parser accepts the quoted-local-part variant.
- Parser produces an address containing additional attacker-controlled text.
- The resulting address is propagated into
envelope.to.
Not confirmed by reporter:
- Successful delivery through a real SMTP server.
- Delivery to an unintended recipient.
- Exploitability against a specific downstream SMTP implementation.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nodemailer"
},
"ranges": [
{
"events": [
{
"introduced": "9.1.0"
},
{
"fixed": "10.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-29T23:44:04Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nNodemailer\u0027s address parser can produce an unexpected recipient address when an RFC 5322 comment follows the domain of an address whose local-part is a quoted string.\n\nFor example:\n\n```text\n\"user\"@example.com(x)evil.com\n```\n\nis parsed as:\n\n```text\n{\n address: \"user@example.com evil.com\",\n name: \"\"\n}\n```\n\nThe resulting address therefore contains additional attacker-controlled domain text separated by a literal space.\n\nThe parsed `.address` value is subsequently propagated into the SMTP envelope:\n\n```text\nsrc/addressparser/index.ts\n \u2193\nrecipient.address\n \u2193\nsrc/mime-node/index.ts\n \u2193\nenvelope.to\n```\n\nThe envelope construction uses the parsed address without another strict address validation step.\n\nThis appears to be a variant of the RFC 5322 comment parsing issue addressed by GHSA-cc9r-2j5m-2m83, but it follows a different parser path when the local-part is quoted.\n\n## Reproduction\n\nInput:\n\n```text\n\"user\"@example.com(x)evil.com\n```\n\nObserved parser output:\n\n```text\naddress: \"user@example.com evil.com\"\nname: \"\"\n```\n\nA second example:\n\n```text\n\"a\"@b.com(c)d.com(e)f.com\n```\n\nproduces:\n\n```text\naddress: \"a@b.com d.com f.com\"\nname: \"\"\n```\n\nFor comparison, the corresponding unquoted form:\n\n```text\nuser@example.com(x)evil.com\n```\n\ntakes a different code path and is handled by the existing protection differently.\n\n## Technical Details\n\nThe issue is caused by different parsing behavior for quoted and unquoted local-parts.\n\nThe quoted-local-part variant allows the comment-separated trailing domain atoms to remain in the resulting `.address` value.\n\nThat value is then used when constructing the message envelope:\n\n```text\nenvelope.to = recipients.map(to =\u003e to.address as string)\n```\n\nNo additional strict recipient validation is performed at this boundary.\n\n## Security Impact\n\nThe confirmed impact is that attacker-controlled comment content can result in a malformed/ambiguous recipient address being accepted by the parser and propagated into `envelope.to`.\n\nThe reporter did **not confirm successful delivery to an unintended recipient through a real SMTP server using this exact quoted-local-part variant**.\n\nThe remaining question is how real SMTP servers and other Nodemailer transports handle an envelope recipient containing a value such as:\n\n```text\nuser@example.com evil.com\n```\n\nAn end-to-end SMTP test is required to determine whether this parser behavior results in an exploitable delivery or recipient-validation bypass.\n\n## Relationship to GHSA-cc9r-2j5m-2m83\n\nThis report is intended as a potential variant/follow-up to GHSA-cc9r-2j5m-2m83.\n\nThe existing advisory addresses RFC 5322 comment handling in email domains. This report identifies a separate parser path involving quoted local-parts that can preserve additional domain-like content in the normalized address.\n\nPlease evaluate whether this behavior is already covered by the existing fix or represents a remaining parser variant.\n\n## Suggested Fix\n\nThe parser should consistently reject or correctly terminate addresses containing trailing domain atoms after RFC 5322 comments, regardless of whether the local-part is quoted.\n\nIn particular:\n\n```text\n\"user\"@example.com(x)evil.com\n```\n\nshould not result in:\n\n```text\nuser@example.com evil.com\n```\n\nThe envelope-generation layer should also avoid assuming that a parser-produced address is safe for SMTP delivery without appropriate validation.\n\n## Verification Status\n\nConfirmed:\n\n* Parser accepts the quoted-local-part variant.\n* Parser produces an address containing additional attacker-controlled text.\n* The resulting address is propagated into `envelope.to`.\n\nNot confirmed by reporter:\n\n* Successful delivery through a real SMTP server.\n* Delivery to an unintended recipient.\n* Exploitability against a specific downstream SMTP implementation.",
"id": "GHSA-g57g-f23g-4646",
"modified": "2026-09-29T23:44:04Z",
"published": "2026-09-29T23:44:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-g57g-f23g-4646"
},
{
"type": "WEB",
"url": "https://github.com/nodemailer/nodemailer/commit/2f36eb1aa1dd33e312411dc9b888548e14db54ee"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodemailer/nodemailer"
},
{
"type": "WEB",
"url": "https://github.com/nodemailer/nodemailer/releases/tag/v10.0.9"
}
],
"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"
}
],
"summary": "Nodemailer: Quoted local-part can produce malformed envelope recipient through RFC 5322 comment parsing"
}
GHSA-GCR4-WCQH-3624
Vulnerability from github – Published: 2022-05-24 16:59 – Updated: 2022-05-24 16:59Go before 1.12.11 and 1.3.x before 1.13.2 can panic upon an attempt to process network traffic containing an invalid DSA public key. There are several attack scenarios, such as traffic from a client to a server that verifies client certificates.
{
"affected": [],
"aliases": [
"CVE-2019-17596"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-24T22:15:00Z",
"severity": "MODERATE"
},
"details": "Go before 1.12.11 and 1.3.x before 1.13.2 can panic upon an attempt to process network traffic containing an invalid DSA public key. There are several attack scenarios, such as traffic from a client to a server that verifies client certificates.",
"id": "GHSA-gcr4-wcqh-3624",
"modified": "2022-05-24T16:59:54Z",
"published": "2022-05-24T16:59:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17596"
},
{
"type": "WEB",
"url": "https://github.com/golang/go/issues/34960"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0101"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0329"
},
{
"type": "WEB",
"url": "https://groups.google.com/d/msg/golang-announce/lVEm7llp0w0/VbafyRkgCgAJ"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00014.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00015.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5VS3HPSE25ZSGS4RSOTADC67YNOHIGVV"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WVOWGM7IQGRO7DS2MCUMYZRQ4TYOZNAS"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20191122-0005"
},
{
"type": "WEB",
"url": "https://www.arista.com/en/support/advisories-notices/security-advisories/10134-security-advisory-46"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4551"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00043.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00044.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GM3X-23WP-HC2C
Vulnerability from github – Published: 2025-12-08 16:42 – Updated: 2025-12-17 00:44Impact
There is a potential vulnerability in Traefik managing the requests using a PathPrefix, Path or PathRegex matcher.
When Traefik is configured to route the requests to a backend using a matcher based on the path; if the request path contains an encoded restricted character from the following set ('/', '\', 'Null', ';', '?', '#'), it’s possible to target a backend, exposed using another router, by-passing the middlewares chain.
Example
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
name: my-service
spec:
routes:
- match: PathPrefix(‘/admin/’)
kind: Rule
services:
- name: service-a
port: 8080
middlewares:
- name: my-security-middleware
- match: PathPrefix(‘/’)
kind: Rule
services:
- name: service-a
port: 8080
In such a case, the request http://mydomain.example.com/admin%2F will reach the backend service-a without operating the middleware my-security-middleware and passing the security put in place for the /admin/ path.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.32
- https://github.com/traefik/traefik/releases/tag/v3.6.4
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description### Summary A vulnerability exists in Traefik’s path matching logic that allows attackers to bypass access-control middleware (e.g., blocking rules) by using URL-encoded paths. I found this vulnerability while playing PwnSec CTF 2025 with my team @0xL4ugh ### Details Traefik evaluates router rules before decoding or normalizing the request path, but forwards the request after decoding to the backend service. As a result, routes meant to block access to sensitive endpoints (such as internal, beta, or admin endpoints) can be trivially bypassed. ### PoC Traefik configuration used in this issue : ```[http.routers.flask-router-report-deny] entryPoints = ["web"] rule = "PathPrefix(`/report_note`)" priority = 10 middlewares = ["block-access"] service = "flask-service" [http.middlewares.block-access.replacePathRegex] regex = ".*" replacement = "/blocked"The intention is to block all access to /report_note.
However, the following request bypasses the block:
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66490"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-08T16:42:30Z",
"nvd_published_at": "2025-12-09T01:16:55Z",
"severity": "MODERATE"
},
"details": "## Impact\n\nThere is a potential vulnerability in Traefik managing the requests using a `PathPrefix`, `Path` or `PathRegex` matcher.\n\nWhen Traefik is configured to route the requests to a backend using a matcher based on the path; if the request path contains an encoded restricted character from the following set **(\u0027/\u0027, \u0027\\\u0027, \u0027Null\u0027, \u0027;\u0027, \u0027?\u0027, \u0027#\u0027)**, it\u2019s possible to target a backend, exposed using another router, by-passing the middlewares chain.\n\n## Example\n\n```yaml\napiVersion: traefik.io/v1alpha1\nkind: IngressRoute\nmetadata:\n name: my-service\nspec:\n routes:\n - match: PathPrefix(\u2018/admin/\u2019)\n kind: Rule\n services:\n - name: service-a\n port: 8080\n middlewares:\n - name: my-security-middleware\n - match: PathPrefix(\u2018/\u2019)\n kind: Rule\n services:\n - name: service-a\n port: 8080\n```\n\nIn such a case, the request `http://mydomain.example.com/admin%2F` will reach the backend `service-a` without operating the middleware `my-security-middleware` and passing the security put in place for the `/admin/` path.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.32\n- https://github.com/traefik/traefik/releases/tag/v3.6.4\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e### Summary\nA vulnerability exists in Traefik\u2019s path matching logic that allows attackers to bypass access-control middleware (e.g., blocking rules) by using URL-encoded paths. I found this vulnerability while playing PwnSec CTF 2025 with my team @0xL4ugh\n\n### Details\nTraefik evaluates router rules before decoding or normalizing the request path, but forwards the request after decoding to the backend service. As a result, routes meant to block access to sensitive endpoints (such as internal, beta, or admin endpoints) can be trivially bypassed.\n\n### PoC\nTraefik configuration used in this issue :\n```[http.routers.flask-router-report-deny]\n entryPoints = [\"web\"]\n rule = \"PathPrefix(`/report_note`)\"\n priority = 10\n middlewares = [\"block-access\"]\n service = \"flask-service\"\n\n[http.middlewares.block-access.replacePathRegex]\n regex = \".*\"\n replacement = \"/blocked\"\n```\nThe intention is to block all access to /report_note.\n\nHowever, the following request bypasses the block:\n```\nPOST /%2freport_note HTTP/1.1\nHost: localhost:62814\n\n\n```\n### Impact\nAccess Control Bypass:\nAny endpoint intended to be blocked (e.g., admin/debug/beta APIs) can be accessed by URL-encoding slashes or other characters.\n\nThis could lead to:\n\n- Unauthorized access to restricted endpoints\n- Execution of protected internal functionality\n- Potential privilege escalation\n- Bypass of security policies enforced via Traefik routing rules\n\u003c/details\u003e",
"id": "GHSA-gm3x-23wp-hc2c",
"modified": "2025-12-17T00:44:50Z",
"published": "2025-12-08T16:42:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-gm3x-23wp-hc2c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66490"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.11.32"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.6.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Path Normalization Bypass in Traefik Router + Middleware Rules"
}
No mitigation information available for this CWE.
CAPEC-105: HTTP Request Splitting
An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to split a single HTTP request into multiple unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).
See CanPrecede relationships for possible consequences.
CAPEC-273: HTTP Response Smuggling
An adversary manipulates and injects malicious content in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., server).
See CanPrecede relationships for possible consequences.
CAPEC-34: HTTP Response Splitting
An adversary manipulates and injects malicious content, in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., web server) or into an already spoofed HTTP response from an adversary controlled domain/site.
See CanPrecede relationships for possible consequences.