Common Weakness Enumeration

CWE-436

Allowed-with-Review

Interpretation Conflict

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

199 vulnerabilities reference this CWE, most recent first.

GHSA-PJ7V-XFVX-WMJQ

Vulnerability from github – Published: 2026-06-26 21:54 – Updated: 2026-06-26 21:54
VLAI
Summary
Hackney has SSRF allowlist bypass in hackney_url:normalize/2 via percent-encoded host
Details

Summary

hackney_url:normalize/2 URL-decodes the host component of a parsed URL, but the caller's SSRF allowlist runs before normalization using OTP's uri_string:parse/1 and inet:parse_address/1, neither of which decodes percent-escapes in hostnames. A URL like http://%31%32%37%2E%30%2E%30%2E%31/ presents an encoded, non-IP-looking host to the validator, which passes the allowlist check; hackney's normalizer then decodes it to 127.0.0.1 and connects to loopback. Because hackney:request/5 always calls normalize/2 with no opt-out, every request path that accepts a binary or list URL is affected. This is a parser-differential SSRF in the same class as CVE-2025-1211, but in a different function.

Details

In src/hackney_url.erl (lines 161–186), normalize/2 checks whether the parsed host is already a dotted-quad or IPv6 literal via inet_parse:address/1. Percent-encoded forms like %31%32%37%2E%30%2E%30%2E%31 fail that check and fall into the catch-all branch, where urldecode/1 decodes the host before passing it to IDNA conversion:

Host1 = binary_to_list(
           urldecode(unicode:characters_to_binary(Host0))
         ),

The decoded host ("127.0.0.1") replaces the original in the returned #hackney_url{} record. hackney:request/5 at src/hackney.erl:463 always calls normalize/2, so the decoded host is what do_dispatch/1 and add_host_header/2 ultimately use. The on-wire Host: header and the TCP connect target both reflect the decoded value.

The same payload pattern reaches the AWS/GCP/Azure IMDS (169.254.169.254), RFC1918 ranges, and any localhost admin endpoint. The 1.21.0 patch for CVE-2025-1211 fixed a separate differential in parse_url/1 and did not touch normalize/2.

PoC

  1. Validate the URL with the canonical Erlang SSRF allowlist: uri_string:parse/1 returns host <<"%31%32%37%2E%30%2E%30%2E%31">>, inet:parse_address/1 returns {error, einval}, so the allowlist accepts it.
  2. Pass the same URL to hackney:get/1.
  3. hackney's normalize/2 decodes the host to "127.0.0.1" and connects to 127.0.0.1:80. The internal service receives the request with Host: 127.0.0.1.

Impact

Unauthenticated SSRF bypassing the canonical Erlang allowlist pattern. Affects hackney 0.13.0 through 4.0.0 for any application that accepts attacker-supplied URLs. Targets include cloud IMDS endpoints, localhost admin interfaces, and RFC1918 backends. CVSS v4.0: 6.9 (MEDIUM).

Resources

  • Introduction commit: https://github.com/benoitc/hackney/commit/4d725507588942fd00efca15b86da3273656510a
  • Patch commit: https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f
