GHSA-3m5p-2c4r-xxw2 fastify vulnerable to X-Forwarded-* spoofing under trustProxy hop-count

• npm fastify: >= 5.8.3, < 5.12.1 → fixed in 5.12.1

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: `) compiles to a predicate that structurally ignores the address argument, so the guard reduces to `0 = 1`. Applications configured with `trustProxy: ` (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).