url-parse incorrectly parses hostname / protocol due to unstripped leading control characters.
Leading control characters in a URL are not stripped when passed into url-parse. This can cause input URLs to be mistakenly be interpreted as a relative URL without a hostname and protocol, while the WHATWG URL parser will trim control characters and treat it as an absolute URL. If url-parse is used in security decisions involving the hostname / protocol, and the input URL is used in a client which uses the WHATWG URL parser, the decision may be incorrect. This can also lead to a cross-site scripting (XSS) vulnerability if url-parse is used to check for the javascript: protocol in URLs. See following example: ```js const parse = require('url-parse') const express = require('express') const app = express() const port = 3000 url = parse(\"\\bjavascript:alert(1)\") console.log(url) app.get('/', (req, res) => { if (url.protocol !== \"javascript:\") {res.send(\"<a href=\\'\" + url.href + \"\\'>CLICK ME!</a>\")} }) app.listen(port, () => { console.log(`Example app listening on port ${port}`) }) ```
describes (1)
Related CVEs.
| ID | severity | exploitable | ||
|---|---|---|---|---|
| CVE-2022-0691US | critical9.8 | — | ||
Authorization Bypass Through User-Controlled Key in NPM url-parse prior to 1.5.9. | ||||
references
External citations — patches, advisories, analysis.
- https://github.com/github/advisory-database/pull/6765WEB
- https://github.com/unshiftio/url-parsePACKAGE
- https://github.com/unshiftio/url-parse/commit/0e3fb542d60ddbf6933f22eb9b1e06e25eaa5b63WEB
- https://huntr.dev/bounties/57124ed5-4b68-4934-8325-2c546257f2e4WEB
- https://lists.debian.org/debian-lts-announce/2023/02/msg00030.htmlWEB
- https://nvd.nist.gov/vuln/detail/CVE-2022-0691ADVISORY
- https://security.netapp.com/advisory/ntap-20220325-0006WEB
Advisories like this name the exposed products attackers go after on your perimeter. See what is exposed on your perimeter with a free passive scan.
Free scan