[GHSA-8v38-pw62-9cw2] url-parse Incorrectly parses URLs that include an '@'

[ljharb]

Updates

• Affected products

Comments
In v1.x, the @ is correctly identified as an auth separator, but when auth is empty, the toString() method has no way to know there was an @ in the original URL. The fix adds a check: if there's no host but there is a pathname (and it's a special protocol), re-add the @ to preserve the original invalid URL structure.

In v0.x, the regex-based approach doesn't cleanly separate empty auth - it ends up treating @ as part of the hostname, which accidentally preserves it in the output.

In v0.x, the final href is: http://@/127.0.0.1 The @ is preserved, which is the correct/safe behavior. This matches the original input.

In contrast, v1.x (vulnerable) outputs: http:///127.0.0.1. The @ is lost, which is the security issue - if code checks hostname (empty) to allow the request, then uses href to make the request, the /127.0.0.1 in the pathname could be misinterpreted by some HTTP clients as a host, leading to SSRF.

[Copilot]

Pull request overview

This PR corrects a security advisory for the url-parse package to accurately reflect which versions are affected by CVE-2022-0639. The vulnerability only affects v1.x of the package, not v0.x, as v0.x uses a regex-based approach that correctly preserves the '@' character in malformed URLs.

Changes:

• Updated the introduced version from "0" to "1.0.0" to correctly indicate that only v1.x is vulnerable
• Updated the modified timestamp to reflect the change

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[helixplant]

Hi @ljharb,
We are currently looking into this and should have an answer for you soon.