@fastify/http-proxy vulnerabilities

@fastify/http-proxy versions 11.6.0 through 11.6.2 normalize literal backslashes before percent-decoding the request path, so a path encoding backslashes and dot-segments survives the dot-segment check and only becomes backslash and double-dot sequences afterward. When the upstream treats backslash as a path separator, the forwarded request walks out of the configured proxy prefix and reaches a sibling upstream location.

@fastify/http-proxy versions 9.0.0 through 11.6.5 substitute URL-decoded route parameters into rewritePrefix without re-encoding them. A parameter value encoding a path separator with a fragment or query delimiter decodes into real separators, injecting extra upstream path segments and stripping the mandatory suffix. An unauthenticated remote attacker can reach upstream locations outside the intended prefix, leading to path-restriction bypass and, depending on the upstream, SSRF or authorization bypass.

A vulnerability in @fastify/http-proxy up to version 11.5.0 causes the request prefix not to be rewritten when the prefix segment is URL-encoded. Fastify URL-decodes paths for route matching, but request.url retains the original encoded form, and the prefix-rewrite step uses a literal string replace against the decoded prefix. A request encoding one or more characters of the configured prefix matches the route but skips the rewrite, so the raw encoded path is forwarded to the upstream unchanged, allowing an attacker to reach upstream paths that the proxy was configured to hide via rewritePrefix, including internal or administrative endpoints.

@fastify/http-proxy versions before 11.6.2 do not validate proxied HTTP request paths for backslash based dot-segments before forwarding them to the configured upstream. The plain HTTP request handler skips the destination validation that the WebSocket path performs, and the underlying reply-from library only rejects forward-slash traversal, so a request containing backslash dot-segments can escape the boundary set by the prefix and rewritePrefix options. An unauthenticated network attacker can use this to reach upstream paths that were meant to stay hidden behind the proxy, resulting in disclosure of internal endpoints. This is a path traversal issue (CWE-22). Users should upgrade to @fastify/http-proxy 11.6.2 or later.

In @fastify/http-proxy versions 9.4.0 through 11.5.0, the resolved WebSocket destination path is not validated against the configured rewrite prefix. Attackers can use path traversal sequences to bypass the prefix and reach unintended upstream endpoints.