Skip to main content

Fastify proxy-addr EUVDEUVD-2026-80806

| CVE-2026-92395 CRITICAL
Authentication Bypass by Spoofing (CWE-290)
2026-09-16 openjs
9.1
CVSS 3.1 · Vendor: openjs
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Identify Fastify app with misconfigured IPv4-mapped trust subnet
  2. Delivery
    Send request with forged X-Forwarded-For header
  3. Exploit
    Plugin trusts arbitrary spoofed client IP
  4. Execution
    Bypass IP access control and rate limiting
  5. Impact
    Reach IP-gated resources / poison audit logs

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Anti-spoofing controls
MITRE ATT&CK

1 technique across 1 tactic: Defense Evasion

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires @fastify/proxy-addr version 3.0.0 through 5.1.0 AND a specific operator misconfiguration: a trust subnet written in IPv4-mapped IPv6 notation using an IPv4-sized prefix (e.g. ::ffff:10.0.0.0/8) rather than the mapped-space equivalent (/104). Under that condition the misconfigured range silently expands to trust all IPv4 addresses, so any unauthenticated remote client can spoof X-Forwarded-For to control request.ip/request.ips. Deployments that express trust ranges in plain IPv4 notation, use a prefix length of at least 97 for mapped ranges, or do not use trusted-proxy IP handling are NOT affected - this misconfiguration precondition is the primary factor limiting real-world exposure despite the unauthenticated network attack path.

Impact

The vendor CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) presents this as a critical remote, unauthenticated trust-boundary bypass, and the vector is internally consistent with the description: any Internet client can spoof X-Forwarded-For once the flaw is triggered. However, a crucial gating factor is NOT captured in the CVSS base score - exploitation requires the operator to have written a trust subnet in IPv4-mapped IPv6 notation with an IPv4-sized prefix (e.g. ::ffff:10.0.0.0/8 instead of the correct /104). This is an operator misconfiguration precondition, so real-world exposure is limited to deployments that both use @fastify/proxy-addr 3.0.0-5.1.0 AND configured trust ranges in that specific erroneous form. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so there is no signal of active or imminent exploitation - this is a real, high-impact configuration-dependent weakness rather than a confirmed mass-exploited threat. The C:H/I:H rating is defensible because bypassing IP-based access control can expose IP-gated admin endpoints (confidentiality) and enable spoofed/forged actions and poisoned audit logs (integrity); A:N is correct as no availability impact is described. Note the shared root cause with upstream proxy-addr CVE-2026-90711 means the true footprint of the class is broader than this Fastify plugin alone.

Exploit ScenarioDerived

An operator configures @fastify/proxy-addr to trust an internal range but writes it as ::ffff:10.0.0.0/8, which is silently accepted and effectively trusts every IPv4 address on the Internet. An unauthenticated remote attacker then sends a request with a forged X-Forwarded-For header, and because their socket peer is treated as trusted at hop 0, the application reads the attacker-chosen address for request.ip - bypassing IP allowlists, rate limits, geolocation, and audit logging. No public exploit code is identified, but the technique is trivial (a single crafted HTTP header).

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 16, 2026

IP spoofing in @fastify/proxy-addr 3.0.0 through 5.1.0 allows any unauthenticated remote client to control the client address an application believes it received, defeating IP-based access control, rate limiting, geolocation, and audit logging. The flaw is triggered only under a specific operator misconfiguration: a trusted-proxy subnet expressed in IPv4-mapped IPv6 notation with an IPv4-sized prefix (for example ::ffff:10.0.0.0/8) is silently accepted but expands to trust every IPv4 address, making the socket peer trusted at hop 0 so an attacker-supplied X-Forwarded-For header is honored. Vendor CVSS is 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), and no public exploit code or confirmed active exploitation was identified at time of analysis; severity in practice is bounded by the misconfiguration precondition, and the issue is fixed in 5.1.1.

RemediationAI

Upgrade to @fastify/proxy-addr 5.1.1 or later (vendor-released patch, per advisory GHSA-8cmm-mhw6-v7xq); no patched release exists for the 3.x or 4.x lines, so staying on those branches requires the configuration workaround rather than a version bump. If an immediate upgrade is not possible, audit every trusted-proxy trust range and either rewrite IPv4-mapped ranges in plain IPv4 notation (for example 10.0.0.0/8) or set the mapped prefix length to at least 97 (the correct mapping of an IPv4 /8 is ::ffff:10.0.0.0/104); this is a pure configuration change with no functional loss, and it fully neutralizes the bypass because the over-broad range is never registered. Additional compensating controls, each with trade-offs: stop honoring X-Forwarded-For at the application layer and instead read the socket peer address (breaks correct client identification for legitimate proxies); restrict the trust list to the exact proxy addresses rather than a broad subnet (adds maintenance overhead when proxy fleets scale); and front the service with a load balancer or WAF that overwrites, rather than appends to, client-supplied forwarding headers (adds infrastructure and can disrupt legitimate multi-hop proxy chains). Rotating any secrets protected solely by IP allowlists is advisable, since those controls may already have been bypassable. Vendor tracking: https://cna.openjsf.org/security-advisories.html.

