CVE-2025-66415

@fastify/reply-from versions up to and including 12.8.0 validate proxy paths only against forward-slash dot-segments, then build the target with the WHATWG URL parser, which normalizes backslash and its percent-encoded form to a forward slash. A path using backslash dot-segments bypasses the traversal check and resolves to a different upstream path. An unauthenticated request can escape the intended prefix and reach other upstream endpoints.

@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.

Vulnerability in @fastify/reply-from versions 8.3.1 up to but not including 12.6.4. The internal URL cache key is built by concatenating the destination and source path without a delimiter, leading to key collisions and requests being routed to the wrong upstream, enabling cross-upstream data access and modification.

A vulnerability in @fastify/reply-from (up to v12.6.1) and @fastify/http-proxy (up to v11.4.3) allows attackers to strip proxy-added headers after they have been added, by manipulating the Connection header. Clients can selectively remove headers used for routing, access control, or security.