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.

261 vulnerabilities reference this CWE, most recent first.

GHSA-P634-W6R4-RJP2

Vulnerability from github – Published: 2026-09-29 23:11 – Updated: 2026-09-29 23:11
VLAI
Summary
adm-zip: Duplicate ZIP entry names: getEntry() and extractAllTo() resolve to different content
Details

Summary

A ZIP file can contain two entries with the identical name. adm-zip keeps both in its internal entry list, but its name-lookup table only retains the last one written. getEntry(name) and extractAllTo() walk these two different internal structures, so they can each resolve a duplicate name to a different entry. An application that validates a named entry's contents via getEntry() before trusting an archive, then extracts the whole archive, can end up approving one file's content while a different file's bytes are what actually land on disk under that name.

Details

  • zipFile.js:58-83 retains both entries in entryList but overwrites entryTable[name] with only the last one written.
  • adm-zip.js:83-95,658-663 uses entryTable for getEntry() lookups — returns the last duplicate.
  • adm-zip.js:769-914 iterates entryList for extraction — writes the first duplicate (sync, default overwrite policy).

PoC

const AdmZip = require('adm-zip');
const z = new AdmZip({ noSort: true });
z.addFile('a.txt', Buffer.from('FIRST'));
z.addFile('b.txt', Buffer.from('SECOND'));
const raw = Buffer.from(z.toBuffer());
// rename the a.txt entry to b.txt directly in the raw bytes
for (let at = raw.indexOf('a.txt'); at >= 0; at = raw.indexOf('a.txt', at + 5)) {
  raw.write('b.txt', at);
}
const parsed = new AdmZip(raw, { noSort: true });
const validated = parsed.getEntry('b.txt').getData().toString();
parsed.extractAllTo(outDir, false);
// validated === "SECOND", but the file written to disk === "FIRST"

Reproduced on the pinned commit (2b4d84087d45344643e0183756e19191d52815cc)

Impact

An application that checks a named entry's content before trusting an untrusted ZIP, then extracts it, can be made to approve different bytes than what actually gets written to disk — the classic check/use split that this kind of validate-then-extract pattern relies on.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "adm-zip"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-696"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:11:01Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA ZIP file can contain two entries with the identical name. adm-zip keeps both in its internal entry list, but its name-lookup table only retains the last one written. `getEntry(name)` and `extractAllTo()` walk these two different internal structures, so they can each resolve a duplicate name to a *different* entry. An application that validates a named entry\u0027s contents via `getEntry()` before trusting an archive, then extracts the whole archive, can end up approving one file\u0027s content while a different file\u0027s bytes are what actually land on disk under that name.\n\n### Details\n- `zipFile.js:58-83` retains both entries in `entryList` but overwrites `entryTable[name]` with only the last one written.\n- `adm-zip.js:83-95,658-663` uses `entryTable` for `getEntry()` lookups \u2014 returns the *last* duplicate.\n- `adm-zip.js:769-914` iterates `entryList` for extraction \u2014 writes the *first* duplicate (sync, default overwrite policy).\n\n\n### PoC\n```js\nconst AdmZip = require(\u0027adm-zip\u0027);\nconst z = new AdmZip({ noSort: true });\nz.addFile(\u0027a.txt\u0027, Buffer.from(\u0027FIRST\u0027));\nz.addFile(\u0027b.txt\u0027, Buffer.from(\u0027SECOND\u0027));\nconst raw = Buffer.from(z.toBuffer());\n// rename the a.txt entry to b.txt directly in the raw bytes\nfor (let at = raw.indexOf(\u0027a.txt\u0027); at \u003e= 0; at = raw.indexOf(\u0027a.txt\u0027, at + 5)) {\n  raw.write(\u0027b.txt\u0027, at);\n}\nconst parsed = new AdmZip(raw, { noSort: true });\nconst validated = parsed.getEntry(\u0027b.txt\u0027).getData().toString();\nparsed.extractAllTo(outDir, false);\n// validated === \"SECOND\", but the file written to disk === \"FIRST\"\n```\n\nReproduced on the pinned commit (`2b4d84087d45344643e0183756e19191d52815cc`)\n\n### Impact\nAn application that checks a named entry\u0027s content before trusting an untrusted ZIP, then extracts it, can be made to approve different bytes than what actually gets written to disk \u2014 the classic check/use split that this kind of validate-then-extract pattern relies on.",
  "id": "GHSA-p634-w6r4-rjp2",
  "modified": "2026-09-29T23:11:01Z",
  "published": "2026-09-29T23:11:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/security/advisories/GHSA-p634-w6r4-rjp2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/commit/05101d47b3b983b705cc3e66fc34366118ba7b99"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cthackers/adm-zip"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cthackers/adm-zip/releases/tag/v0.6.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "adm-zip: Duplicate ZIP entry names: getEntry() and extractAllTo() resolve to different content"
}