Severity
6.9 (Medium)
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "hackney"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.13.0"
            },
            {
              "fixed": "4.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47076"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T21:54:55Z",
    "nvd_published_at": "2026-05-25T15:16:22Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`hackney_url:normalize/2` URL-decodes the host component of a parsed URL, but the caller\u0027s SSRF allowlist runs before normalization using OTP\u0027s `uri_string:parse/1` and `inet:parse_address/1`, neither of which decodes percent-escapes in hostnames. A URL like `http://%31%32%37%2E%30%2E%30%2E%31/` presents an encoded, non-IP-looking host to the validator, which passes the allowlist check; hackney\u0027s normalizer then decodes it to `127.0.0.1` and connects to loopback. Because `hackney:request/5` always calls `normalize/2` with no opt-out, every request path that accepts a binary or list URL is affected. This is a parser-differential SSRF in the same class as CVE-2025-1211, but in a different function.\n\n### Details\n\nIn `src/hackney_url.erl` (lines 161\u2013186), `normalize/2` checks whether the parsed host is already a dotted-quad or IPv6 literal via `inet_parse:address/1`. Percent-encoded forms like `%31%32%37%2E%30%2E%30%2E%31` fail that check and fall into the catch-all branch, where `urldecode/1` decodes the host before passing it to IDNA conversion:\n\n```erlang\nHost1 = binary_to_list(\n           urldecode(unicode:characters_to_binary(Host0))\n         ),\n```\n\nThe decoded host (`\"127.0.0.1\"`) replaces the original in the returned `#hackney_url{}` record. `hackney:request/5` at `src/hackney.erl:463` always calls `normalize/2`, so the decoded host is what `do_dispatch/1` and `add_host_header/2` ultimately use. The on-wire `Host:` header and the TCP connect target both reflect the decoded value.\n\nThe same payload pattern reaches the AWS/GCP/Azure IMDS (`169.254.169.254`), RFC1918 ranges, and any `localhost` admin endpoint. The 1.21.0 patch for CVE-2025-1211 fixed a separate differential in `parse_url/1` and did not touch `normalize/2`.\n\n### PoC\n\n1. Validate the URL with the canonical Erlang SSRF allowlist: `uri_string:parse/1` returns host `\u003c\u003c\"%31%32%37%2E%30%2E%30%2E%31\"\u003e\u003e`, `inet:parse_address/1` returns `{error, einval}`, so the allowlist accepts it.\n2. Pass the same URL to `hackney:get/1`.\n3. hackney\u0027s `normalize/2` decodes the host to `\"127.0.0.1\"` and connects to `127.0.0.1:80`. The internal service receives the request with `Host: 127.0.0.1`.\n\n### Impact\n\nUnauthenticated SSRF bypassing the canonical Erlang allowlist pattern. Affects hackney 0.13.0 through 4.0.0 for any application that accepts attacker-supplied URLs. Targets include cloud IMDS endpoints, `localhost` admin interfaces, and RFC1918 backends. CVSS v4.0: **6.9 (MEDIUM)**.\n\n## Resources\n\n* Introduction commit: https://github.com/benoitc/hackney/commit/4d725507588942fd00efca15b86da3273656510a\n* Patch commit: https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f",
  "id": "GHSA-pj7v-xfvx-wmjq",
  "modified": "2026-06-26T21:54:55Z",
  "published": "2026-06-26T21:54:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/benoitc/hackney/security/advisories/GHSA-pj7v-xfvx-wmjq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47076"
    },
    {
      "type": "WEB",
      "url": "https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-47076.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/benoitc/hackney"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-47076"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Hackney has SSRF allowlist bypass in hackney_url:normalize/2 via percent-encoded host"
}

GHSA-PQHF-P39G-3X64

Vulnerability from github – Published: 2025-10-29 22:12 – Updated: 2025-10-29 22:12
VLAI
Summary
uv allows ZIP payload obfuscation through parsing differentials
Details

Impact

In versions 0.9.5 and earlier of uv, ZIP archives were handled in a manner that enabled two parsing differentials against other components of the Python packaging ecosystem:

  1. Central directory entries in a ZIP archive can contain comment fields. However, uv would assume that these fields were not present, since they aren't widely used. Consequently, a ZIP archive could be constructed where uv would interpret the contents of a central directory comment field as ZIP control structures (such as a new central directory entry), rather than skipping over them.
  2. Both local file entries and central directory entries contain filename fields, which are used to place archive members on disk. These fields are arbitrary sequences of bytes, and may therefore be invalid or ambiguous. For example, they may contain ASCII null bytes, in which case different ZIP extractors behave differently: Python's zipfile module truncates the filename at the first null, while uv would skip (not extract) any archive members whose filenames contained nulls. Because of this difference, a ZIP archive could be constructed that would extract differently across different Python package installers.

In both cases, the outcome is that an attacker may be able to produce a ZIP with a consistent digest that expands differently with different Python package installers.

