[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.

[advisory-database]

Hi @ljharb! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!