CVE-2026-92395: Fastify proxy-addr Auth Bypass Vulnerability

CVE-2026-92395 Overview

CVE-2026-92395 is a critical authentication bypass vulnerability in the @fastify/proxy-addr plugin, which determines a client's address behind trusted reverse proxies and backs the Fastify request.ip and request.ips properties. The flaw affects 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, is accepted without error but trusts every IPv4 address on the internet instead of the intended block. The plugin inherited this defect from the upstream proxy-addr module tracked as CVE-2026-90711. The issue is fixed in @fastify/proxy-addr 5.1.1.

Critical Impact
Any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, defeating IP-based access control, rate limiting, geolocation, and audit logging.

Affected Products

@fastify/proxy-addr versions 3.0.0 through 5.1.0
Fastify applications relying on request.ip or request.ips for trust decisions
Downstream services inheriting the upstream proxy-addr defect (CVE-2026-90711)

Discovery Timeline

2026-09-16 - CVE-2026-92395 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92395

Vulnerability Analysis

The vulnerability is an authentication bypass by spoofed trusted source [CWE-290]. @fastify/proxy-addr walks the proxy chain from the socket peer inward, marking hops as trusted when they match a configured subnet. When an operator supplies an IPv4-mapped IPv6 subnet with an IPv4-sized prefix length, the parser accepts the value without warning and constructs a comparison mask that covers only the high-order bits shared by all IPv4-mapped addresses.

As a result, every IPv4 address on the internet satisfies the trust check at hop 0. Once the immediate socket peer is trusted, the plugin honors client-controlled X-Forwarded-For values without further validation. Any host reaching the application over the network becomes an authoritative source of client-IP information.

Root Cause

The root cause is inconsistent handling of prefix length semantics between IPv4 and IPv6 representations. In IPv4-mapped IPv6 addresses, the IPv4 octets occupy the low 32 bits of the 128-bit address. A correct trust entry for the RFC1918 range 10.0.0.0/8 expressed in mapped notation must use ::ffff:10.0.0.0/104, which reserves 8 host bits at the low end. Using /8 instead reserves 120 host bits and matches nearly the entire address space.

Attack Vector

Exploitation requires no authentication and no user interaction. An attacker sends an HTTP request directly to the vulnerable Fastify application or through any intermediate proxy. The attacker includes a forged X-Forwarded-For header naming any chosen IP address, such as an allowlisted internal address or a benign geolocation. The application reads the forged value through request.ip, bypassing controls that assume the value is proxy-verified.

A misparsed trust configuration such as ::ffff:10.0.0.0/8 is sufficient to trigger the condition. See the GitHub Security Advisory GHSA-8cmm-mhw6-v7xq for the upstream analysis.

Detection Methods for CVE-2026-92395

Indicators of Compromise

Requests containing X-Forwarded-For headers with internal, loopback, or allowlisted addresses arriving from untrusted networks
Application logs showing request.ip values that do not correspond to observed TCP peer addresses
Successful access to admin or IP-restricted endpoints from unexpected geographies
Rate-limiting counters skewed toward a single suspicious spoofed address

Detection Strategies

Inventory Fastify services and enumerate installed @fastify/proxy-addr versions using npm ls @fastify/proxy-addr across build pipelines
Audit trust proxy configuration for IPv4-mapped IPv6 subnets with prefix lengths below 97
Correlate reverse proxy access logs with application logs to detect divergence between socket peer and reported client IP
Alert on unauthenticated requests to sensitive routes when the socket peer sits outside the documented proxy tier

Monitoring Recommendations

Log both the raw TCP peer address and the resolved request.ip in application access logs for post-hoc comparison
Track anomalous distributions of X-Forwarded-For values feeding rate limiters and geofences
Ingest Fastify and reverse proxy logs into a centralized analytics platform to baseline expected client-IP patterns

How to Mitigate CVE-2026-92395

Immediate Actions Required

Upgrade @fastify/proxy-addr to version 5.1.1 or later across all services and container images
Review every configured trust subnet and correct IPv4-mapped IPv6 entries that use IPv4-sized prefixes
Revalidate IP-based access control lists, rate-limit rules, and audit pipelines that depend on request.ip
Rotate any credentials or tokens whose access decisions relied on spoofable client-IP checks during the exposure window

Patch Information

The defect is fixed in @fastify/proxy-addr 5.1.1. Upgrade using npm install @fastify/proxy-addr@^5.1.1 or the equivalent for your package manager, then redeploy affected services. Additional context is available from the OpenJS Foundation Security Advisories and the GitHub Security Advisory GHSA-8cmm-mhw6-v7xq.

Workarounds

Ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97
Express IPv4 ranges in plain IPv4 CIDR notation, for example 10.0.0.0/8 instead of ::ffff:10.0.0.0/8
Terminate untrusted traffic at a reverse proxy that strips inbound X-Forwarded-For headers before forwarding
Restrict application network exposure so only known proxy addresses can reach the Fastify listener

bash

# Configuration example: correct IPv4-mapped IPv6 trust subnet
# Incorrect (vulnerable): trusts the entire IPv4 internet
# trustProxy: '::ffff:10.0.0.0/8'

# Correct: /104 reserves the low 8 bits for host addressing within 10.0.0.0/8
trustProxy: '::ffff:10.0.0.0/104'

# Or use plain IPv4 notation
trustProxy: '10.0.0.0/8'