Fastify http-proxy Flaw (CVE-2026-15631) Lets Attackers Bypass Prefix via WebSocket

A newly disclosed vulnerability in @fastify/http-proxy shows that a well-known security fix from 2021 didn’t fully close the door it was meant to shut it just moved the gap to a different protocol.

Tracked as CVE-2026-15631 and published via GHSA-7hrw-592w-9wh2, the flaw allows attackers to escape the rewritePrefix boundary that the proxy is supposed to enforce, but only when the connection travels over WebSocket. GitHub has rated the issue High severity, and it affects all versions from 9.4.0 through 11.5.0. The fix ships in version 11.6.0.

@fastify/http-proxy is designed to expose a limited subtree of an upstream service. It does this by rewriting incoming request paths from a public-facing prefix to an internal rewritePrefix before forwarding traffic.

Fastify http-proxy Flaw

Over standard HTTP, this boundary holds up because the companion module @fastify/reply-from explicitly rejects .. sequences with a 400 Bad Request response.

WebSocket traffic doesn’t get the same treatment. The proxy builds the upstream target using new URL(dest, upstream), which follows RFC-3986 URL resolution rules including collapsing .. segments.

That’s standard, spec-compliant browser and Node.js behavior for URL parsing, but it’s exactly the kind of normalization that path-traversal defenses need to account for and, in this case, don’t.

This makes the vulnerability a WebSocket-transport variant of CVE-2021-21322, the original “prefix escape” bug found in @fastify/reply-from. That earlier issue was patched in reply-from 4.3.1 for HTTP traffic. This new disclosure confirms the same architectural weakness persisted in the WebSocket handling path years later.

The practical impact centers on unauthorized access to hidden upstream WebSocket endpoints. If an organization runs internal or admin WebSocket APIs behind a proxy specifically to keep them out of public reach, a crafted upgrade request with traversal sequences in the path can reach those endpoints directly.

GitHub’s advisory notes an important scope limitation: because Node.js routes upgrade requests through the upgrade event rather than the normal HTTP handler, the escape only reaches other WebSocket endpoints, not arbitrary HTTP routes. Still, that’s a meaningful attack surface. Any internal service using WebSocket for real-time admin panels, message queues, or monitoring dashboards is a plausible target.

The CVSS vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N reflects no authentication requirement, no user interaction, and a high impact on confidentiality and integrity, tempered by high attack complexity.

Once a connection is established, an attacker gets a full bidirectional session with the hidden endpoint, opening the door to data exfiltration and authorization bypass, effectively an SSRF-style reach into infrastructure the proxy was configured to conceal.

Mitigation

Fastify maintainer Matteo Collina published the fix alongside contributors from the Fastify security team. The remediation is straightforward:

Upgrade @fastify/http-proxy to version 11.6.0 or later immediately.
Audit any proxy configuration relying on rewritePrefix with websocket: true enabled.
Review upstream WebSocket endpoints for sensitive functionality that shouldn’t be internet-facing even indirectly.
Treat this as a reminder that HTTP-focused input validation doesn’t automatically extend to WebSocket upgrade handling.

Organizations running Fastify-based API gateways or reverse proxies should treat this patch as a priority, particularly if their infrastructure exposes any internal WebSocket services through a public-facing prefix.