@fastify/http-proxy vulnerabilities

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

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.

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.