GHSA-3m5p-2c4r-xxw2: CSRF
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).
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.1Patch GHSA-444r-cwp2-x5xf - Configuration
Do not use Fastify's numeric `trustProxy: <number>` (e.g., `trustProxy: 1` behind a single proxy), because the hop-count predicate ignores the address and remains vulnerable. Configure `trustProxy` with an IP/CIDR value or a custom-function that validates the connecting address (the custom function must inspect the `address` argument, not only the hop index).
Fastify trustProxy = (disable numeric trustProxy form; use IP/CIDR/custom-function trustProxy that validates connecting address) - Compensating control
Ensure the Fastify origin is only reachable through the trusted proxy chain and not directly on the network path (block direct client access to the Fastify origin so requests cannot bypass the front-facing proxy).
Event History
Frequently Asked Questions
Which Fastify deployments remain exposed after the earlier trust-proxy fix?
Applications using the hop-count form of trustProxy, such as trustProxy: 1 for a single reverse proxy, remain vulnerable. IP, CIDR, and custom-function trustProxy configurations are covered by the earlier guard because they evaluate the connecting address.
What must an attacker be able to do to exploit this issue?
The attacker must be able to connect directly to the Fastify origin while bypassing the front-facing reverse proxy. They can then spoof X-Forwarded-* values that influence request.host, request.protocol, request.hostname, request.ip, and request.ips.
What security controls or application behavior can be affected by spoofed forwarded headers?
The described impacts include host injection in generated URLs, HTTPS-enforcement bypass, secure-cookie and CSRF-origin bypass, and host-based routing and cache behavior. Exploitation depends on the application using the affected request fields for those decisions.