CVE-2026-16732 in Fastify
Summary
by MITRE • 08/19/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in this advisory represents a critical oversight in how the Fastify web framework for Node.js handles reverse proxy configurations when using numeric hop-count values for the trustProxy setting. While previous patches addressed IP, CIDR, and custom-function forms of trustProxy by ensuring that predicates inspecting the connecting address were properly guarded against spoofed forwarded headers, the implementation failed to apply similar safeguards to the numeric form of this configuration. When trustProxy is set to a number, such as one for a single reverse proxy scenario, it compiles into a predicate that structurally ignores the actual network connection details and relies entirely on the presence of specific HTTP headers like X-Forwarded-For or Host. This architectural flaw means that the security guard designed to validate the source address is bypassed because the logic assumes any request arriving with these headers originates from a trusted proxy, regardless of whether it actually did so.
The operational impact of this vulnerability allows an attacker who can reach the Fastify origin directly, thereby bypassing the front-facing reverse proxy, to spoof forwarded request fields just as effectively as in the unpatched versions. By sending requests that include forged X-Forwarded-Host or similar headers from a direct connection rather than through the trusted proxy chain, an adversary can manipulate how the application interprets the client's identity and location. This capability leads directly to host injection attacks where generated URLs reflect attacker-controlled domains, potentially facilitating phishing campaigns or session hijacking if cookies are not strictly configured with domain constraints that account for such spoofing. Furthermore, this flaw enables HTTPS-enforcement bypasses, allowing attackers to trick applications into generating HTTP links instead of secure HTTPS ones, which can undermine transport layer security assumptions and expose sensitive data in transit.
Beyond host injection, the vulnerability facilitates secure-cookie and CSRF-origin bypasses by manipulating the perceived origin of incoming requests. Applications that rely on forwarded headers to determine cookie domains or validate Cross-Site Request Forgery tokens may incorrectly trust malicious origins if they are spoofed via direct connections with forged headers. Additionally, this issue impacts host-based routing mechanisms and can lead to cache poisoning attacks where an attacker forces the application or associated caching layers to store content under a manipulated hostname, affecting other users who subsequently request that resource. The severity of these outcomes aligns closely with the impact class of the parent CVE-2026-3635, emphasizing the systemic risk posed by improper trust boundary validation in reverse proxy environments.
From a classification perspective, this vulnerability maps to CWE-798: Use of Hard-coded Credentials when considering the reliance on implicit trust assumptions rather than explicit verification, and more accurately to CWE-441: Unintended Proxy or Intermediary if viewed through the lens of misconfigured trust boundaries. In terms of offensive security frameworks, it aligns with MITRE ATT&CK technique T1557: Adversary-in-the-Middle, specifically regarding lateral movement within a trusted network segment where an attacker positions themselves to intercept and manipulate traffic that is incorrectly deemed trustworthy due to header spoofing capabilities. The core failure lies in the lack of source address validation for numeric trust configurations, which violates the principle of least privilege by granting proxy-like privileges to any client capable of sending specific headers.
To mitigate this risk, organizations must immediately upgrade Fastify to version 5.12.1 or later, where the numeric form of trustProxy has been disabled at runtime and removed from the TypeScript type union to prevent its accidental use. For environments that cannot patch immediately, a robust workaround involves migrating away from numeric hop-count configurations entirely. Instead, administrators should configure trustProxy using explicit IP addresses, CIDR ranges, or custom functions that actively validate the connecting address against known trusted proxy networks. This ensures that only requests originating from verified infrastructure are allowed to influence host and client identification logic. Additionally, network-level controls such as firewall rules should be implemented to ensure the Fastify origin is reachable exclusively through the designated reverse proxy chain, blocking direct external access to backend services even if application-layer protections fail.