GHSA-jqcg-44mw-7w3h: Critical severity npm/proxy-addr vulnerability
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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/proxy-addrto a version that resolves this vulnerability.Fixed in 2.0.8 - Upgrade
Upgrade
proxy-addrto a version that resolves this vulnerability.Fixed in 2.0.8 - Configuration
Write IPv4 trust subnets in plain IPv4 notation, such as 10.0.0.0/8. If IPv4-mapped IPv6 notation is required, use a full prefix that covers the mapped marker, such as ::ffff:10.0.0.0/104 instead of ::ffff:10.0.0.0/8.
proxy-addr IPv4 trust subnet notation = Plain IPv4 notation, or full IPv4-mapped IPv6 prefix
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments are exposed when they configure proxy-addr with an IPv4-mapped IPv6 trust subnet using a short prefix, such as ::ffff:10.0.0.0/8, or an IPv6 trust subnet with zero leading bits such as ::/1. Applications using Express are affected through req.ip and req.ips when they rely on this trust configuration.
What does an attacker need to exploit it?
An attacker only needs to send a request with a chosen X-Forwarded-For header. Because the faulty trust rule treats every IPv4 client as a trusted proxy at hop 0, the application can accept the attacker-supplied address.
What security controls can be bypassed?
Any control that relies on the derived client IP can be undermined, including IP-based access control, rate limiting, geolocation, and audit logging. The attacker can cause the application to use an arbitrary X-Forwarded-For value as the client address.
What can be done if upgrading is not immediately possible?
Write IPv4 trust subnets in plain IPv4 notation, such as 10.0.0.0/8, rather than as IPv4-mapped IPv6 ranges. Upgrade to proxy-addr 2.0.8 when possible.