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 …
Authorization Bypass Through User-Controlled Key in NPM url-parse prior to 1.5.8.
A specially crafted URL with an '@' sign but empty user info and no hostname, when parsed with url-parse, url-parse will return the incorrect href. In particular, parse("http://@/127.0.0.1") Will return: { slashes: true, protocol: 'http:', hash: '', query: '', pathname: '/127.0.0.1', auth: '', host: '', port: '', hostname: '', password: '', username: '', origin: 'null', href: 'http:///127.0.0.1' } If the 'hostname' or 'origin' attributes of the output from url-parse are …
An authorization bypass through a user-controlled key was found in url-parse.
Insufficient validation and sanitization of user input exists in url-parse npm package version 1.4.4 and earlier may allow attacker to bypass security checks.
Depending on library usage and attacker intent, impacts may include allow/block list bypasses, SSRF attacks, open redirects, or other undesired behavior.
url-parse before 1.5.0 mishandles certain uses of backslash such as http:/ and interprets the URI as a relative path.
Versions of url-parse before 1.4.3 returns the wrong hostname which could lead to Open Redirect, Server Side Request Forgery (SSRF), or Bypass Authentication Protocol vulnerabilities.