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.
228 vulnerabilities reference this CWE, most recent first.
GHSA-QC95-4862-92FH
Vulnerability from github – Published: 2026-05-27 20:13 – Updated: 2026-05-27 20:13Description
symfony/html-sanitizer lets applications sanitise untrusted HTML. The configuration methods allowLinkHosts([...]) and allowLinkSchemes([...]) are intended to restrict <a href> targets to an allowlist of hosts/schemes; allowMediaHosts() / allowMediaSchemes() do the same for <img src> etc.
Three distinct bypasses allow a content author to smuggle off-allowlist URLs past these checks. First, UrlSanitizer::parse() parses the input following RFC-3986, while browsers follow the WHATWG URL Standard which normalises \ to / before parsing the authority of "special" schemes; so an input like https://evil\@trusted.com/ parses with host trusted.com server-side but navigates to https://evil/ in the browser. Second, WHATWG collapses any run of / after the scheme into //, while RFC-3986 does not; so https:/evil.com/ and https:///evil.com/ parse as host-less (skipping the host allowlist) but resolve to evil.com in the browser. Third, UrlAttributeSanitizer checks 'a' === $element to route to the link policy and falls through to the media policy otherwise, but <area> is a navigable hyperlink equivalent to <a>; so <area href> was sanitised against the media policy (which typically allows data: and may have no host allowlist), bypassing allowLinkHosts() / allowLinkSchemes() entirely.
Resolution
UrlSanitizer::sanitize() now rejects URLs that contain a backslash or that use a special scheme (http, https, ftp, ws, wss) followed by a single slash or three slashes before parsing, eliminating the parser-differential bypasses. UrlAttributeSanitizer now applies the link policy to both <a> and <area> elements.
The patch for this issue is available here for branch 5.4.
Credits
Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/html-sanitizer"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"fixed": "6.4.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/html-sanitizer"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/html-sanitizer"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"fixed": "6.4.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"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-45066"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T20:13:04Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\n\n`symfony/html-sanitizer` lets applications sanitise untrusted HTML. The configuration methods `allowLinkHosts([...])` and `allowLinkSchemes([...])` are intended to restrict `\u003ca href\u003e` targets to an allowlist of hosts/schemes; `allowMediaHosts()` / `allowMediaSchemes()` do the same for `\u003cimg src\u003e` etc.\n\nThree distinct bypasses allow a content author to smuggle off-allowlist URLs past these checks. First, `UrlSanitizer::parse()` parses the input following RFC-3986, while browsers follow the WHATWG URL Standard which normalises `\\` to `/` before parsing the authority of \"special\" schemes; so an input like `https://evil\\@trusted.com/` parses with host `trusted.com` server-side but navigates to `https://evil/` in the browser. Second, WHATWG collapses any run of `/` after the scheme into `//`, while RFC-3986 does not; so `https:/evil.com/` and `https:///evil.com/` parse as host-less (skipping the host allowlist) but resolve to `evil.com` in the browser. Third, `UrlAttributeSanitizer` checks `\u0027a\u0027 === $element` to route to the link policy and falls through to the media policy otherwise, but `\u003carea\u003e` is a navigable hyperlink equivalent to `\u003ca\u003e`; so `\u003carea href\u003e` was sanitised against the media policy (which typically allows `data:` and may have no host allowlist), bypassing `allowLinkHosts()` / `allowLinkSchemes()` entirely.\n\n### Resolution\n\n`UrlSanitizer::sanitize()` now rejects URLs that contain a backslash or that use a special scheme (`http`, `https`, `ftp`, `ws`, `wss`) followed by a single slash or three slashes before parsing, eliminating the parser-differential bypasses. `UrlAttributeSanitizer` now applies the link policy to both `\u003ca\u003e` and `\u003carea\u003e` elements.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/d506b556d3d3906f3e8660ad82257ce87edbaac4) for branch 5.4.\n\n### Credits\n\nSymfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.",
"id": "GHSA-qc95-4862-92fh",
"modified": "2026-05-27T20:13:04Z",
"published": "2026-05-27T20:13:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-qc95-4862-92fh"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/html-sanitizer/CVE-2026-45066.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45066.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-45066"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Symfony has an HtmlSanitizer allowLinkHosts() / allowMediaHosts() Bypass via URL-Parser Differentials and \u003carea\u003e Misclassification"
}
GHSA-QCM3-7879-XCWW
Vulnerability from github – Published: 2024-08-15 21:46 – Updated: 2024-09-30 19:48Impact
Gateway API HTTPRoutes and GRPCRoutes do not follow the match precedence specified in the Gateway API specification. In particular, request headers are matched before request methods, when the specification describes that the request methods must be respected before headers are matched (HTTPRouteRule, GRPCRouteRule).
If users create Gateway API resources that use both request headers and request methods in order to route to different destinations, then traffic may be delivered to the incorrect backend. If the backend does not have Network Policy restricting acceptable traffic to receive, then requests may access information that you did not intend for them to access.
Patches
This issue was fixed in https://github.com/cilium/cilium/pull/34109.
This issue affects: - Cilium v1.15 between v1.15.0 and v1.15.7 inclusive - Cilium v1.16.0
This issue is fixed in: - Cilium v1.15.8 - Cilium v1.16.1
Workarounds
There is no workaround for this issue.
Acknowledgements
The Cilium community has worked together with members of Cure53 and Isovalent to prepare these mitigations. Special thanks to @sayboras for remediating this issue.
Further information
If you have any questions or comments about this advisory, please reach out on Slack.
If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cilium/cilium"
},
"ranges": [
{
"events": [
{
"introduced": "1.16.0"
},
{
"fixed": "1.16.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.16.0"
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cilium/cilium"
},
"ranges": [
{
"events": [
{
"introduced": "1.15.0"
},
{
"fixed": "1.15.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-42487"
],
"database_specific": {
"cwe_ids": [
"CWE-113",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-15T21:46:46Z",
"nvd_published_at": "2024-08-15T21:15:16Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nGateway API HTTPRoutes and GRPCRoutes do not follow the match precedence specified in the Gateway API specification. In particular, request headers are matched before request methods, when the specification describes that the request methods must be respected before headers are matched ([HTTPRouteRule](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule), [GRPCRouteRule](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.GRPCRouteRule)).\n\nIf users create Gateway API resources that use both request headers and request methods in order to route to different destinations, then traffic may be delivered to the incorrect backend. If the backend does not have Network Policy restricting acceptable traffic to receive, then requests may access information that you did not intend for them to access.\n\n### Patches\n\nThis issue was fixed in https://github.com/cilium/cilium/pull/34109.\n\nThis issue affects:\n- Cilium v1.15 between v1.15.0 and v1.15.7 inclusive\n- Cilium v1.16.0\n\nThis issue is fixed in:\n- Cilium v1.15.8\n- Cilium v1.16.1\n\n### Workarounds\n\nThere is no workaround for this issue.\n\n### Acknowledgements\n\nThe Cilium community has worked together with members of Cure53 and Isovalent to prepare these mitigations. Special thanks to @sayboras for remediating this issue.\n\n### Further information\n\nIf you have any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/#slack).\n\nIf you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and your report will be treated as top priority.\n",
"id": "GHSA-qcm3-7879-xcww",
"modified": "2024-09-30T19:48:17Z",
"published": "2024-08-15T21:46:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/security/advisories/GHSA-qcm3-7879-xcww"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42487"
},
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/pull/34109"
},
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/commit/a3510fe4a92305822aa1a5e08cb6d6c873c8699a"
},
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/commit/d88772b9c29e370becbc4547cada6711d51edcde"
},
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/commit/fe42273566a943a0f3174c87b23a195c856b51d6"
},
{
"type": "PACKAGE",
"url": "https://github.com/cilium/cilium"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gateway API route matching order contradicts specification"
}
GHSA-QFGR-CRR9-7R49
Vulnerability from github – Published: 2026-04-02 20:31 – Updated: 2026-05-13 16:17Summary
Rack::Utils.forwarded_values parses the RFC 7239 Forwarded header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header such as:
Forwarded: for="127.0.0.1;host=evil.com;proto=https"
can be interpreted by Rack as multiple Forwarded directives rather than as a single quoted for value.
In deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted Forwarded values differently, this discrepancy can allow an attacker to smuggle host, proto, for, or by parameters through a single header value.
Details
Rack::Utils.forwarded_values processes the header using logic equivalent to:
forwarded_header.split(';').each_with_object({}) do |field, values|
field.split(',').each do |pair|
pair = pair.split('=').map(&:strip).join('=')
return nil unless pair =~ /\A(by|for|host|proto)="?([^"]+)"?\Z/i
(values[$1.downcase.to_sym] ||= []) << $2
end
end
The method splits on ; before it parses individual name=value pairs. This is inconsistent with RFC 7239, which permits quoted-string values, and quoted strings may contain semicolons as literal content.
As a result, a header value such as:
Forwarded: for="127.0.0.1;host=evil.com;proto=https"
is not treated as a single for value. Instead, Rack may interpret it as if the client had supplied separate for, host, and proto directives.
This creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters.
Impact
Applications that rely on Forwarded to derive request metadata may observe attacker-controlled values for host, proto, for, or related URL components.
In affected deployments, this can lead to host or scheme spoofing in derived values such as req.host, req.scheme, req.base_url, or req.url. Applications that use those values for password reset links, redirects, absolute URL generation, logging, IP-based decisions, or backend requests may be vulnerable to downstream security impact.
The practical security impact depends on deployment architecture. If clients can already supply arbitrary trusted Forwarded parameters directly, this bug may not add meaningful attacker capability. The issue is most relevant where an upstream component and Rack interpret the same Forwarded header differently.
Mitigation
- Update to a patched version of Rack that parses
Forwardedquoted-string values before splitting on parameter delimiters. - Avoid trusting client-supplied
Forwardedheaders unless they are normalized or regenerated by a trusted reverse proxy. - Prefer stripping inbound
Forwardedheaders at the edge and reconstructing them from trusted proxy metadata. - Avoid using
req.host,req.scheme,req.base_url, orreq.urlfor security-sensitive operations unless the forwarding chain is explicitly trusted and validated.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0.beta1"
},
{
"fixed": "3.1.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"fixed": "3.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32762"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-02T20:31:52Z",
"nvd_published_at": "2026-04-02T18:16:27Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`Rack::Utils.forwarded_values` parses the RFC 7239 `Forwarded` header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header such as:\n\n```http\nForwarded: for=\"127.0.0.1;host=evil.com;proto=https\"\n```\n\ncan be interpreted by Rack as multiple `Forwarded` directives rather than as a single quoted `for` value.\n\nIn deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted `Forwarded` values differently, this discrepancy can allow an attacker to smuggle `host`, `proto`, `for`, or `by` parameters through a single header value.\n\n## Details\n\n`Rack::Utils.forwarded_values` processes the header using logic equivalent to:\n\n```ruby\nforwarded_header.split(\u0027;\u0027).each_with_object({}) do |field, values|\n field.split(\u0027,\u0027).each do |pair|\n pair = pair.split(\u0027=\u0027).map(\u0026:strip).join(\u0027=\u0027)\n return nil unless pair =~ /\\A(by|for|host|proto)=\"?([^\"]+)\"?\\Z/i\n (values[$1.downcase.to_sym] ||= []) \u003c\u003c $2\n end\nend\n```\n\nThe method splits on `;` before it parses individual `name=value` pairs. This is inconsistent with RFC 7239, which permits quoted-string values, and quoted strings may contain semicolons as literal content.\n\nAs a result, a header value such as:\n\n```http\nForwarded: for=\"127.0.0.1;host=evil.com;proto=https\"\n```\n\nis not treated as a single `for` value. Instead, Rack may interpret it as if the client had supplied separate `for`, `host`, and `proto` directives.\n\nThis creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters.\n\n## Impact\n\nApplications that rely on `Forwarded` to derive request metadata may observe attacker-controlled values for `host`, `proto`, `for`, or related URL components.\n\nIn affected deployments, this can lead to host or scheme spoofing in derived values such as `req.host`, `req.scheme`, `req.base_url`, or `req.url`. Applications that use those values for password reset links, redirects, absolute URL generation, logging, IP-based decisions, or backend requests may be vulnerable to downstream security impact.\n\nThe practical security impact depends on deployment architecture. If clients can already supply arbitrary trusted `Forwarded` parameters directly, this bug may not add meaningful attacker capability. The issue is most relevant where an upstream component and Rack interpret the same `Forwarded` header differently.\n\n## Mitigation\n\n* Update to a patched version of Rack that parses `Forwarded` quoted-string values before splitting on parameter delimiters.\n* Avoid trusting client-supplied `Forwarded` headers unless they are normalized or regenerated by a trusted reverse proxy.\n* Prefer stripping inbound `Forwarded` headers at the edge and reconstructing them from trusted proxy metadata.\n* Avoid using `req.host`, `req.scheme`, `req.base_url`, or `req.url` for security-sensitive operations unless the forwarding chain is explicitly trusted and validated.",
"id": "GHSA-qfgr-crr9-7r49",
"modified": "2026-05-13T16:17:51Z",
"published": "2026-04-02T20:31:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack/security/advisories/GHSA-qfgr-crr9-7r49"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32762"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-32762.yml"
}
],
"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"
}
],
"summary": "Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing"
}
GHSA-QHWR-MFCX-QRR9
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39An improper interpretation conflict of certain data between certain software components within the Juniper Networks Junos OS devices does not allow certain traffic to pass through the device upon receipt from an ingress interface filtering certain specific types of traffic which is then being redirected to an egress interface on a different VLAN. This causes a Denial of Service (DoS) to those clients sending these particular types of traffic. Such traffic being sent by a client may appear genuine, but is non-standard in nature and should be considered as potentially malicious, and can be targeted to the device, or destined through it for the issue to occur. This issues affects IPv4 and IPv6 traffic. An indicator of compromise may be found by checking log files. You may find that traffic on the input interface has 100% of traffic flowing into the device, yet the egress interface shows 0 pps leaving the device. For example: [show interfaces "interface" statistics detail] Output between two interfaces would reveal something similar to: Ingress, first interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/0 Up 9999999999 (9999) 1 (0) -------------------- Egress, second interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/1 Up 0 (0) 9999999999 (0) -------------------- Dropped packets will not show up in DDoS monitoring/protection counters as issue is not caused by anti-DDoS protection mechanisms. This issue affects: Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S7 on NFX250, QFX5K Series, EX4600; 17.4 versions prior to 17.4R2-S11, 17.4R3-S3 on NFX250, QFX5K Series, EX4600; 18.1 versions prior to 18.1R3-S9 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4600; 18.2 versions prior to 18.2R3-S3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600; 18.3 versions prior to 18.3R3-S1 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.2 versions prior to 19.2R1-S5, 19.2R2 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.3 versions prior to 19.3R2-S3, 19.3R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.4 versions prior to 19.4R1-S2, 19.4R2 on NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series. This issue does not affect Junos OS releases prior to 17.2R2.
{
"affected": [],
"aliases": [
"CVE-2021-0207"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-15T18:15:00Z",
"severity": "HIGH"
},
"details": "An improper interpretation conflict of certain data between certain software components within the Juniper Networks Junos OS devices does not allow certain traffic to pass through the device upon receipt from an ingress interface filtering certain specific types of traffic which is then being redirected to an egress interface on a different VLAN. This causes a Denial of Service (DoS) to those clients sending these particular types of traffic. Such traffic being sent by a client may appear genuine, but is non-standard in nature and should be considered as potentially malicious, and can be targeted to the device, or destined through it for the issue to occur. This issues affects IPv4 and IPv6 traffic. An indicator of compromise may be found by checking log files. You may find that traffic on the input interface has 100% of traffic flowing into the device, yet the egress interface shows 0 pps leaving the device. For example: [show interfaces \"interface\" statistics detail] Output between two interfaces would reveal something similar to: Ingress, first interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/0 Up 9999999999 (9999) 1 (0) -------------------- Egress, second interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/1 Up 0 (0) 9999999999 (0) -------------------- Dropped packets will not show up in DDoS monitoring/protection counters as issue is not caused by anti-DDoS protection mechanisms. This issue affects: Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S7 on NFX250, QFX5K Series, EX4600; 17.4 versions prior to 17.4R2-S11, 17.4R3-S3 on NFX250, QFX5K Series, EX4600; 18.1 versions prior to 18.1R3-S9 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4600; 18.2 versions prior to 18.2R3-S3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600; 18.3 versions prior to 18.3R3-S1 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.2 versions prior to 19.2R1-S5, 19.2R2 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.3 versions prior to 19.3R2-S3, 19.3R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.4 versions prior to 19.4R1-S2, 19.4R2 on NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series. This issue does not affect Junos OS releases prior to 17.2R2.",
"id": "GHSA-qhwr-mfcx-qrr9",
"modified": "2022-05-24T17:39:19Z",
"published": "2022-05-24T17:39:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0207"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11097"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-R6QF-8968-WJ9Q
Vulnerability from github – Published: 2026-03-09 19:54 – Updated: 2026-03-30 13:30OpenClaw's system.run dispatch-wrapper handling applied different depth-boundary rules to shell-wrapper approval detection and execution planning.
With exactly four transparent dispatch wrappers such as repeated env invocations before /bin/sh -c, the approval classifier could stop treating the command as a shell wrapper at the depth boundary while execution planning still unwrapped through to the shell payload. In security=allowlist mode, that mismatch could skip the expected approval-required path for the shell wrapper invocation.
Latest published npm version: 2026.3.2
Fixed on main on March 7, 2026 in 2fc95a7cfc1eb9306356510b0251b6d51fb1c0b0 by keeping shell-wrapper classification active at the configured dispatch depth boundary and only failing closed beyond that boundary. This aligns approval gating with the execution plan. Legitimate shallow dispatch-wrapper usage continues to work.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
<= 2026.3.2 - Patched version:
>= 2026.3.7
Fix Commit(s)
2fc95a7cfc1eb9306356510b0251b6d51fb1c0b0
Release Process Note
npm 2026.3.7 was published on March 8, 2026. This advisory is fixed in the released package.
Thanks @tdjackey for reporting.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.3.2"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27183"
],
"database_specific": {
"cwe_ids": [
"CWE-436",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-09T19:54:25Z",
"nvd_published_at": "2026-03-23T22:16:25Z",
"severity": "LOW"
},
"details": "OpenClaw\u0027s `system.run` dispatch-wrapper handling applied different depth-boundary rules to shell-wrapper approval detection and execution planning.\n\nWith exactly four transparent dispatch wrappers such as repeated `env` invocations before `/bin/sh -c`, the approval classifier could stop treating the command as a shell wrapper at the depth boundary while execution planning still unwrapped through to the shell payload. In `security=allowlist` mode, that mismatch could skip the expected approval-required path for the shell wrapper invocation.\n\nLatest published npm version: `2026.3.2`\n\nFixed on `main` on March 7, 2026 in `2fc95a7cfc1eb9306356510b0251b6d51fb1c0b0` by keeping shell-wrapper classification active at the configured dispatch depth boundary and only failing closed beyond that boundary. This aligns approval gating with the execution plan. Legitimate shallow dispatch-wrapper usage continues to work.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.3.2`\n- Patched version: `\u003e= 2026.3.7`\n\n## Fix Commit(s)\n\n- `2fc95a7cfc1eb9306356510b0251b6d51fb1c0b0`\n\n## Release Process Note\n\nnpm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.\n\nThanks @tdjackey for reporting.",
"id": "GHSA-r6qf-8968-wj9q",
"modified": "2026-03-30T13:30:28Z",
"published": "2026-03-09T19:54:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-r6qf-8968-wj9q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27183"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/2fc95a7cfc1eb9306356510b0251b6d51fb1c0b0"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.7"
},
{
"type": "WEB",
"url": "https://vulncheck.com/advisories/openclaw-mar-shell-approval-gating-bypass-via-dispatch-wrapper-depth-mismatch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: system.run wrapper-depth boundary could skip shell approval gating"
}
GHSA-RM86-H44C-2R2M
Vulnerability from github – Published: 2024-07-24 06:31 – Updated: 2025-11-04 19:49In OpenStack Nova before 27.4.1, 28 before 28.2.1, and 29 before 29.1.1, by supplying a raw format image that is actually a crafted QCOW2 image with a backing file path or VMDK flat image with a descriptor file path, an authenticated user may convince systems to return a copy of the referenced file's contents from the server, resulting in unauthorized access to potentially sensitive data. All Nova deployments are affected. NOTE: this issue exists because of an incomplete fix for CVE-2022-47951 and CVE-2024-32498.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Nova"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "27.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "Nova"
},
"ranges": [
{
"events": [
{
"introduced": "28.0.0"
},
{
"last_affected": "28.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "Nova"
},
"ranges": [
{
"events": [
{
"introduced": "29.0.0"
},
{
"last_affected": "29.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-40767"
],
"database_specific": {
"cwe_ids": [
"CWE-436",
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-25T14:27:53Z",
"nvd_published_at": "2024-07-24T05:15:12Z",
"severity": "MODERATE"
},
"details": "In OpenStack Nova before 27.4.1, 28 before 28.2.1, and 29 before 29.1.1, by supplying a raw format image that is actually a crafted QCOW2 image with a backing file path or VMDK flat image with a descriptor file path, an authenticated user may convince systems to return a copy of the referenced file\u0027s contents from the server, resulting in unauthorized access to potentially sensitive data. All Nova deployments are affected. NOTE: this issue exists because of an incomplete fix for CVE-2022-47951 and CVE-2024-32498.",
"id": "GHSA-rm86-h44c-2r2m",
"modified": "2025-11-04T19:49:52Z",
"published": "2024-07-24T06:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40767"
},
{
"type": "PACKAGE",
"url": "https://github.com/openstack/nova"
},
{
"type": "WEB",
"url": "https://launchpad.net/bugs/2071734"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00017.html"
},
{
"type": "WEB",
"url": "https://review.opendev.org/c/openstack/nova/+/924731"
},
{
"type": "WEB",
"url": "https://security.openstack.org"
},
{
"type": "WEB",
"url": "https://security.openstack.org/ossa/OSSA-2024-002.html"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2024/07/23/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenStack Nova vulnerable to unauthorized access to potentially sensitive data "
}
GHSA-RQRH-6WCG-WQW7
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11Firefox incorrectly treated an inline list-item element as a block element, resulting in an out of bounds read or memory corruption, and a potentially exploitable crash. This vulnerability affects Thunderbird < 78.13, Thunderbird < 91, Firefox ESR < 78.13, and Firefox < 91.
{
"affected": [],
"aliases": [
"CVE-2021-29988"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-17T20:15:00Z",
"severity": "HIGH"
},
"details": "Firefox incorrectly treated an inline list-item element as a block element, resulting in an out of bounds read or memory corruption, and a potentially exploitable crash. This vulnerability affects Thunderbird \u003c 78.13, Thunderbird \u003c 91, Firefox ESR \u003c 78.13, and Firefox \u003c 91.",
"id": "GHSA-rqrh-6wcg-wqw7",
"modified": "2022-05-24T19:11:20Z",
"published": "2022-05-24T19:11:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29988"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1717922"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202202-03"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202208-14"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2021-33"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2021-34"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2021-35"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2021-36"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RW39-5899-8MXP
Vulnerability from github – Published: 2026-03-13 15:47 – Updated: 2026-04-06 22:37Summary
In affected versions of openclaw, node-host system.run approvals could display only an extracted shell payload such as jq --version while execution still ran a different outer wrapper argv such as ./env sh -c 'jq --version'.
Impact
This is an approval-integrity bug. An attacker who could place or select a local wrapper binary and induce a wrapper-shaped command could get local code executed after the operator approved misleading command text.
Affected Packages and Versions
- Package:
openclaw(npm) - Affected versions:
<= 2026.3.8 - Fixed in:
2026.3.11
Technical Details
Wrapper resolution normalized executables by basename and extracted inner shell payload text for approval display, while execution still preserved the full wrapper argv. Approval storage and UI therefore showed text that did not match the exact command OpenClaw would execute.
Fix
OpenClaw now binds approvals to the exact executed argv and keeps extracted shell payload text only as secondary preview data. The fix shipped in openclaw@2026.3.11.
Workarounds
Upgrade to 2026.3.11 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32971"
],
"database_specific": {
"cwe_ids": [
"CWE-436",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T15:47:46Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\nIn affected versions of `openclaw`, node-host `system.run` approvals could display only an extracted shell payload such as `jq --version` while execution still ran a different outer wrapper argv such as `./env sh -c \u0027jq --version\u0027`.\n\n## Impact\nThis is an approval-integrity bug. An attacker who could place or select a local wrapper binary and induce a wrapper-shaped command could get local code executed after the operator approved misleading command text.\n\n## Affected Packages and Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.3.8`\n- Fixed in: `2026.3.11`\n\n## Technical Details\nWrapper resolution normalized executables by basename and extracted inner shell payload text for approval display, while execution still preserved the full wrapper argv. Approval storage and UI therefore showed text that did not match the exact command OpenClaw would execute.\n\n## Fix\nOpenClaw now binds approvals to the exact executed argv and keeps extracted shell payload text only as secondary preview data. The fix shipped in `openclaw@2026.3.11`.\n\n## Workarounds\nUpgrade to `2026.3.11` or later.",
"id": "GHSA-rw39-5899-8mxp",
"modified": "2026-04-06T22:37:28Z",
"published": "2026-03-13T15:47:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-rw39-5899-8mxp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32971"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.11"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-node-host-approval-ui-mismatch-allows-execution-of-unintended-commands"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenClaw: Node-host approvals could show misleading shell payloads instead of the executed argv"
}
GHSA-V293-3P6G-J7W7
Vulnerability from github – Published: 2024-04-10 18:30 – Updated: 2024-04-10 18:30An incorrect string comparison vulnerability in Palo Alto Networks PAN-OS software prevents Predefined Decryption Exclusions from functioning as intended. This can cause traffic destined for domains that are not specified in Predefined Decryption Exclusions to be unintentionally excluded from decryption.
{
"affected": [],
"aliases": [
"CVE-2024-3386"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-10T17:15:57Z",
"severity": "MODERATE"
},
"details": "An incorrect string comparison vulnerability in Palo Alto Networks PAN-OS software prevents Predefined Decryption Exclusions from functioning as intended. This can cause traffic destined for domains that are not specified in Predefined Decryption Exclusions to be unintentionally excluded from decryption.",
"id": "GHSA-v293-3p6g-j7w7",
"modified": "2024-04-10T18:30:48Z",
"published": "2024-04-10T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3386"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2024-3386"
}
],
"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-V2HH-GCRM-F6HX
Vulnerability from github – Published: 2026-07-21 22:08 – Updated: 2026-07-21 22:08Impact
fast-uri v4.1.0 and earlier do not treat a literal backslash (U+005C) as an authority delimiter. Node's native WHATWG URL (used by fetch(), undici, and Node's http/https clients) normalizes \ to / for special schemes (http, https, ws, wss, ftp, file), so the two parsers extract different hosts from the same input string.
For example, http://evil.com\@allowed.com is treated by fast-uri as host allowed.com with userinfo evil.com\, while Node's WHATWG URL parser and fetch() see host evil.com with path /@allowed.com.
Applications that use fast-uri to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination, including cloud metadata endpoints, loopback, or internal hosts.
Patches
Upgrade to fast-uri v4.1.1, v3.1.4, or v2.4.3.
Workarounds
None. Upgrade to the patched version.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.4.2"
},
"package": {
"ecosystem": "npm",
"name": "fast-uri"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.1"
},
{
"fixed": "2.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.3"
},
"package": {
"ecosystem": "npm",
"name": "fast-uri"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.0"
},
"package": {
"ecosystem": "npm",
"name": "fast-uri"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-16221"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T22:08:28Z",
"nvd_published_at": "2026-07-19T15:16:49Z",
"severity": "HIGH"
},
"details": "### Impact\n\n`fast-uri` v4.1.0 and earlier do not treat a literal backslash (U+005C) as an authority delimiter. Node\u0027s native WHATWG `URL` (used by `fetch()`, `undici`, and Node\u0027s `http`/`https` clients) normalizes `\\` to `/` for special schemes (`http`, `https`, `ws`, `wss`, `ftp`, `file`), so the two parsers extract different hosts from the same input string.\n\nFor example, `http://evil.com\\@allowed.com` is treated by `fast-uri` as host `allowed.com` with userinfo `evil.com\\`, while Node\u0027s WHATWG URL parser and `fetch()` see host `evil.com` with path `/@allowed.com`.\n\nApplications that use `fast-uri` to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node\u0027s URL or `fetch()` consumers see a policy/use desync and can be steered to an unintended destination, including cloud metadata endpoints, loopback, or internal hosts.\n\n### Patches\n\nUpgrade to `fast-uri` v4.1.1, v3.1.4, or v2.4.3.\n\n### Workarounds\n\nNone. Upgrade to the patched version.",
"id": "GHSA-v2hh-gcrm-f6hx",
"modified": "2026-07-21T22:08:29Z",
"published": "2026-07-21T22:08:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fastify/fast-uri/security/advisories/GHSA-v2hh-gcrm-f6hx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16221"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fast-uri/commit/0542a216860fd70c062a4730e620576f62ded057"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fast-uri/commit/2d50fbabc80e4d0884fe0f6a98fe118ce6faa353"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fast-uri/commit/9438266d6a7ded688c8bc7c4ba506da17f44a17b"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/fastify/fast-uri"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fast-uri/releases/tag/v2.4.3"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fast-uri/releases/tag/v3.1.4"
},
{
"type": "WEB",
"url": "https://github.com/fastify/fast-uri/releases/tag/v4.1.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "fast-uri vulnerable to host confusion via literal backslash authority delimiter"
}
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.