CVE-2026-16732: fastify vulnerable to X-Forwarded-* spoofing under trustProxy hop-count
Impact
The fix for CVE-2026-3635 (GHSA-444r-cwp2-x5xf) added a proxyFn(socket.remoteAddress, 0) guard on the X-Forwarded- reads in request.host, request.protocol, request.hostname, request.ip, and request.ips. That guard closes the IP, CIDR, and custom-function forms of trustProxy correctly because those forms compile to predicates that inspect the connecting address. The hop-count form (trustProxy: <number>) compiles to a predicate that structurally ignores the address argument, so the guard reduces to 0 < tp, always true for any tp >= 1.
Applications configured with trustProxy: <number> (documented as "behind N reverse proxies", trustProxy: 1 being the canonical single-proxy setting) remain vulnerable. An attacker who can reach the Fastify origin directly, bypassing the front-facing proxy, can spoof the request fields exactly as in the unpatched version. Impact class matches the parent CVE-2026-3635: host injection in generated URLs, HTTPS-enforcement bypass, secure-cookie / CSRF-origin bypass, host-based routing and cache poisoning.
Patches
Patched in fastify 5.12.1. The numeric form of trustProxy is now disabled at runtime and removed from the TypeScript type union.
Workarounds
- Migrate to an IP / CIDR / custom-function trustProxy value that validates the connecting address. Custom functions must inspect the address argument, not only the hop index. - Ensure the Fastify origin is only reachable through the trusted proxy chain (no direct network path).
Other sources
fastify is a fast and low overhead web framework for Node.js. Impact: the fix for CVE-2026-3635 added a guard on the forwarded-header reads used to derive the request host, protocol, hostname, ip, and ips values, checking the connecting address. That guard closes the IP, CIDR, and custom-function forms of trustProxy correctly, because those forms compile to predicates that inspect the connecting address. The hop-count form, where trustProxy is set to a number, compiles to a predicate that structurally ignores the address, so the guard is always satisfied for any hop count of one or more. Applications configured with a numeric trustProxy value, such as trustProxy set to 1 for a single reverse proxy, remain vulnerable: an attacker who can reach the Fastify origin directly, bypassing the front-facing proxy, can spoof the forwarded request fields exactly as in the unpatched version. The impact class matches the parent CVE-2026-3635, including host injection in generated URLs, HTTPS-enforcement bypass, secure-cookie and CSRF-origin bypass, and host-based routing and cache poisoning. Affected versions are fastify from 5.8.3 up to but not including 5.12.1. Patches: patched in fastify 5.12.1, where the numeric form of trustProxy is disabled at runtime and removed from the TypeScript type union. Workarounds: migrate to an IP, CIDR, or custom-function trustProxy value that validates the connecting address, and ensure the Fastify origin is only reachable through the trusted proxy chain.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/fastifyto a version that resolves this vulnerability.Fixed in 5.12.1 - Upgrade
Upgrade
fastifyto a version that resolves this vulnerability.Fixed in 5.12.1 - Configuration
Ensure `trustProxy` is set using an IP, CIDR, or a custom-function that validates the connecting address (inspect the `address` argument, not only the hop index). Avoid `trustProxy: <number>`/hop-count values such as `trustProxy: 1`, which remain vulnerable when the Fastify origin is reachable directly.
Fastify trustProxy = Use a validating trustProxy IP/CIDR/custom-function predicate - Compensating control
Ensure the Fastify origin is only reachable through the trusted proxy chain (no direct network path to the Fastify origin that can bypass the front-facing proxy).
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Applications using Fastify 5.8.3 through versions before 5.12.1 are affected when trustProxy is configured as a numeric hop count of one or greater. The relevant exposure requires that the Fastify origin can be reached directly rather than only through the intended reverse proxy.
What does an attacker need to exploit this issue?
An unauthenticated attacker must be able to bypass the front-facing proxy and connect directly to the Fastify origin. They can then supply spoofed X-Forwarded-* fields that Fastify accepts under numeric trustProxy configuration.
Is a typical single-proxy trustProxy configuration affected?
Numeric trustProxy settings, including trustProxy: 1 for a single reverse proxy, are affected. IP-address, CIDR, and custom-function trustProxy forms are described as correctly checking the connecting address.
What mitigation is available before patching?
If upgrading is not immediately possible, prevent direct access to the Fastify origin so requests can reach it only through the designated reverse proxy. This removes the direct-origin access required for spoofing.
How can I determine whether my application is affected?
Check whether the application runs a Fastify version from 5.8.3 up to but not including 5.12.1 and whether trustProxy is configured as a number of one or more. Also determine whether network paths permit clients to connect to the Fastify origin without passing through the front-facing proxy.