Vulnerability database

4 results

• Sep 3, 2026@fastify/http-proxy versions before 11.6.2 do not validate proxied HTTP request paths for backslash based dot-segments before forwarding them to the configured CVE-2026-85124 · Other software · @fastify/http-proxy · reported by ce714d77-add3-4f53-aff5-83d477b104bbHigh 7.5

  @fastify/http-proxy versions before 11.6.2 do not validate proxied HTTP request paths for backslash based dot-segments before forwarding them to the configured upstream. The plain HTTP request handler skips the destination validation that the WebSocket path performs, and the underlying reply-from library only rejects forward-slash traversal, so a request containing backslash dot-segments can escape the boundary set by the prefix and rewritePrefix options. An unauthenticated network attacker can use this to reach upstream paths that were meant to stay hidden behind the proxy, resulting in disclosure of internal endpoints. This is a path traversal issue (CWE-22). Users should upgrade to @fastify/http-proxy 11.6.2 or later.

  Product

  @fastify/http-proxy

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordcna.openjsf.orggithub.com

• Jul 18, 2026Impact: @fastify/http-proxy versions up to and including 11.5.0 fail to rewrite the request prefix when the prefix segment is URL-encoded.CVE-2026-16117 · Other software · @fastify/http-proxy · reported by ce714d77-add3-4f53-aff5-83d477b104bbCritical 10

  Impact: @fastify/http-proxy versions up to and including 11.5.0 fail to rewrite the request prefix when the prefix segment is URL-encoded. Fastify's router 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 that encodes one or more characters of the configured prefix therefore matches the route but skips the rewrite, so the raw encoded path is forwarded to the upstream unchanged. The upstream then decodes the path and serves it, letting an attacker reach upstream paths that the proxy was configured to hide via rewritePrefix, including internal or administrative endpoints. Patches: upgrade to @fastify/http-proxy 11.6.0. Workarounds: none.

  Product

  @fastify/http-proxy

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordcna.openjsf.orggithub.com

• Jul 18, 2026Impact: @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 rewriCVE-2026-15631 · Other software · @fastify/http-proxy · reported by ce714d77-add3-4f53-aff5-83d477b104bbHigh 8.7

  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.

  Product

  @fastify/http-proxy

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordcna.openjsf.orggithub.com

• Apr 15, 2026@fastify/reply-from v12.6.1 and earlier and @fastify/http-proxy v11.4.3 and earlier process the client's Connection header after the proxy has added its own heaCVE-2026-33805 · Other software · @fastify/reply-from · reported by ce714d77-add3-4f53-aff5-83d477b104bbCritical 9

  @fastify/reply-from v12.6.1 and earlier and @fastify/http-proxy v11.4.3 and earlier process the client's Connection header after the proxy has added its own headers via rewriteRequestHeaders. This allows attackers to retroactively strip proxy-added headers from upstream requests by listing them in the Connection header value. Any header added by the proxy for routing, access control, or security purposes can be selectively removed by a client. @fastify/http-proxy is also affected as it delegates to @fastify/reply-from. Upgrade to @fastify/reply-from v12.6.2 or @fastify/http-proxy v11.4.4 or later.

  Product

  @fastify/reply-from

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordcna.openjsf.orggithub.com

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.