Like with GHSA-8qf3-x8v5-2pj8, the impact of these differentials is limited by a number of factors:

  • To be compromised via this vulnerability, user interaction of some sort is required. In particular, the user must run uv pip install $package or similar with an attacker-controlled $package. When using wheel distributions, installation of the malicious package is not sufficient for execution of malicious code, the vicim would need to perform a separate invocation, e.g., python -c "import $package".
  • If a ZIP-based source distribution (which are less common than tarball source distributions), is encountered, malicious code can be executed during package resolution or installation. uv may invoke the malicious code when building the source distribution into a wheel.

Patches

Versions 0.9.6 and newer of uv address both of the parser differentials above, by properly handling comments in central directory entries and by refusing to process ZIPs that contain filename fields that are unlikely to be interpreted consistently across other ZIP parser implementations.

Workarounds

Users are advised to upgrade to 0.9.6 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. However, users who do experience breakage should carefully review their distributions for signs of malicious intent. Users may choose to set UV_INSECURE_NO_ZIP_VALIDATION=1 to revert to the previous behavior.

Attribution

This vulnerability was disclosed by Caleb Brown (Google).

Severity
6.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "uv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-29T22:12:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nIn versions 0.9.5 and earlier of uv, ZIP archives were handled in a manner that enabled two parsing differentials against other components of the Python packaging ecosystem:\n\n1. Central directory entries in a ZIP archive can contain comment fields. However, uv would assume that these fields were not present, since they aren\u0027t widely used. Consequently, a ZIP archive could be constructed where uv would interpret the contents of a central directory comment field as ZIP control structures (such as a new central directory entry), rather than skipping over them.\n2. Both local file entries and central directory entries contain filename fields, which are used to place archive members on disk. These fields are arbitrary sequences of bytes, and may therefore be invalid or ambiguous. For example, they may contain ASCII null bytes, in which case different ZIP extractors behave differently: Python\u0027s `zipfile` module truncates the filename at the first null, while uv would skip (not extract) any archive members whose filenames contained nulls. Because of this difference, a ZIP archive could be constructed that would extract differently across different Python package installers.\n\nIn both cases, the outcome is that an attacker may be able to produce a ZIP with a consistent digest that expands differently with different Python package installers.\n\nLike with GHSA-8qf3-x8v5-2pj8, the impact of these differentials is limited by a number of factors:\n\n- To be compromised via this vulnerability, user interaction of some sort is required. In particular, the user must run `uv pip install $package` or similar with an attacker-controlled $package.\nWhen using wheel distributions, installation of the malicious package is not sufficient for execution of malicious code, the vicim would need to perform a separate invocation, e.g., `python -c \"import $package\"`.\n- If a ZIP-based source distribution (which are less common than tarball source distributions), is encountered, malicious code can be executed during package resolution or installation. uv may invoke the malicious code when building the source distribution into a wheel.\n\n### Patches\n\nVersions 0.9.6 and newer of uv address both of the parser differentials above, by properly handling comments in central directory entries and by refusing to process ZIPs that contain filename fields that are unlikely to be interpreted consistently across other ZIP parser implementations.\n\n### Workarounds\n\nUsers are advised to upgrade to 0.9.6 or newer to address this advisory.\n\nMost users should experience no breaking changes as a result of the patch above. However, users who do experience breakage should carefully review their distributions for signs of malicious intent. Users may choose to set `UV_INSECURE_NO_ZIP_VALIDATION=1` to revert to the previous behavior.\n\n### Attribution\n\nThis vulnerability was disclosed by Caleb Brown (Google).",
  "id": "GHSA-pqhf-p39g-3x64",
  "modified": "2025-10-29T22:12:57Z",
  "published": "2025-10-29T22:12:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/security/advisories/GHSA-pqhf-p39g-3x64"
    },
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/uv/commit/da659fee4898a73dbc75070f3e82d49f745e4628"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/astral-sh/uv"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "uv allows ZIP payload obfuscation through parsing differentials"
}

GHSA-Q2QJ-628G-VHFW

