CVE-2026-15631 is a path traversal flaw in @fastify/http-proxy versions 9.4.0 up to and including 11.5.0, rated 8.7 (high). A WebSocket client can escape the configured rewrite prefix and reach upstream WebSocket paths the proxy was meant to hide. Upgrade to 11.6.0, the version the advisory names as patched.
What's affected
- Package:
@fastify/http-proxyon npm. - Affected: 9.4.0 up to and including 11.5.0.
- Fixed: 11.6.0.
- Condition: the advisory describes the WebSocket routing path, so the exposure applies where WebSocket proxying is enabled. HTTP routing already rejects dot segments through
@fastify/reply-from. - Severity: 8.7 in the record, CWE-22. It is not on the CISA Known Exploited Vulnerabilities list.
The advisory calls this a WebSocket variant of an older prefix escape, CVE-2021-21322, which was fixed for HTTP traffic. The HTTP path was protected. The WebSocket path built its target differently and missed the same check.
How to check if you're exposed
Find every copy of the package, including ones pulled in by other packages:
npm ls @fastify/http-proxy
Run it in each service that might sit at the edge of your network, and in monorepos run it per workspace. A result at 9.4.0 through 11.5.0 is in range. A result of 11.6.0 or later is not.
Then search your source for the proxy registration and look at whether WebSocket support is turned on:
grep -rn "websocket" --include=*.js --include=*.ts .
If you proxy only plain HTTP, the advisory's described path does not apply to you, though upgrading is still the clean answer. If WebSocket proxying is on, list which upstream and which rewrite prefix each registration uses, because that tells you what a client could reach if the prefix were bypassed.
What to do now
- Upgrade
@fastify/http-proxyto 11.6.0 or later in every service that uses it, then commit the lockfile change. - Redeploy the services and confirm the running version with
npm lsinside the built image, not just on a developer machine. - List the upstream WebSocket endpoints behind each proxy. Anything internal or administrative should also require its own authentication, so the proxy prefix is not the only barrier.
- Check proxy and upstream logs for unusual WebSocket upgrade requests to paths outside the intended prefix, covering the period the vulnerable version was deployed.
- Add the package to your dependency monitoring so the next Fastify advisory reaches you the day it is published.
Why it matters
The weakness class is CWE-22, improper limitation of a pathname to a restricted directory. Here the "directory" is the part of the upstream that the proxy is allowed to expose. The proxy rewrites a public prefix to an internal prefix and relies on that rewrite as a boundary. For WebSocket traffic, the destination was resolved with the standard URL parser, which collapses dot segments in the path. A request that contained them could therefore land outside the prefix.
The advisory is specific about the limit of the damage. The escape delivers a WebSocket upgrade, so it reaches WebSocket endpoints on the upstream. A path that only speaks plain HTTP does not complete the handshake. That still matters: internal or administrative WebSocket APIs, and other services on the same upstream, are exactly what a prefix is often used to hide. The advisory describes authorization bypass and SSRF style reach, with data exposure possible.
The bigger lesson is the one in the advisory title, which calls it a variant of an earlier bug. When a fix closes one transport, check the others. The same logic applies to your own code. If you enforce a boundary in one request path, find the other paths that reach the same resource and test them too.
A secondary lesson is about trust in a prefix. A rewrite rule is a routing convenience, not an access control. Anything that should not be reachable by every client needs authentication at the upstream itself.
Try it yourself
Whether this bug matters to you depends on whether your proxy has WebSocket support switched on. This demo shows how reachability analysis separates installed from actually used.
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I only proxy HTTP?
The advisory describes the problem in the WebSocket routing path. HTTP requests were already checked by the reply-from plugin. Still, upgrade, since it is a single version bump and removes the question.
Is there a workaround if I cannot upgrade yet?
The advisory fetched for this post lists the upgrade to 11.6.0 as the remediation and does not describe a workaround. Disabling WebSocket proxying is a decision for your own team, not something the advisory states.
Sources
Last reviewed: 19 October 2026.
