{"id":"CVE-2026-109841","aliases":["CLSA-2026-1793099993","CLSA-2026-1793809357","CLSA-2026-1793809399","CLSA-2026-1793973403","CLSA-2026-1794310630","DEBIAN-CVE-2026-109841","EUVD-2026-102305","GHSA-f72v-6w45-q472","RHSA-2026:84657","RHSA-2026:84706","UBUNTU-CVE-2026-109841"],"status":"published","title":"undici vulnerable to Subresource Integrity bypass via non-lowercase algorithm tokens","description":"undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata.","severity":{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00252,"percentile":0.16785,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-178"],"published":"2026-10-15T18:22:06Z","modified":"2026-11-10T13:15:07Z","fixes":[{"ecosystem":"npm","package":"undici","fixed_in":["7.30.1","8.12.2"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:14","package":"node-undici","fixed_in":["8.12.2+dfsg+~cs3.2.3-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"7.15.0"},{"fixed":"7.30.1"}]}]},{"source":"ghsa","ecosystem":"npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"8.0.0"},{"fixed":"8.12.2"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"7.24.4-tuxcare.0"},{"fixed":"7.24.4-tuxcare.4"}]}],"versions":["7.24.4","7.24.4-tuxcare.1","7.24.4-tuxcare.2","7.24.4-tuxcare.3"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"7.28.0-tuxcare.0"},{"fixed":"7.28.0-tuxcare.9"}]}],"versions":["7.28.0","7.28.0-tuxcare.1","7.28.0-tuxcare.2","7.28.0-tuxcare.3","7.28.0-tuxcare.4","7.28.0-tuxcare.5","7.28.0-tuxcare.6","7.28.0-tuxcare.7","7.28.0-tuxcare.8"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"7.29.0-tuxcare.0"},{"fixed":"7.29.0-tuxcare.8"}]}],"versions":["7.29.0","7.29.0-tuxcare.1","7.29.0-tuxcare.2","7.29.0-tuxcare.3","7.29.0-tuxcare.4","7.29.0-tuxcare.5","7.29.0-tuxcare.6","7.29.0-tuxcare.7"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"7.29.1-tuxcare.0"},{"fixed":"7.29.1-tuxcare.1"}]}],"versions":["7.29.1"],"bundled":7},{"source":"osv","ecosystem":"TuxCare:npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"7.24.8-tuxcare.0"},{"fixed":"7.24.8-tuxcare.1"}]}],"versions":["7.24.8"],"bundled":14},{"source":"osv","ecosystem":"Debian:14","package":"node-undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"8.12.2+dfsg+~cs3.2.3-1"}]}],"versions":["7.15.0+dfsg+~cs3.2.0-1","7.15.0+dfsg+~cs3.2.0-3","7.16.0+dfsg+~cs3.2.0-1","7.16.0+dfsg+~cs3.2.0-2","7.18.2+dfsg+~cs3.2.0-1","7.24.5+dfsg+~cs3.2.0-1","7.24.6+dfsg+~cs3.2.0-1","7.24.6+dfsg+~cs3.2.0-2","7.24.6+dfsg+~cs3.2.0-3","7.3.0+dfsg1+~cs24.12.11-1","7.3.0+dfsg1+~cs24.12.11-2","8.10.2+dfsg+~cs3.2.2-1","8.12.1+dfsg+~cs3.2.3-1","8.5.0+dfsg+~cs3.2.0-1","8.5.0+dfsg+~cs3.2.0-2","8.5.0+dfsg+~cs3.2.0-3","8.9.0+dfsg+~cs3.2.0-1"]},{"source":"osv","ecosystem":"npm","package":"undici","ranges":[{"type":"SEMVER","events":[{"introduced":"7.15.0"},{"fixed":"7.30.1"}]}]},{"source":"osv","ecosystem":"npm","package":"undici","ranges":[{"type":"SEMVER","events":[{"introduced":"8.0.0"},{"fixed":"8.12.2"}]}]},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs26","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:26.11.1-0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs26-bin","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:26.11.1-0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs26-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:26.11.1-0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs26-docs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:26.11.1-0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs26-full-i18n","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:26.11.1-0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs26-libs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:26.11.1-0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs26-npm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:11.20.0-1.26.11.1.0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs26-npm-bin","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:26.11.1-0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"v8-14.6-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:14.6.202.34-1.26.11.1.0.4.hum1"}]}],"bundled":9},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs24","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:24.21.0-1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs24-bin","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:24.21.0-1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs24-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:24.21.0-1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs24-docs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:24.21.0-1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs24-full-i18n","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:24.21.0-1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs24-libs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:24.21.0-1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs24-npm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:11.19.0-1.24.21.0.1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"nodejs24-npm-bin","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:24.21.0-1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"v8-13.6-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:13.6.233.17-1.24.21.0.1.5.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"node-undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.22.1+dfsg1+~cs20.10.10.2-1ubuntu1","5.26.3+dfsg1+~cs23.10.12-2"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"node-undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["7.18.2+dfsg+~cs3.2.0-1build1","7.24.6+dfsg+~cs3.2.0-3","8.5.0+dfsg+~cs3.2.0-2","8.5.0+dfsg+~cs3.2.0-3","8.9.0+dfsg+~cs3.2.0-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"node-undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["7.3.0+dfsg1+~cs24.12.11-2","7.16.0+dfsg+~cs3.2.0-2","7.18.2+dfsg+~cs3.2.0-1","7.18.2+dfsg+~cs3.2.0-1build1"]}],"products":[{"vendor":"nodejs","product":"undici"},{"vendor":"undici","product":"undici"}],"references":[{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-f72v-6w45-q472","tags":["Mitigation","Vendor Advisory","advisory","web","article","report"]},{"url":"https://cna.openjsf.org/security-advisories.html","tags":["Vendor Advisory","advisory","web","article","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-109841","tags":["advisory"]},{"url":"https://github.com/nodejs/undici/commit/18bc8a1e09d15bc45815154a289dcf6fd5254d00","tags":["web"]},{"url":"https://github.com/nodejs/undici/commit/4f7ef6806e532ab9e29ccd6229b1b9d241e1b1f0","tags":["web"]},{"url":"https://github.com/nodejs/undici/releases/tag/v7.30.1","tags":["web"]},{"url":"https://github.com/nodejs/undici/releases/tag/v8.12.2","tags":["web"]},{"url":"https://github.com/advisories/GHSA-f72v-6w45-q472"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/109xxx/CVE-2026-109841.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-109841","tags":["advisory"]},{"url":"https://github.com/nodejs/undici","tags":["package"]},{"url":"https://access.redhat.com/errata/RHSA-2026:84657","tags":["advisory"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-102276","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-109383","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-109829","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-109841","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-109869","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-109924","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-109932","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-87018","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-87029","tags":["report"]},{"url":"https://access.redhat.com/security/updates/classification/","tags":["article"]},{"url":"https://images.redhat.com/","tags":["article"]},{"url":"https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_84657.json","tags":["advisory"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2553677","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-87018","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-87018","tags":["advisory"]},{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-qrxm-fqhp-jwvm","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2553726","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-87029","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-87029","tags":["advisory"]},{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-55wc-3pg8-jfw6","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2542707","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-102276","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-102276","tags":["advisory"]},{"url":"https://github.com/juliangruber/brace-expansion/commit/0bcbfc0a5928c3073d48f42999d1ce4fc1c42fbc","tags":["article"]},{"url":"https://github.com/juliangruber/brace-expansion/commit/316359e6019c39b3254c8ba8e25dc586a480652c","tags":["article"]},{"url":"https://github.com/juliangruber/brace-expansion/commit/5171e681c0922b7ae8bfaf9a331e309107be6edc","tags":["article"]},{"url":"https://github.com/juliangruber/brace-expansion/commit/6735c94873ca570bcdd6a0690033bdd3126379d3","tags":["article"]},{"url":"https://github.com/juliangruber/brace-expansion/security/advisories/GHSA-6j4f-fj2g-mc7p","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2553678","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-109383","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-109383","tags":["advisory"]},{"url":"https://github.com/nodejs/undici/commit/f75eac00ac17","tags":["article"]},{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-2m5v-pch6-74hx","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2553679","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-109829","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-109829","tags":["advisory"]},{"url":"https://github.com/nodejs/undici/commit/26c2bfb3def0","tags":["article"]},{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-4w7w-5xrc-9h26","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2553669","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-109841","tags":["advisory","report"]},{"url":"https://github.com/nodejs/undici/commit/4f7ef6806e53","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2553656","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-109869","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-109869","tags":["advisory"]},{"url":"https://github.com/nodejs/undici/commit/b5084c7dc239","tags":["article"]},{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-xjj6-f33q-929c","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2553663","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-109924","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-109924","tags":["advisory"]},{"url":"https://github.com/nodejs/undici/commit/789ef26461c","tags":["article"]},{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-4qv8-2p9j-2685","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2553687","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-109932","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-109932","tags":["advisory"]},{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-9fm3-97px-rjf6","tags":["article"]},{"url":"https://access.redhat.com/errata/RHSA-2026:84706","tags":["advisory"]},{"url":"https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_84706.json","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-109841","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-109841","title":"undici vulnerable to Subresource Integrity bypass via non-lowercase algorithm tokens","description":"undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata.","status":"published","published":"2026-10-15T18:22:06.283Z","modified":"2026-10-16T20:04:41.388Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-178"],"updated_at":"2026-11-02T14:20:11.581788Z"}],"euvd":[{"id":"EUVD-2026-102305","description":"undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata.","status":"published","published":"2026-10-15T18:22:06Z","modified":"2026-10-16T20:04:41Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T17:00:01.858348Z"}],"ghsa":[{"id":"GHSA-f72v-6w45-q472","title":"undici vulnerable to Subresource Integrity bypass via non-lowercase algorithm tokens","description":"### Impact\n\nundici's `fetch()` verifies Subresource Integrity (SRI) metadata by looking up the algorithm token in a lowercase-only set, but the SRI specification defines a valid token by its ASCII-lowercase form. A correct but non-lowercase token such as `SHA256-...` or `Sha256-...` is therefore treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server that returns a body different from the pinned digest passes the check.\n\nAn application that pins a response with a valid uppercase or mixed-case SRI token receives attacker-controlled bytes with no integrity error. The attacker needs only to control the response body, not the application's integrity metadata. The issue affects response integrity only. The regression was introduced in undici 7.15.0; releases 7.14.0 and earlier lowercase the token and are not affected.\n\n### Patches\n\nUpgrade to `7.30.1` or `8.12.2`. undici now normalizes the algorithm token to ASCII lowercase before validating it and before selecting the strongest algorithm, so case variants of SHA-256, SHA-384, and SHA-512 are verified correctly.\n\n### Workarounds\n\nUse lowercase algorithm tokens (`sha256`, `sha384`, `sha512`) in `integrity` metadata.","status":"published","published":"2026-10-23T22:12:57Z","modified":"2026-10-23T22:13:18Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"cwes":["CWE-178"],"updated_at":"2026-11-02T14:41:35.723785Z"}],"nvd":[{"id":"CVE-2026-109841","description":"undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata.","status":"published","published":"2026-10-15T19:17:21.64Z","modified":"2026-10-19T20:45:30.84Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high","assessor":"primary"}],"cwes":["CWE-178"],"updated_at":"2026-11-02T14:12:59.751798Z"}],"osv":[{"id":"CVE-2026-109841","title":"undici vulnerable to Subresource Integrity bypass via non-lowercase algorithm tokens","description":"undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata.","status":"published","published":"2026-10-15T18:22:06.283Z","modified":"2026-10-28T02:30:26.474385165Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"cwes":["CWE-178"],"updated_at":"2026-11-02T15:44:55.61515Z"},{"id":"DEBIAN-CVE-2026-109841","description":"undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata.","status":"published","published":"2026-10-15T19:17:21.64Z","modified":"2026-11-01T05:00:06.040848821Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:45:49.381767Z"},{"id":"GHSA-f72v-6w45-q472","title":"undici vulnerable to Subresource Integrity bypass via non-lowercase algorithm tokens","description":"### Impact\n\nundici's `fetch()` verifies Subresource Integrity (SRI) metadata by looking up the algorithm token in a lowercase-only set, but the SRI specification defines a valid token by its ASCII-lowercase form. A correct but non-lowercase token such as `SHA256-...` or `Sha256-...` is therefore treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server that returns a body different from the pinned digest passes the check.\n\nAn application that pins a response with a valid uppercase or mixed-case SRI token receives attacker-controlled bytes with no integrity error. The attacker needs only to control the response body, not the application's integrity metadata. The issue affects response integrity only. The regression was introduced in undici 7.15.0; releases 7.14.0 and earlier lowercase the token and are not affected.\n\n### Patches\n\nUpgrade to `7.30.1` or `8.12.2`. undici now normalizes the algorithm token to ASCII lowercase before validating it and before selecting the strongest algorithm, so case variants of SHA-256, SHA-384, and SHA-512 are verified correctly.\n\n### Workarounds\n\nUse lowercase algorithm tokens (`sha256`, `sha384`, `sha512`) in `integrity` metadata.","status":"published","published":"2026-10-23T22:12:57Z","modified":"2026-10-23T22:30:04.094314933Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"cwes":["CWE-178"],"updated_at":"2026-11-02T15:46:46.006631Z"},{"id":"RHSA-2026:84657","title":"Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update","status":"published","published":"2026-10-20T10:17:41Z","modified":"2026-10-20T10:43:33.48989051Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:23.547034Z"},{"id":"RHSA-2026:84706","title":"Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update","status":"published","published":"2026-10-20T10:17:45Z","modified":"2026-10-20T10:43:36.699091514Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:23.547034Z"},{"id":"UBUNTU-CVE-2026-109841","description":"undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata.","status":"published","published":"2026-10-15T19:17:00Z","modified":"2026-10-28T17:50:33Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T16:55:59.591851Z"},{"id":"CLSA-2026-1793099993","title":"TuxCare security update for undici (3 CVEs)","description":"TuxCare rebuilt undici to address 3 CVEs. Fixed in 7.24.4-tuxcare.4.","status":"published","published":"2026-10-27T11:19:53Z","modified":"2026-10-27T13:30:08.305551151Z","updated_at":"2026-11-02T15:43:55.34846Z"},{"id":"CLSA-2026-1793809357","title":"TuxCare security update for undici (3 CVEs)","description":"TuxCare rebuilt undici to address 3 CVEs. Fixed in 7.28.0-tuxcare.9.","status":"published","published":"2026-11-04T17:22:38Z","modified":"2026-11-04T19:00:35.346388915Z","updated_at":"2026-11-04T19:15:03.6858Z"},{"id":"CLSA-2026-1793809399","title":"TuxCare security update for undici (3 CVEs)","description":"TuxCare rebuilt undici to address 3 CVEs. Fixed in 7.29.0-tuxcare.8.","status":"published","published":"2026-11-04T17:23:20Z","modified":"2026-11-04T19:00:35.350027838Z","updated_at":"2026-11-04T19:15:03.6858Z"},{"id":"CLSA-2026-1793973403","title":"TuxCare security update for undici (7 CVEs)","description":"TuxCare rebuilt undici to address 7 CVEs. Fixed in 7.29.1-tuxcare.1.","status":"published","published":"2026-11-06T14:56:44Z","modified":"2026-11-06T19:00:03.416565041Z","updated_at":"2026-11-06T19:05:31.753133Z"},{"id":"CLSA-2026-1794310630","title":"TuxCare security update for undici (14 CVEs)","description":"TuxCare rebuilt undici to address 14 CVEs. Fixed in 7.24.8-tuxcare.1.","status":"published","published":"2026-11-10T12:37:11Z","modified":"2026-11-10T13:15:07.241296257Z","updated_at":"2026-11-10T13:29:51.103746Z"}]}}