Vulnerability from github – Published: 2023-04-18 22:20 – Updated: 2023-05-22 14:38
VLAI
Summary
Insecure header validation in slim/psr7
Details

Impact

An attacker could sneak in a newline (\n) into both the header names and values. While the specification states that \r\n\r\n is used to terminate the header list, many servers in the wild will also accept \n\n. An attacker that is able to control the header names that are passed to Slilm-Psr7 would be able to intentionally craft invalid messages, possibly causing application errors or invalid HTTP requests being sent out with an PSR-18 HTTP client. The latter might present a denial of service vector if a remote service’s web application firewall bans the application due to the receipt of malformed requests.

Patches

The issue is patched in 1.6.1, 1.5.1, and 1.4.1.

Workarounds

In Slim-Psr7 prior to 1.6.1, 1.5.1, and 1.4.1, validate HTTP header keys and/or values, and if using user-supplied values, filter them to strip off leading or trailing newline characters before calling withHeader().

Acknowledgments

We are very grateful to and thank Graham Campbell for reporting and working with us on this issue.

References

  • Guzzle: CVE-2023-29197, with advisory GHSA-wxmh-65f7-jcvw
  • Laminas Diactoros: CVE-2023-29530, with advisory GHSA-xv3h-4844-9h36
  • https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "slim/psr7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6"
            },
            {
              "fixed": "1.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "slim/psr7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5"
            },
            {
              "fixed": "1.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "slim/psr7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-18T22:20:42Z",
    "nvd_published_at": "2023-04-17T22:15:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn attacker could sneak in a newline (`\\n`) into both the header names and values. While the specification states that `\\r\\n\\r\\n` is used to terminate the header list, many servers in the wild will also accept `\\n\\n`. An attacker that is able to control the header names that are passed to Slilm-Psr7 would be able to intentionally craft invalid messages, possibly causing application errors or invalid HTTP requests being sent out with an PSR-18 HTTP client. The latter might present a denial of service vector if a remote service\u2019s web application firewall bans the application due to the receipt of malformed requests.\n\n### Patches\n\nThe issue is patched in 1.6.1, 1.5.1, and 1.4.1.\n\n### Workarounds\n\nIn Slim-Psr7 prior to 1.6.1, 1.5.1, and 1.4.1, validate HTTP header keys and/or values, and if using user-supplied values, filter them to strip off leading or trailing newline characters before calling withHeader().\n\n### Acknowledgments\n\nWe are very grateful to and thank \u003ca href=\"https://gjcampbell.co.uk/\"\u003eGraham Campbell\u003c/a\u003e for reporting and working with us on this issue.\n\n### References\n\n* Guzzle: CVE-2023-29197, with advisory GHSA-wxmh-65f7-jcvw\n* Laminas Diactoros: CVE-2023-29530, with advisory GHSA-xv3h-4844-9h36\n* https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4",
  "id": "GHSA-q2qj-628g-vhfw",
  "modified": "2023-05-22T14:38:30Z",
  "published": "2023-04-18T22:20:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/security/advisories/GHSA-q2qj-628g-vhfw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30536"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/issues/284#issuecomment-1541328898"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/commit/ed1d553225dd190875d8814c47460daed4b550bb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/slimphp/Slim-Psr7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/releases/tag/1.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/releases/tag/1.5.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/slimphp/Slim-Psr7/releases/tag/1.6.1"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Insecure header validation in slim/psr7"
}

GHSA-Q382-VC8Q-7JHJ

Vulnerability from github – Published: 2026-03-19 12:44 – Updated: 2026-03-19 12:44
VLAI
Summary
Improper handling of null Unicode character when parsing JSON in github.com/modelcontextprotocol/go-sdk
Details

The Go SDK recently transitioned to the segmentio/encoding library for JSON parsing in version 1.3.1. While this change addressed both case-insensitivity and ASCII folding issues, the new parser implemented aggressive key matching that treated keys with null Unicode characters appended at the end as equivalent to their base strings.

Impact

