CVE-2026-90711 is a critical-severity (CVSS 9.1) CWE-290 vulnerability in proxy-addr. A fix is available for proxy-addr — see the affected versions and patch details below.
proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-90711.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
proxy-addrnpmDescription
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | proxy-addr | ≥ 1.1.0&&< 2.0.8 | 2.0.8npm install proxy-addr@2.0.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for proxy-addr, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update proxy-addr to 2.0.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-90711 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is rated as Important because unauthenticated remote attackers can spoof client IP addresses and circumvent security controls, such as rate limits or network access lists, by sending custom forwarding headers. Exploitation is contingent on application configurations that define reverse proxy trust…
To mitigate this flaw through configuration: 1. Configure trusted proxy definitions using standard IPv4 notation (such as `10.0.0.0/8`) rather than IPv4-mapped IPv6 notation. 2. If IPv4-mapped IPv6 notation is required, set the subnet prefix length to at least 97 to cover the mapped boundary (for example, specify `::ffff:10.0.0.0/104` instead of `::ffff:10.0.0.0/8`). 3. Alternatively, sanitize or strip incoming `X-Forwarded-For` headers at edge load balancers or boundary reverse proxies before passing traffic to backend applications. Warning: Modifying application configuration files requires restarting the Node.js application service, which will temporarily interrupt service availability…Source: Red Hat security advisory for CVE-2026-90711 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Ansible Automation Platform 2.6 for RHEL 9 | automation-platform-ui-0:2.6.15-1.el9ap | RHSA-2026:87004 |
| Red Hat Ansible Automation Platform 2.2 | ansible-automation-platform/automation-portal:1792523640 | RHSA-2026:86675 |
| Red Hat Developer Hub 1.10 | rhdh/red-hat-developer-hub-backstage-plugin-lightspeed-backend:1792506092 | RHSA-2026:86957 |
| Red Hat Developer Hub 1.10 | rhdh/rhdh-hub-rhel9:1792593817 | RHSA-2026:88198 |
| Red Hat Migration Toolkit 1.8 | rhmtc/openshift-migration-ui-rhel8:1791853281 | RHSA-2026:85846 |
Frequently Asked Questions
Is CVE-2026-90711 in your dependencies?
Find it across npm, including transitive dependencies.