go

echo: the proxy that keeps tunneling after the upgrade is rejected

Echo shipped v4.16.1 and v5.4.1 on October 22. The headline fix is a critical flaw in its Proxy middleware: a rejected WebSocket upgrade left a raw tunnel open, and that tunnel skipped the router, so later requests on the connection went straight to the upstream without hitting route-level auth.

Glenn Fryklund

Glenn Fryklund

— 3 min read
Share
echo: the proxy that keeps tunneling after the upgrade is rejected
A reverse proxy whose tunnel keeps going after the upstream rejects the WebSocket upgrade: the raw path bypasses the router's access controls and pipes requests straight to the upstream. Rendered with AI.

Echo shipped v4.16.1 and v5.4.1 on October 22. The headline fix is a critical flaw in its Proxy middleware, tracked as GHSA-cxf3-9h37-7rr8 and scored CVSS 9.1 by NVD as CVE-2026-118264. A rejected WebSocket upgrade was leaving a raw tunnel open, and that tunnel skipped the router.

How a rejected upgrade becomes a tunnel

Echo's Proxy middleware is the part of the framework that forwards a client's request to a configured upstream. When a client sends a WebSocket upgrade, the middleware has to decide whether to hand the connection over as a raw tunnel. The bug is in the order of that decision. The middleware selected the raw tunnel before it verified that the upstream actually accepted the upgrade.

That ordering is the whole flaw. If the upstream rejected the upgrade with an ordinary keep-alive response, the middleware had already committed the connection to tunnel mode. From that point on, later HTTP requests on the same connection were forwarded straight to the upstream. They never passed through Echo's router, and they never hit the route-specific middleware. If your authentication and authorization live in Echo routes, those requests went through with no check at all.

The precondition set is narrow, which is what makes this a conditional bug rather than a free RCE. You need three things: an accessible proxy route, a cooperating rejected-upgrade response from the upstream, and a target that does not enforce its own authorization.

Who is actually exposed

That third precondition is the one that matters in practice. The vulnerability only lands when the backend trusts the proxy for authorization and does not check the client itself. A backend that enforces its own auth is safe even if the tunnel opens, because it still checks the request. The dangerous setup is the common one where the proxy's route-level middleware is the only gate and the backend assumes the proxy already vetted the caller.

So the exposure is specific. It requires a backend that sits behind Echo's Proxy middleware, leans on the proxy's route-level auth, and rejects WebSocket upgrades with a plain keep-alive response. If your backend does its own authorization, the tunnel is a nuisance, not a bypass.

The same release also ships four other fixes. Two are high-severity resource-exhaustion bugs in the v4 line: BodyDump could capture request and response bodies without bound, and Decompress could expand gzip without bound. A third high-severity item (GHSA-9969-6676-49h5) is a WebSocket proxy that retained connections and handlers after the client disconnected. The v5 line carries two medium items: the X-Real-IP extractor trusted the header over the actual sending peer, and BodyDump discarded BodyLimit overflow errors for unknown-length requests.

What to do

  • Upgrade: v4 to 4.16.1, v5 to 5.4.1. Both were released 2026-10-22.
  • Check your backends: if a backend sits behind Echo's Proxy middleware and relies on the proxy's route-level auth, verify it enforces its own authorization. The tunnel only becomes an auth bypass when the backend does not.
  • Review the secondary fixes: if you run v4 with BodyDump or Decompress on untrusted input, the unbounded capture and expansion are a memory-exhaustion path on their own.

No KEV entry and no in-the-wild exploitation evidence have been published for this flaw as of the October 30 scan, so this is a patch-now item rather than an incident response. The fix is a version bump. The real work is confirming which of your backends would have been bypassed, because that is what turns a patch into an actual defense.

Sources

This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.

Topics:

Read more