CVE-2026-92395: @fastify/proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet
@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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@fastify/proxy-addrto a version that resolves this vulnerability.Fixed in 5.1.1 - Configuration
As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97 (example: ::ffff:10.0.0.0/104), or rewrite the trust range in plain IPv4 notation.
@fastify/proxy-addr trust subnet (IPv4-mapped IPv6 notation prefix length) = at least 97 (e.g., use ::ffff:10.0.0.0/104 instead of ::ffff:10.0.0.0/8) or express the range in plain IPv4 notation - Compensating control
Because socket peer is trusted at hop 0, consider enforcing IP-based controls (access control, rate limiting, geolocation, audit logging) using additional trusted mechanisms rather than relying on request.ip/request.ips until the service is upgraded to @fastify/proxy-addr 5.1.1 or later.
Event History
Frequently Asked Questions
Which deployments are exposed to spoofed client IP addresses?
Deployments using @fastify/proxy-addr versions 3.0.0 through 5.1.0 are exposed if they configure a trusted subnet in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8. That configuration causes every IPv4 socket peer to be trusted rather than only the intended range.
Does an attacker need access to a trusted proxy or credentials?
No. Once the malformed trust subnet is configured, any unauthenticated client can send an arbitrary X-Forwarded-For header and control the address returned to the application through request.ip and request.ips.
What can be affected if the application relies on these address fields?
IP-based access controls, rate limiting, geolocation decisions, and audit logging can be bypassed or corrupted because the application may treat an attacker-chosen X-Forwarded-For value as the client address.
What can be done before upgrading?
Ensure IPv4-mapped IPv6 trust subnets use a prefix length of at least 97, or express the trusted range in plain IPv4 notation. Upgrade to @fastify/proxy-addr 5.1.1 or later when possible.