GHSA-P6X2-6XX4-X843

Vulnerability from github – Published: 2023-06-16 15:30 – Updated: 2024-04-04 04:54
VLAI
Details

There is a misinterpretation of input vulnerability in Huawei Printer. Successful exploitation of this vulnerability may cause the printer service to be abnormal.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-48471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-16T13:15:09Z",
    "severity": "HIGH"
  },
  "details": "There is a misinterpretation of input vulnerability in Huawei Printer. Successful exploitation of this vulnerability may cause the printer service to be abnormal.",
  "id": "GHSA-p6x2-6xx4-x843",
  "modified": "2024-04-04T04:54:57Z",
  "published": "2023-06-16T15:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48471"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/2023/huawei-sa-moivihp-73cabdde-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PC4W-X9P8-64J7

Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2022-02-18 00:00
VLAI
Details

PAN-OS software provides options to exclude specific websites from URL category enforcement and those websites are blocked or allowed (depending on your rules) regardless of their associated URL category. This is done by creating a custom URL category list or by using an external dynamic list (EDL) in a URL Filtering profile. When the entries in these lists have a hostname pattern that does not end with a forward slash (/) or a hostname pattern that ends with an asterisk (), any URL that starts with the specified pattern is considered a match. Entries with a caret (^) at the end of a hostname pattern match any top level domain. This may inadvertently allow or block more URLs than intended and allowing more URLs than intended represents a security risk. For example: example.com will match example.com.website.test example.com. will match example.com.website.test example.com.^ will match example.com.test You should take special care when using such entries in policy rules that allow traffic. Where possible, use the exact list of hostname names ending with a forward slash (/) instead of using wildcards. PAN-OS 10.1 versions earlier than PAN-OS 10.1.3; PAN-OS 10.0 versions earlier than PAN-OS 10.0.8; PAN-OS 9.1 versions earlier than PAN-OS 9.1.12; all PAN-OS 9.0 versions; PAN-OS 8.1 versions earlier than PAN-OS 8.1.21, and Prisma Access 2.2 and 2.1 versions do not allow customers to change this behavior without changing the URL category list or EDL.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-0011"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-10T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "PAN-OS software provides options to exclude specific websites from URL category enforcement and those websites are blocked or allowed (depending on your rules) regardless of their associated URL category. This is done by creating a custom URL category list or by using an external dynamic list (EDL) in a URL Filtering profile. When the entries in these lists have a hostname pattern that does not end with a forward slash (/) or a hostname pattern that ends with an asterisk (*), any URL that starts with the specified pattern is considered a match. Entries with a caret (^) at the end of a hostname pattern match any top level domain. This may inadvertently allow or block more URLs than intended and allowing more URLs than intended represents a security risk. For example: example.com will match example.com.website.test example.com.* will match example.com.website.test example.com.^ will match example.com.test You should take special care when using such entries in policy rules that allow traffic. Where possible, use the exact list of hostname names ending with a forward slash (/) instead of using wildcards. PAN-OS 10.1 versions earlier than PAN-OS 10.1.3; PAN-OS 10.0 versions earlier than PAN-OS 10.0.8; PAN-OS 9.1 versions earlier than PAN-OS 9.1.12; all PAN-OS 9.0 versions; PAN-OS 8.1 versions earlier than PAN-OS 8.1.21, and Prisma Access 2.2 and 2.1 versions do not allow customers to change this behavior without changing the URL category list or EDL.",
  "id": "GHSA-pc4w-x9p8-64j7",
  "modified": "2022-02-18T00:00:57Z",
  "published": "2022-02-11T00:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0011"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2022-0011"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

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"
}

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