CVE-2026-117518 in reply-from
Summary
by MITRE • 11/02/2026
@fastify/reply-from is a Fastify plugin that forwards requests to an upstream HTTP server. In versions up to and including 12.8.0, the plugin validated proxy paths against forward-slash dot-segments only and then built the target with the WHATWG URL parser, which normalizes a backslash and its percent-encoded form to a forward slash on the http, https, ws, and wss schemes. A path that uses backslash dot-segments therefore bypasses the traversal check and resolves to a different upstream path, so an application that scopes proxying to an upstream prefix, or relies on route guards in front of the forwarding call, can have an unauthenticated request escape the intended prefix and reach other upstream endpoints. The resulting access to unintended upstream resources is primarily a confidentiality impact with limited integrity impact. The issue is fixed in @fastify/reply-from 12.8.1, where the path is normalized and any segment resolving to a single or double dot, along with control characters and ambiguous whitespace, is rejected before the URL is constructed, and users should upgrade to 12.8.1 or later. There is no workaround other than upgrading.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability in @fastify/reply-from versions up to and including 12.8.0 represents a critical path traversal flaw rooted in inconsistent input validation logic within the plugin's request forwarding mechanism. As a Fastify plugin designed to proxy HTTP requests to upstream servers, its security model relies heavily on correctly scoping access to specific upstream prefixes or enforcing route guards before forwarding traffic. The core technical defect lies in how the plugin validates and normalizes URL paths prior to constructing the target URI. Specifically, the validation logic only checked for forward-slash dot-segments such as ../ while neglecting equivalent representations using backslashes. This oversight created a bypass vector where attackers could manipulate the request path to escape intended boundaries.
The exploitation of this flaw leverages the behavior of the WHATWG URL parser used by Node.js and modern browsers, which normalizes both forward slashes and their percent-encoded variants into standard forward slashes for http, https, ws, and wss schemes. Crucially, this normalization process also treats backslashes as equivalent to forward slashes in many contexts or allows them to persist in a way that bypasses the initial validation check. When an attacker submits a path containing backslash dot-segments like ..\.. they evade the plugin's security checks because those segments are not recognized as traversal attempts by the pre-validation logic. However, when the WHATWG URL parser subsequently processes this input to build the final target URI, it interprets these sequences correctly as directory traversals or normalizes them in a manner that resolves to an unintended upstream path.
This discrepancy between validation and execution allows unauthenticated requests to bypass application-level scoping mechanisms. If an organization relies on @fastify/reply-from to restrict proxying to a specific subdirectory of an upstream server, this vulnerability enables attackers to traverse out of that directory structure entirely. Similarly, if route guards are implemented in the Fastify application layer before invoking the forwarding function, they may validate the incoming request path but fail to account for how the plugin internally transforms it. Consequently, sensitive internal endpoints or administrative interfaces hosted on the upstream server can be accessed by unauthorized users who should have been blocked at the proxy level.
The operational impact of this vulnerability is primarily focused on confidentiality rather than integrity. Attackers gain access to unintended upstream resources that are not meant for public consumption. This could include private API responses, internal service configurations, or sensitive data stored in directories outside the allowed scope. While direct modification of upstream content via this specific vector is limited due to the read-heavy nature of typical proxying scenarios, the exposure of restricted information poses a significant risk depending on the sensitivity of the backend services involved. The lack of integrity impact suggests that while attackers can view unauthorized data, they cannot easily alter server-side state through this specific path traversal mechanism alone.
From a standards perspective, this vulnerability aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory and CWE-749 Exposed Dangerous Method or Function in the context of improper input validation leading to unauthorized access. It also maps to MITRE ATT&CK techniques related to Discovery and potentially Lateral Movement if internal services are accessed, specifically leveraging path traversal for unauthorized resource discovery. The failure lies not just in the missing check but in the assumption that client-side normalization matches server-side parsing behavior without explicit enforcement of canonicalization rules before validation occurs.
The recommended mitigation is straightforward and mandatory: upgrade @fastify/reply-from to version 12.8.1 or later. In this patched release, developers have addressed the root cause by implementing rigorous path normalization prior to any URL construction. The updated logic explicitly rejects any segment that resolves to a single dot (current directory) or double dot (parent directory), along with control characters and ambiguous whitespace that could be used for obfuscation attacks. This ensures that all potential traversal vectors, including those using backslashes or encoded variants, are identified and blocked before the request is forwarded upstream. There are no viable workarounds such as configuration changes or middleware additions; upgrading to the fixed version is the only effective remediation strategy to restore secure proxying behavior.