← Blog · · df00tech

proxy-addr IP Spoofing Flaw Lets Attackers Bypass X-Forwarded-For Trust Checks (CVE-2026-90711)

breaking ghsa npm CVE-2026-90711

What happened

A GitHub Security Advisory (GHSA-jqcg-44mw-7w3h) published October 5, 2026 discloses a critical flaw in proxy-addr, the npm package that Express and many other Node.js frameworks use to decide which upstream hops are trusted proxies before honoring X-Forwarded-For. Per the advisory, when a trust subnet is written as an IPv4-mapped IPv6 address with a short prefix — the example given is ::ffff:10.0.0.0/8, where the correct prefix is /104 — the configuration compiles with all-zero leading bits and ends up matching every IPv4 address, not just the intended block. The advisory notes the same issue occurs for any IPv6 trust subnet with zero leading bits, such as ::/1. Critically, the misconfiguration produces no error and looks correct in code review; only a correctly-written subnet behaves correctly.

Why it matters

When this misconfiguration is present, every unauthenticated client is treated as a trusted proxy at hop 0. That means proxyaddr(req, trust), and by extension req.ip/req.ips in Express applications, will return whatever value an attacker places in the X-Forwarded-For header. The advisory assigns this CVE-2026-90711 with a CVSS of 9.1 and notes a public PoC exists. Any application relying on the trusted client IP for IP-based access control, rate limiting, geolocation decisions, or audit/forensic logging is directly affected — all of those controls can be silently bypassed by spoofing the header.

What defenders should do now

  • Audit any application or middleware config that sets a trust proxy list using IPv4-mapped IPv6 notation (e.g. ::ffff:x.x.x.x/N) or short-prefix IPv6 ranges like ::/1 — these are the exact patterns called out in the advisory.
  • Upgrade proxy-addr to 2.0.8, where an IPv4 address only matches an IPv6 trust subnet if that subnet is a genuine IPv4-mapped subnet whose prefix covers the mapped marker.
  • As an interim workaround per the advisory: write IPv4 trust subnets in plain IPv4 notation (10.0.0.0/8) rather than mapped IPv6 notation, or if mapped notation is required, use the full correct prefix (::ffff:10.0.0.0/104).
  • From a detection/hunting angle, review logs for anomalous or inconsistent X-Forwarded-For values relative to actual connection source IPs, and flag any access-control or rate-limit decisions that trusted a client-supplied forwarded IP without validating it against a correctly-scoped proxy list.

Developing intel

This item is based solely on the GHSA advisory published today; no exploitation in the wild, affected downstream products, or victim details have been confirmed at this time, and this note will not speculate beyond what the advisory states. For full technical details and the patch, see the original advisory: GHSA-jqcg-44mw-7w3h.

Get new detections in your inbox

New ATT&CK coverage plus CISA KEV / CVE detection rules, roughly weekly. No spam, unsubscribe anytime.