@fastify/reply-from vulnerable to path traversal via backslash dot-segment prefix escape
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 12.8.1
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 12.8.1.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 18/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 12.8.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
The @fastify/reply-from plugin, which forwards requests from Fastify applications to upstream HTTP servers, is affected. A crafted request using backslash path segments can bypass the plugin's path checks and reach upstream endpoints outside the intended prefix, potentially exposing unauthorized data with limited risk to data integrity.
Read the original description
@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.
What to do
Upgrade to a fixed version: 12.8.1.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- @fastify/reply-from @fastify/reply-from
fixed in 12.8.1
Evidence 2
- Advisory
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-117518
What does this mean?
A crafted request that uses backslash and dot-segment sequences can get past the upstream prefix that the application meant to limit proxying to. That lets an unauthenticated request reach other endpoints on the upstream server. The advisory says the main exposure is confidential data, with limited integrity impact.Source: github.com
Am I affected, and how do I check?
All releases of @fastify/reply-from up to and including 12.8.0 are affected, but only in setups that scope proxying to an upstream prefix and rely on Fastify route guards in front of reply.from(). To check, look at the installed version of @fastify/reply-from in your lockfile or with npm ls @fastify/reply-from, and review whether your reply.from() calls use a prefix scope behind route guards.Source: github.com
What should I do about it?
Upgrade @fastify/reply-from to 12.8.1, which is the listed fixed version.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data