When combined with duplicate keys, the described behavior leads to a "last key wins" resolution that could override the intended MCP message. This had the potential for: - Bypassing intermediary inspection: Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages. - Cross-implementation inconsistency: Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.

Fix:

The segmentio/encoding package was patched with a fix in https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb and a new version of the package was released (v0.5.4). The SDK switched to the patched version of the dependency in 724dd47aa. Users are advised to update to v1.4.1 to resolve this issue.

Credits:

Thank you to Francesco Lacerenza (Doyensec) for reporting this issue.

Severity
8.2 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/modelcontextprotocol/go-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T12:44:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The Go SDK recently transitioned to the `segmentio/encoding` library for JSON parsing in version 1.3.1. While this change addressed both case-insensitivity and ASCII folding issues, the new parser implemented aggressive key matching that treated keys with `null` Unicode characters appended at the end as equivalent to their base strings.\n\n#### Impact\n\nWhen combined with duplicate keys, the described behavior leads to a \"last key wins\" resolution that could override the intended MCP message. This had the potential for:\n  - **Bypassing intermediary inspection:** Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages.\n  - **Cross-implementation inconsistency:** Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.\n\n####  Fix:\n\nThe `segmentio/encoding` package was patched with a fix in https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb and a new version of the package was released (`v0.5.4`). The SDK switched to the patched version of the dependency in 724dd47aa. Users are advised to update to v1.4.1 to resolve this issue.\n\n#### Credits:\nThank you to Francesco Lacerenza (Doyensec) for reporting this issue.",
  "id": "GHSA-q382-vc8q-7jhj",
  "modified": "2026-03-19T12:44:07Z",
  "published": "2026-03-19T12:44:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/go-sdk/security/advisories/GHSA-q382-vc8q-7jhj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/go-sdk/commit/724dd47aa3431b9d4cf9ac2eebbf7b38a629afca"
    },
    {
      "type": "WEB",
      "url": "https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/go-sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Improper handling of null Unicode character when parsing JSON in github.com/modelcontextprotocol/go-sdk"
}

GHSA-Q6HR-VM49-FVM5

Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12
VLAI
Details

A vulnerability in the VXLAN Operation, Administration, and Maintenance (OAM) feature of Cisco NX-OS Software, known as NGOAM, could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to improper handling of specific packets with a Transparent Interconnection of Lots of Links (TRILL) OAM EtherType. An attacker could exploit this vulnerability by sending crafted packets, including the TRILL OAM EtherType of 0x8902, to a device that is part of a VXLAN Ethernet VPN (EVPN) fabric. A successful exploit could allow the attacker to cause an affected device to experience high CPU usage and consume excessive system resources, which may result in overall control plane instability and cause the affected device to reload. Note: The NGOAM feature is disabled by default.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-1587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-25T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the VXLAN Operation, Administration, and Maintenance (OAM) feature of Cisco NX-OS Software, known as NGOAM, could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to improper handling of specific packets with a Transparent Interconnection of Lots of Links (TRILL) OAM EtherType. An attacker could exploit this vulnerability by sending crafted packets, including the TRILL OAM EtherType of 0x8902, to a device that is part of a VXLAN Ethernet VPN (EVPN) fabric. A successful exploit could allow the attacker to cause an affected device to experience high CPU usage and consume excessive system resources, which may result in overall control plane instability and cause the affected device to reload. Note: The NGOAM feature is disabled by default.",
  "id": "GHSA-q6hr-vm49-fvm5",
  "modified": "2022-05-24T19:12:08Z",
  "published": "2022-05-24T19:12:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1587"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nxos-ngoam-dos-LTDb9Hv"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-Q6R2-X2CC-VRP7

Vulnerability from github – Published: 2025-01-14 21:20 – Updated: 2025-01-23 18:31
VLAI
Summary
Git LFS permits exfiltration of credentials via crafted HTTP URLs
Details

Impact

When Git LFS requests credentials from Git for a remote host, it passes portions of the host's URL to the git-credential(1) command without checking for embedded line-ending control characters, and then sends any credentials it receives back from the Git credential helper to the remote host. By inserting URL-encoded control characters such as line feed (LF) or carriage return (CR) characters into the URL, an attacker may be able to retrieve a user's Git credentials.

