CVE-2026-3635

What it actually does

The flaw causes Fastify applications configured with a restrictive trustProxy setting to incorrectly trust X-Forwarded-Proto and X-Forwarded-Host headers from untrusted direct clients. As a result, request.protocol and request.host can reflect attacker-supplied values even when the connection did not come from a trusted reverse proxy. Applications that rely on those getters for security-sensitive logic may make incorrect decisions, such as treating an insecure request as HTTPS, accepting a forged host during origin validation, generating attacker-controlled absolute URLs, applying incorrect secure-cookie behavior, or routing requests based on a spoofed hostname.

Why it matters to the business

Organizations running affected Fastify versions may have applications that can be tricked into trusting forged request metadata. The practical impact depends on how the application uses request.protocol and request.host: it may enable bypasses of HTTPS enforcement, CSRF or origin checks, incorrect redirect or link generation, host-based access-control mistakes, or exposure of sensitive workflows through spoofed request context. The reported CVSS is moderate and EPSS is currently low, and it is not listed in CISA KEV, but internet-facing applications using Fastify behind proxies should still treat this as important because the weakness sits in common request-handling logic and may be exploitable without authentication in affected configurations.

How an attack unfolds

An attacker first identifies a Fastify application that is reachable directly, rather than only through its intended reverse proxy or load balancer. The application must be running an affected Fastify version and have trustProxy configured restrictively, such as a specific trusted proxy IP, subnet, hop count, or custom trust function. The attacker then sends crafted HTTP requests directly to the Fastify service and includes forged X-Forwarded-Proto and X-Forwarded-Host headers. Due to the vulnerability, request.protocol and request.host may use those untrusted header values even though the client is not a trusted proxy. If the application uses those values in security logic, the attacker may influence behavior such as HTTPS checks, generated URLs, host allowlists, CSRF origin validation, callback construction, or host-based routing. Successful exploitation is application-dependent and generally requires that the attacker can reach the Fastify server directly and that the application makes security decisions from the affected getters.

How to fix it

Upgrade Fastify to a version that contains the fix when available from the Fastify maintainers. The supplied advisory identifies fastify versions <= 5.8.2 as affected, but no fixed version was provided in the input; monitor the official Fastify release notes, npm advisory data, and GitHub security advisories for the patched release. As compensating controls, ensure Fastify application ports are not directly reachable from untrusted networks and can only be accessed by the intended reverse proxy or load balancer. At the proxy layer, strip or overwrite X-Forwarded-Proto and X-Forwarded-Host before forwarding requests, and reject requests arriving at the application service from non-proxy source addresses. Review application code for security decisions based on request.protocol or request.host and prefer validated, canonical configuration values or framework APIs that correctly enforce proxy trust. Where host validation is required, enforce an explicit allowlist independent of user-supplied forwarded headers.

How to confirm the fix worked

Confirm the deployed Fastify version is no longer in the affected range once a patched release is available. Review package manifests and lockfiles, such as package.json, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, or yarn.lock, for fastify versions <= 5.8.2. Validate network architecture by confirming the Fastify listener is not directly reachable from the internet or untrusted network segments. Test behavior by sending a direct request to the Fastify service from an untrusted source with X-Forwarded-Proto and X-Forwarded-Host headers set to controlled values; after remediation, application behavior must not trust those values unless the request came through a trusted proxy. Also verify that the edge proxy overwrites or removes inbound forwarded headers and that application-level host/origin checks reject unexpected hostnames.

Typical attack path

1. Discover a Fastify service that is exposed directly or reachable without passing through the expected trusted reverse proxy.
2. Confirm the service is running an affected Fastify version and uses a restrictive trustProxy configuration.
3. Send direct HTTP requests containing attacker-controlled X-Forwarded-Proto and X-Forwarded-Host headers.
4. Cause request.protocol and request.host to reflect the forged header values.
5. Abuse application logic that relies on those values, such as HTTPS enforcement, secure-cookie decisions, CSRF or origin checks, URL generation, redirects, or host-based routing.
6. Use the resulting trust-boundary confusion to access sensitive functionality, bypass checks, or induce users or services to interact with attacker-controlled URLs, depending on application behavior.

How to detect it

Review reverse proxy, load balancer, web server, application, and container ingress logs for direct requests to Fastify backends that include X-Forwarded-Proto or X-Forwarded-Host headers from source IPs that are not trusted proxies. Look for mismatches between the actual local listener or TLS termination point and the forwarded protocol value, such as direct plain HTTP requests claiming X-Forwarded-Proto: https. Search for unusual X-Forwarded-Host values, including external domains, attacker-controlled domains, IP literals, localhost/internal hostnames, or hostnames not present in the application allowlist. Examine application logs for redirects, generated links, CSRF validation outcomes, origin-check failures or bypasses, host-based route selections, and secure-cookie behavior that correlate with forged forwarded headers. If application request logging does not currently capture forwarded headers and source IPs, enable temporary structured logging at the edge and application boundary to determine whether untrusted clients can influence request.protocol or request.host. Also review firewall, security group, Kubernetes NetworkPolicy, and ingress controller logs to identify any direct access path to the Fastify service that bypasses the intended proxy.

• X-Forwarded-Proto: https
• X-Forwarded-Proto: http
• X-Forwarded-Host:
• x-forwarded-proto
• x-forwarded-host
• request.protocol
• request.host
• trustProxy
• trust proxy
• X-Forwarded-Host: localhost
• X-Forwarded-Host: 127.0.0.1
• X-Forwarded-Host: 0.0.0.0
• X-Forwarded-Host: internal
• X-Forwarded-Host: admin
• X-Forwarded-Proto: javascript
• X-Forwarded-Proto: file

What your security team should do

• Inventory all applications using Fastify and identify versions <= 5.8.2, especially internet-facing services behind reverse proxies.
• Prioritize applications that configure trustProxy with a specific IP, subnet, hop count, or custom trust function and that use request.protocol or request.host in security-sensitive code.
• Restrict direct network access to Fastify application ports so only trusted reverse proxies or load balancers can connect.
• Configure reverse proxies to strip client-supplied X-Forwarded-Proto and X-Forwarded-Host headers and set trusted values explicitly.
• Upgrade Fastify to the patched version as soon as it is released and verify lockfiles and container images are rebuilt with the fixed dependency.
• Search application code for request.protocol and request.host usage in HTTPS enforcement, cookie settings, CSRF validation, redirects, URL generation, and host-based routing.
• Add monitoring for requests containing X-Forwarded-Proto or X-Forwarded-Host that arrive from non-proxy source addresses.
• If exposure is found, review access logs for suspicious forwarded-host values, unexpected protocols, redirect abuse, origin-check bypass attempts, or anomalous host-based routing behavior.