CVE-2026-107318: @fastify/reply-from vulnerable to improper certificate validation in built-in HTTPS transports
@fastify/reply-from is a Fastify plugin that forwards requests to an upstream HTTP or HTTPS server. In versions prior to 12.7.0, all of the built-in HTTPS transports override the secure default and set rejectUnauthorized to false, so the proxy does not verify the TLS certificate of the upstream even when the application points it at an https upstream in the default configuration. An on-path network attacker can therefore impersonate the configured HTTPS upstream, read the credentials and request bodies the proxy forwards, and return forged responses that the application trusts. The issue is fixed in @fastify/reply-from 12.7.0, and users should upgrade to 12.7.0 or later. As a workaround, pass an explicit rejectUnauthorized true on the transport, supply an already configured undici instance, or use the undici global agent.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@fastify/reply-fromto a version that resolves this vulnerability.Fixed in 12.7.0 - Configuration
Pass an explicit rejectUnauthorized: true on the transport; alternatively, supply an already configured undici instance or use the undici global agent.
@fastify/reply-from built-in HTTPS transports rejectUnauthorized = true
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using @fastify/reply-from before 12.7.0 to forward requests to an HTTPS upstream are exposed. The built-in HTTPS transports disable upstream TLS certificate verification even in the default configuration.
What does an attacker need to exploit it?
An attacker needs an on-path network position between the proxy and its configured HTTPS upstream. No application privileges or user interaction are required.
What could an attacker do if exploitation succeeds?
The attacker can impersonate the HTTPS upstream, read forwarded credentials and request bodies, and send forged responses that the application accepts as trusted.
What can be done if upgrading is not immediately possible?
Explicitly set rejectUnauthorized to true on the transport, provide an already configured undici instance, or use the undici global agent. Upgrading to @fastify/reply-from 12.7.0 or later is the documented fix.