CVE-2026-16117 in http-proxy
Summary
by MITRE • 07/18/2026
Impact: @fastify/http-proxy versions up to and including 11.5.0 fail to rewrite the request prefix when the prefix segment is URL-encoded. Fastify's router 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 that encodes one or more characters of the configured prefix therefore matches the route but skips the rewrite, so the raw encoded path is forwarded to the upstream unchanged. The upstream then decodes the path and serves it, letting an attacker reach upstream paths that the proxy was configured to hide via rewritePrefix, including internal or administrative endpoints.
Patches: upgrade to @fastify/http-proxy 11.6.0.
Workarounds: none.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/18/2026
This vulnerability resides in the fastify/http-proxy middleware component affecting versions 11.5.0 and earlier, where a critical path traversal flaw occurs due to improper handling of URL-encoded prefixes during request forwarding. The issue stems from a fundamental mismatch between how Fastify's routing system processes incoming requests and how the proxy component handles prefix rewriting. When Fastify routes match requests, it automatically URL-decodes paths for route matching purposes but preserves the original encoded form in the request.url property. However, the prefix-rewrite functionality employs a literal string replacement operation against the decoded prefix value rather than accounting for the encoded nature of the actual request path.
The technical flaw manifests when an attacker crafts a request where one or more characters of the configured proxy prefix are URL-encoded, causing the routing system to correctly match the route while simultaneously bypassing the intended prefix rewriting mechanism. This creates a scenario where requests containing encoded prefix segments successfully trigger the proxy's route matching logic but fail to undergo proper prefix replacement, allowing the original encoded path to be forwarded unchanged to the upstream server. The upstream server processes this raw encoded path and subsequently decodes it, potentially exposing internal or administrative endpoints that should have been hidden through proper prefix rewriting configuration.
This vulnerability directly maps to CWE-22 known as "Improper Limitation of a Pathname to a Restricted Directory" and aligns with ATT&CK technique T1071.004 for application layer protocol tunneling. The operational impact is severe as it essentially defeats the security controls implemented through proxy prefix rewriting, potentially allowing unauthorized access to internal systems, administrative interfaces, or sensitive endpoints that should remain protected from direct client access. Attackers can leverage this flaw to bypass authentication mechanisms and reach backend services that are normally restricted through proper proxy configuration.
The fix requires upgrading to version 11.6.0 of @fastify/http-proxy which implements proper handling of URL-encoded prefixes during the rewrite process. This patch ensures that the prefix replacement logic correctly accounts for encoded path segments rather than performing literal string replacements against decoded values. Organizations should immediately implement this upgrade across all systems utilizing affected versions, as there are no viable workarounds available to mitigate this vulnerability without upgrading the software component. The vulnerability demonstrates a critical design flaw in how URL encoding is handled in proxy middleware components and underscores the importance of consistent handling of encoded vs decoded path representations throughout web application security controls.