CVE-2026-3635 in Fastify
Summary
by MITRE • 03/23/2026
Summary When trustProxy is configured with a restrictive trust function (e.g., a specific IP like trustProxy: '10.0.0.1', a subnet, a hop count, or a custom function), the request.protocol and request.host getters read X-Forwarded-Proto and X-Forwarded-Host headers from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application.
Affected Versions fastify <= 5.8.2
Impact Applications using request.protocol or request.host for security decisions (HTTPS enforcement, secure cookie flags, CSRF origin checks, URL construction, host-based routing) are affected when trustProxy is configured with a restrictive trust function.
When trustProxy: true (trust everything), both host and protocol trust all forwarded headers — this is expected behavior. The vulnerability only manifests with restrictive trust configurations.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/23/2026
The vulnerability described in CVE-2026-3635 represents a critical security flaw in the Fastify web framework that undermines the trust proxy functionality when configured with restrictive trust functions. This issue affects versions of Fastify up to and including 5.8.2, where the framework's handling of forwarded headers creates a path for attackers to manipulate core application protocol and host information. The vulnerability specifically targets applications that rely on the request.protocol and request.host getters for making security-sensitive decisions, creating a scenario where attackers can bypass intended security controls by directly connecting to the Fastify server rather than routing through a trusted proxy.
The technical flaw stems from the inconsistent handling of forwarded headers across different trust proxy configurations. When trustProxy is set to a restrictive function such as a specific IP address, subnet, hop count, or custom validation function, the framework fails to properly validate the source of X-Forwarded-Proto and X-Forwarded-Host headers. This behavior creates a security boundary violation where headers from untrusted connections are accepted and processed, despite the proxy configuration intended to limit trust to specific sources. The vulnerability manifests because the framework does not properly check the connection source when processing forwarded headers, allowing direct connections to influence application behavior that should only be accessible through legitimate proxy channels.
Applications utilizing request.protocol and request.host for security-critical operations face significant operational impact from this vulnerability. The flaw enables attackers to spoof the protocol and host information that applications use for HTTPS enforcement, secure cookie flag management, CSRF origin validation, URL construction, and host-based routing decisions. This compromise can lead to various security consequences including bypassing HTTPS requirements, manipulating secure cookie attributes, conducting cross-site request forgery attacks, and potentially enabling path traversal or other routing-based exploits. The vulnerability is particularly dangerous because it operates silently, allowing attackers to manipulate application behavior without detection while maintaining the appearance of legitimate traffic.
The security implications extend beyond simple header manipulation to encompass fundamental application trust models and security boundary enforcement. When applications make security decisions based on protocol and host information, they become vulnerable to attacks that exploit this inconsistency in trust proxy handling. This vulnerability aligns with CWE-284 (Improper Access Control) and CWE-352 (Cross-Site Request Forgery) categories, as it enables unauthorized manipulation of security-critical application state. From an ATT&CK framework perspective, this vulnerability maps to T1071.004 (Application Layer Protocol: DNS) and T1566 (Phishing) as attackers can manipulate application behavior through spoofed protocol and host information, potentially enabling more sophisticated attacks. Organizations should immediately update to patched versions of Fastify, review their trust proxy configurations to ensure proper implementation, and conduct security assessments to identify applications that may be vulnerable to this specific manipulation of forwarded headers.
Mitigation strategies should focus on immediate patching of affected Fastify versions, followed by comprehensive review of trust proxy configurations across all applications. Security teams must implement network-level controls to prevent direct connections to Fastify servers from untrusted sources, while also ensuring that all forwarded headers are properly validated against known trusted proxy IP ranges. Organizations should consider implementing additional security controls such as header validation middleware, rate limiting for suspicious header combinations, and network segmentation to isolate Fastify applications from direct internet access. The vulnerability highlights the importance of proper input validation and source verification in web application frameworks, emphasizing that trust proxy configurations must be thoroughly tested to ensure they properly enforce security boundaries and prevent header manipulation attacks that could compromise application security.