CVE-2026-15631

HighCVSS 8.7

Published: 18/07/2026(UTC)Updated: 28/07/2026(UTC)Translated: 23/07/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.30%

22th percentile - higher than 22% of all known CVEs

Summary

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.

Risk Assessment

An attacker can bypass proxy restrictions and access internal WebSocket services that should not be exposed, leading to unauthorized access.

Recommendation

Update @fastify/http-proxy to version 11.6.0 or later, which includes a fix for this vulnerability.

Other vulnerabilities in @fastify/http-proxy

CVE-2026-16117Critical
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.

Original NVD description (English source)

Impact: @fastify/http-proxy versions from 9.4.0 up to and including 11.5.0 fail to validate the resolved WebSocket destination path against the configured rewrite prefix. The WebSocket routing path in WebSocketProxy.findUpstream resolves the destination via the WHATWG URL constructor, which collapses dot segments, so a crafted upgrade request with path traversal sequences can escape the rewrite prefix and reach upstream endpoints that were not meant to be exposed by the proxy. This is a variant of CVE-2021-21322 in a code path that never went through the HTTP fix in fastify/reply-from. Exploitation requires a non-normalizing WebSocket client, since browsers and the ws package normalize the request path before sending, but raw HTTP clients or downstream proxies that forward the request target unchanged make the attack reachable in production topologies. Patches: upgrade to @fastify/http-proxy 11.6.0. Workarounds: none.