Affected VersionsENISA

@fastify/proxy-addr 3.0.0 <5.1.1

Affected Packages

euvd fastify_proxy_addr fix: 5.1.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The package @fastify/proxy-addr is a Fastify plugin that resolves a request's client address behind trusted reverse proxies and backs request.ip and request.ips; it inherits its address-trust logic from the upstream proxy-addr module, which carries the same defect as CVE-2026-90711. The root cause is CWE-290 (Authentication Bypass by Spoofing) arising from incorrect parsing of IPv4-mapped IPv6 CIDR notation: in the mapped space ::ffff:0:0/96, each IPv4 address occupies the low 32 bits, so an IPv4 block of size /8 corresponds to a mapped-space prefix of /104, and any mapped prefix shorter than /97 is invalid for expressing IPv4 ranges. The plugin validates the syntactic form but does not reject or correct an IPv4-sized prefix such as /8, so the range is applied as a mapped-space /8 that encompasses all ::ffff:x.x.x.x addresses - effectively the entire IPv4 Internet. Once the connecting peer falls inside that over-broad trusted range, it is trusted at hop 0 and its self-asserted X-Forwarded-For value becomes the derived client address, giving a remote, unauthenticated attacker (PR:N per the assessed vector) full control of request.ip and request.ips. Because the defect is purely in address-range interpretation, no memory-safety or injection primitive is involved; the impact is a complete trust-boundary failure for any application logic that relies on the derived client address.

Know when Fastify Proxy Addr gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (openjs) PRIMARY 9.1 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
vuln.today AI 9.1 CRITICAL

Once the erroneous trust subnet is configured, an unauthenticated remote attacker trivially spoofs client IP (PR:N/AC:L); access-control bypass yields C:H/I:H, no availability impact; config precondition is not modeled in base metrics.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Red Hat 7.4 HIGH

Primary rating from Vendor (openjs).

CVSS VectorVendor: openjs

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

2
Patch available
Sep 16, 2026 - 16:04 EUVD
CVE Published
Sep 16, 2026 - 14:35 cve.org
CRITICAL 9.1

DescriptionCVE.org

@fastify/proxy-addr is a Fastify plugin that determines a request's client address behind trusted reverse proxies, and it backs Fastify request.ip and request.ips. In versions 3.0.0 through 5.1.0, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. The plugin inherited this defect from the upstream proxy-addr module (CVE-2026-90711). The issue is fixed in @fastify/proxy-addr 5.1.1, and users should upgrade to 5.1.1 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation.

Technical POC Analysis

CWE-290 - Authentication Bypass by Spoofing.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

@fastify/proxy-addr versions 3.0.0 through 5.1.0 can be misconfigured so that any unauthenticated internet client controls the client IP address our applications believe they received, allowing attackers to bypass IP allow-lists, evade rate limits, falsify geolocation, and poison audit logs. The exposure is bounded by a specific configuration precondition - a trusted-proxy subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix (for example ::ffff:10.0.0.0/8) - so leadership should treat this as a configuration-driven integrity failure in our edge trust model rather than an imminent intrusion. Ownership sits with the engineering and platform teams responsible for Node.js services running the affected library and for any security decision still anchored on client IP.

Business Impact: High
Compensating Controls

Apply vendor patch (upgrade to 5.1.1 per the vendor advisory; note the supplied patch-status field still lists the patch as unavailable, so confirm release availability with the vendor before relying on it). Until the upgrade is in place, correct the misconfiguration by expressing trusted-proxy subnets in native IPv4 CIDR notation rather than IPv4-mapped IPv6 form, remove any ::ffff:-prefixed trusted-proxy entries, and pin trust to specific proxy host addresses; additionally, stop using client IP as an authentication or authorization factor, enforce rate limiting and allow-listing at the edge (WAF, load balancer, or reverse proxy) where the address is determined by the network rather than request headers, require authenticated sessions for sensitive functions, and flag or suppress client-IP-derived audit records that may have been spoofed.

Threat Intelligence Overview

EPSS Score
0.3%
Top 77% exploitable
Prevalence
Medium
Official plugin for popular Fastify Node.js framework, but niche vs core proxy-addr
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

46
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +46
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Vendor StatusVendor

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy