{"id":"CVE-2022-35949","aliases":["CLSA-2026-1788560495","DEBIAN-CVE-2022-35949","EUVD-2022-6518","GHSA-8qr4-xgw6-wmr3","SUSE-SU-2022:3196-1","SUSE-SU-2022:3250-1","SUSE-SU-2022:3251-1","openSUSE-SU-2024:12285-1"],"status":"published","title":"`undici.request` vulnerable to SSRF using absolute URL on `pathname`","description":"undici is an HTTP/1.1 client, written from scratch for Node.js.`undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`. If a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1` ```js const undici = require(\"undici\") undici.request({origin: \"http://example.com\", pathname: \"//127.0.0.1\"}) ``` Instead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`. If a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL. This issue was fixed in `undici@5.8.1`. The best workaround is to validate user input before passing it to the `undici.request` call.","severity":{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.01927,"percentile":0.80112,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-918"],"published":"2022-08-12T00:00:00Z","modified":"2026-11-03T06:02:55Z","fixes":[{"ecosystem":"npm","package":"undici","fixed_in":["5.8.2"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:12","package":"node-undici","fixed_in":["5.8.2+dfsg1+~cs18.9.18.1-1"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"node-undici","fixed_in":["5.8.2+dfsg1+~cs18.9.18.1-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"node-undici","fixed_in":["5.8.2+dfsg1+~cs18.9.18.1-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"5.8.1"},{"fixed":"5.8.2"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.5.1-tuxcare.0"},{"fixed":"5.5.1-tuxcare.1"}]}],"versions":["5.5.1"],"bundled":14},{"source":"osv","ecosystem":"Debian:12","package":"node-undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.8.2+dfsg1+~cs18.9.18.1-1"}]}]},{"source":"osv","ecosystem":"Debian:13","package":"node-undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.8.2+dfsg1+~cs18.9.18.1-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"node-undici","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.8.2+dfsg1+~cs18.9.18.1-1"}]}]},{"source":"osv","ecosystem":"npm","package":"undici","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"5.8.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Web and Scripting 12","package":"nodejs16","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"16.17.0-8.9.1"}]}],"bundled":4},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Web and Scripting 15 SP4","package":"nodejs16","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"16.17.0-150400.3.6.1"}]}],"bundled":4},{"source":"osv","ecosystem":"openSUSE:Leap 15.4","package":"nodejs16","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"16.17.0-150400.3.6.1"}]}],"bundled":4},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Web and Scripting 15 SP3","package":"nodejs16","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"16.17.0-150300.7.9.1"}]}],"bundled":4},{"source":"osv","ecosystem":"openSUSE:Leap 15.3","package":"nodejs16","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"16.17.0-150300.7.9.1"}]}],"bundled":4},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"nodejs16","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"16.17.0-2.1"}]}],"bundled":2}],"products":[{"vendor":"nodejs","product":"undici"},{"vendor":"undici","product":"undici"}],"references":[{"url":"https://github.com/nodejs/undici/security/advisories/GHSA-8qr4-xgw6-wmr3","tags":["x_transferred","Exploit","Mitigation","Third Party Advisory","advisory","web"]},{"url":"https://github.com/nodejs/undici/commit/124f7ebf705366b2e1844dff721928d270f87895","tags":["x_transferred","Patch","Third Party Advisory","fix","web"]},{"url":"https://github.com/nodejs/undici/releases/tag/v5.8.2","tags":["x_transferred","Release Notes","Third Party Advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-35949","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-8qr4-xgw6-wmr3"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/35xxx/CVE-2022-35949.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2022-35949","tags":["advisory"]},{"url":"https://github.com/nodejs/undici","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2022/suse-su-20223196-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1200303","tags":["report"]},{"url":"https://bugzilla.suse.com/1200517","tags":["report"]},{"url":"https://bugzilla.suse.com/1201710","tags":["report"]},{"url":"https://bugzilla.suse.com/1202382","tags":["report"]},{"url":"https://bugzilla.suse.com/1202383","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2022-29244","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2022-31150","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2022-35948","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2022-35949","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2022/suse-su-20223250-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2022/suse-su-20223251-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2022-35949","title":"`undici.request` vulnerable to SSRF using absolute URL on `pathname`","description":"undici is an HTTP/1.1 client, written from scratch for Node.js.`undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`. If a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1` ```js const undici = require(\"undici\") undici.request({origin: \"http://example.com\", pathname: \"//127.0.0.1\"}) ``` Instead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`. If a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL. This issue was fixed in `undici@5.8.1`. The best workaround is to validate user input before passing it to the `undici.request` call.","status":"published","published":"2022-08-12T00:00:00Z","modified":"2025-04-22T17:42:40.255Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:34:40.275153Z"}],"euvd":[{"id":"EUVD-2022-6518","description":"undici is an HTTP/1.1 client, written from scratch for Node.js.`undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`. If a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1` ```js const undici = require(\"undici\") undici.request({origin: \"http://example.com\", pathname: \"//127.0.0.1\"}) ``` Instead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`. If a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL. This issue was fixed in `undici@5.8.1`. The best workaround is to validate user input before passing it to the `undici.request` call.","status":"published","published":"2022-08-12T00:00:00Z","modified":"2025-04-22T17:42:40Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"medium"}],"updated_at":"2026-11-02T20:52:15.540112Z"}],"ghsa":[{"id":"GHSA-8qr4-xgw6-wmr3","title":"`undici.request` vulnerable to SSRF using absolute URL on `pathname`","description":"### Impact\n\n`undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`.\n\nIf a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1`\n\n```js\nconst undici = require(\"undici\")\nundici.request({origin: \"http://example.com\", pathname: \"//127.0.0.1\"})\n```\n\nInstead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`.\n\nIf a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL.\n\n### Patches\n\nThis issue was fixed in `undici@5.8.1`.\n\n### Workarounds\n\nThe best workaround is to validate user input before passing it to the `undici.request` call.\n\n## For more information\nIf you have any questions or comments about this advisory:\n\n- Open an issue in [undici repository](https://github.com/nodejs/undici/issues)\n- To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document\n","status":"published","published":"2022-08-18T18:59:46Z","modified":"2023-02-03T05:04:20Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"medium"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:36:41.967989Z"}],"nvd":[{"id":"CVE-2022-35949","description":"undici is an HTTP/1.1 client, written from scratch for Node.js.`undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`. If a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1` ```js const undici = require(\"undici\") undici.request({origin: \"http://example.com\", pathname: \"//127.0.0.1\"}) ``` Instead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`. If a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL. This issue was fixed in `undici@5.8.1`. The best workaround is to validate user input before passing it to the `undici.request` call.","status":"published","published":"2022-08-12T23:15:07.97Z","modified":"2026-06-17T04:52:35.147Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"medium","assessor":"secondary"},{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"primary"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:07:24.750124Z"}],"osv":[{"id":"CVE-2022-35949","title":"`undici.request` vulnerable to SSRF using absolute URL on `pathname`","description":"undici is an HTTP/1.1 client, written from scratch for Node.js.`undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`. If a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1` ```js const undici = require(\"undici\") undici.request({origin: \"http://example.com\", pathname: \"//127.0.0.1\"}) ``` Instead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`. If a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL. This issue was fixed in `undici@5.8.1`. The best workaround is to validate user input before passing it to the `undici.request` call.","status":"published","published":"2022-08-12T00:00:00Z","modified":"2026-10-28T02:31:03.879380223Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"medium"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T15:44:26.195407Z"},{"id":"GHSA-8qr4-xgw6-wmr3","title":"`undici.request` vulnerable to SSRF using absolute URL on `pathname`","description":"### Impact\n\n`undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`.\n\nIf a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1`\n\n```js\nconst undici = require(\"undici\")\nundici.request({origin: \"http://example.com\", pathname: \"//127.0.0.1\"})\n```\n\nInstead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`.\n\nIf a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL.\n\n### Patches\n\nThis issue was fixed in `undici@5.8.1`.\n\n### Workarounds\n\nThe best workaround is to validate user input before passing it to the `undici.request` call.\n\n## For more information\nIf you have any questions or comments about this advisory:\n\n- Open an issue in [undici repository](https://github.com/nodejs/undici/issues)\n- To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document\n","status":"published","published":"2022-08-18T18:59:46Z","modified":"2023-11-08T04:09:53.898548Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"medium"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T15:46:42.78452Z"},{"id":"CLSA-2026-1788560495","title":"TuxCare security update for undici (14 CVEs)","description":"TuxCare rebuilt undici to address 14 CVEs. Fixed in 5.5.1-tuxcare.1.","status":"published","published":"2026-09-04T22:21:35Z","modified":"2026-10-15T09:48:03.135244229Z","updated_at":"2026-11-02T15:43:47.591214Z"},{"id":"DEBIAN-CVE-2022-35949","description":"undici is an HTTP/1.1 client, written from scratch for Node.js.`undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`. If a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1` ```js const undici = require(\"undici\") undici.request({origin: \"http://example.com\", pathname: \"//127.0.0.1\"}) ``` Instead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`. If a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL. This issue was fixed in `undici@5.8.1`. The best workaround is to validate user input before passing it to the `undici.request` call.","status":"published","published":"2022-08-12T23:15:07.97Z","modified":"2026-11-03T06:02:55.99980021Z","updated_at":"2026-11-03T06:43:19.563245Z"},{"id":"openSUSE-SU-2024:12285-1","title":"corepack16-16.17.0-2.1 on GA media","description":"These are all security issues fixed in the corepack16-16.17.0-2.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-06-15T00:00:00Z","modified":"2026-02-04T03:07:32.465356Z","updated_at":"2026-11-02T16:58:35.485255Z"},{"id":"SUSE-SU-2022:3196-1","title":"Security update for nodejs16","description":"This update for nodejs16 fixes the following issues:\n\n- CVE-2022-35949: Fixed SSRF when an application takes in user input into the path/pathname option of undici.request (bsc#1202382).\n- CVE-2022-35948: Fixed CRLF injection via Content-Type (bsc#1202383).\n- CVE-2022-29244: Fixed npm pack ignores root-level .gitignore and .npmignore file exclusion directives when run in a workspace (bsc#1200517).\n- CVE-2022-31150: Fixed CRLF injection in node-undici (bsc#1201710).\n\nBugfixes:\n\n- Enable crypto-policies for SLE15 SP4+ and TW (bsc#1200303)\n","status":"published","published":"2022-09-08T08:35:42Z","modified":"2026-02-04T04:06:40.438354Z","updated_at":"2026-11-02T15:53:50.965375Z"},{"id":"SUSE-SU-2022:3250-1","title":"Security update for nodejs16","description":"This update for nodejs16 fixes the following issues:\n\n- CVE-2022-35949: Fixed SSRF when an application takes in user input into the path/pathname option of undici.request (bsc#1202382).\n- CVE-2022-35948: Fixed CRLF injection via Content-Type (bsc#1202383).\n- CVE-2022-29244: Fixed npm pack ignores root-level .gitignore and .npmignore file exclusion directives when run in a workspace (bsc#1200517).\n- CVE-2022-31150: Fixed CRLF injection in node-undici (bsc#1201710).\n\nBugfixes:\n\n- Enable crypto-policies for SLE15 SP4+ and TW (bsc#1200303)\n","status":"published","published":"2022-09-12T07:06:54Z","modified":"2026-02-04T04:01:38.008685Z","updated_at":"2026-11-02T15:53:50.965375Z"},{"id":"SUSE-SU-2022:3251-1","title":"Security update for nodejs16","description":"This update for nodejs16 fixes the following issues:\n\n- CVE-2022-35949: Fixed SSRF when an application takes in user input into the path/pathname option of undici.request (bsc#1202382).\n- CVE-2022-35948: Fixed CRLF injection via Content-Type (bsc#1202383).\n- CVE-2022-29244: Fixed npm pack ignores root-level .gitignore and .npmignore file exclusion directives when run in a workspace (bsc#1200517).\n- CVE-2022-31150: Fixed CRLF injection in node-undici (bsc#1201710).\n\nBugfixes:\n\n- Enable crypto-policies for SLE15 SP4+ and TW (bsc#1200303)\n","status":"published","published":"2022-09-12T07:07:06Z","modified":"2026-02-04T04:04:13.518338Z","updated_at":"2026-11-02T15:53:50.965375Z"}]}}