Patches

This problem exists in all previous versions and is patched in v3.6.1. All users should upgrade to v3.6.1.

Workarounds

There are no workarounds known at this time.

References

  • https://github.com/git-lfs/git-lfs/security/advisories/GHSA-q6r2-x2cc-vrp7
  • https://nvd.nist.gov/vuln/detail/CVE-2024-53263
  • https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-53263
  • https://github.com/git-lfs/git-lfs/releases/tag/v3.6.1
  • git-lfs/git-lfs@0345b6f816

For more information

If you have any questions or comments about this advisory: * For general questions, start a discussion in the Git LFS discussion forum. * For reports of additional vulnerabilities, please follow the Git LFS security reporting policy.

Severity
8.5 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/git-lfs/git-lfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "last_affected": "3.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.6.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/git-lfs/git-lfs/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-53263"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-74"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-14T21:20:42Z",
    "nvd_published_at": "2025-01-14T20:15:28Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen Git LFS requests credentials from Git for a remote host, it passes portions of the host\u0027s URL to the `git-credential(1)` command without checking for embedded line-ending control characters, and then sends any credentials it receives back from the Git credential helper to the remote host.  By inserting URL-encoded control characters such as line feed (LF) or carriage return (CR) characters into the URL, an attacker may be able to retrieve a user\u0027s Git credentials.\n\n### Patches\n\nThis problem exists in all previous versions and is patched in v3.6.1.  All users should upgrade to v3.6.1.\n\n### Workarounds\n\nThere are no workarounds known at this time.\n\n### References\n\n* https://github.com/git-lfs/git-lfs/security/advisories/GHSA-q6r2-x2cc-vrp7\n* https://nvd.nist.gov/vuln/detail/CVE-2024-53263\n* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-53263\n* https://github.com/git-lfs/git-lfs/releases/tag/v3.6.1\n* [git-lfs/git-lfs@0345b6f816](https://github.com/git-lfs/git-lfs/commit/0345b6f816e611d050c0df67b61f0022916a1c90)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* For general questions, start a discussion in the Git LFS [discussion forum](https://github.com/git-lfs/git-lfs/discussions).\n* For reports of additional vulnerabilities, please follow the Git LFS [security reporting policy](https://github.com/git-lfs/git-lfs/blob/main/SECURITY.md).",
  "id": "GHSA-q6r2-x2cc-vrp7",
  "modified": "2025-01-23T18:31:17Z",
  "published": "2025-01-14T21:20:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/git-lfs/git-lfs/security/advisories/GHSA-q6r2-x2cc-vrp7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53263"
    },
    {
      "type": "WEB",
      "url": "https://github.com/git-lfs/git-lfs/commit/0345b6f816e611d050c0df67b61f0022916a1c90"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/git-lfs/git-lfs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/git-lfs/git-lfs/releases/tag/v3.6.1"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3390"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Git LFS permits exfiltration of credentials via crafted HTTP URLs"
}

GHSA-QC95-4862-92FH

Vulnerability from github – Published: 2026-05-27 20:13 – Updated: 2026-05-27 20:13
VLAI
Summary
Symfony has an HtmlSanitizer allowLinkHosts() / allowMediaHosts() Bypass via URL-Parser Differentials and <area> Misclassification
Details

Description

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.

Show details on source website
To clipboard 

{
  "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:48
VLAI
Summary
Gateway API route matching order contradicts specification
Details

Impact

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.

Severity
4.0 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "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:17
VLAI
Summary
Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing
Details

Summary

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 Forwarded quoted-string values before splitting on parameter delimiters.
  • Avoid trusting client-supplied Forwarded headers unless they are normalized or regenerated by a trusted reverse proxy.
  • Prefer stripping inbound Forwarded headers at the edge and reconstructing them from trusted proxy metadata.
  • 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.
Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "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:39
VLAI
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.

Show details on source website
To clipboard 

{
  "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": []
}

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.

← Back to the CWE list