Bug 2450330 (CVE-2026-3635)

Summary: CVE-2026-3635 fastify: request.protocol and request.host spoofable via X-Forwarded-Proto/Host from untrusted connections when trustProxy uses restrictive trust function
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: bbrownin, jkoehler, lphiri, sdawley
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in fastify. When the trustProxy option is configured with a restrictive trust function, such as a specific IP, 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 the server, bypassing the proxy, to spoof both the protocol and host seen by the application.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-03-23 14:02:01 UTC
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.