proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet

Why it is Amber

• CVSS 9.1 critical
• Remotely exploitable without logging in
• On your watchlist: npm

Affected packages

References

• https://github.com/advisories/GHSA-jqcg-44mw-7w3h
• https://github.com/jshttp/proxy-addr/security/advisories/GHSA-jqcg-44mw-7w3h
• https://nvd.nist.gov/vuln/detail/CVE-2026-90711
• https://github.com/jshttp/proxy-addr/commit/780911d84d18e2c5fa008ed0c0d387631ec11965
• https://cna.openjsf.org/security-advisories.html
• https://github.com/jshttp/proxy-addr/releases/tag/v2.0.8
• https://github.com/advisories/GHSA-jqcg-44mw-7w3h

Original description

### Impact `proxy-addr` determines which network hops are trusted proxies so that `X-Forwarded-For` can be believed. When an application configures a trust subnet as an IPv4-mapped IPv6 address with a short prefix, such as `::ffff:10.0.0.0/8` (the correct spelling is `::ffff:10.0.0.0/104`), the subnet compiles with all-zero leading bits and matches every IPv4 address instead of the block it names. The same happens for any IPv6 trust subnet with zero leading bits, such as `::/1`. Every unauthenticated client is then trusted as a proxy at hop 0, so `proxyaddr(req, trust)`, and therefore `req.ip` and `req.ips` in Express, returns whatever the client sends in `X-Forwarded-For`. This defeats IP-based access control, rate limiting, geolocation, and audit logging. The misconfiguration compiles without any error, and the same block written correctly behaves correctly, so the difference is not visible from the configuration. ### Patches Upgrade to `proxy-addr` 2.0.8. An IPv4 address now matches an IPv6 trust subnet only when that subnet is a genuine IPv4-mapped subnet whose prefix covers the mapped marker. ### Workarounds Write IPv4 trust subnets in plain IPv4 notation (for example `10.0.0.0/8`). If IPv4-mapped IPv6 notation is required, use the full form so the prefix covers the mapped marker (for example `::ffff:10.0.0.0/104` for the `10.0.0.0/8` block).