Echo · Disclosed

Echo fixes WebSocket bypass of route access controls

Oct 22, 2026 · 1 min read

Rejected WebSocket upgrades could bypass Echo Proxy middleware route-level access controls, exposing protected routes. Update labstack/echo v4 to 4.16.1 and v5 to 5.4.1.

By HIFY Radar newsroom Updated 10/26/2026 01:11 PM Get this every day →← Back to the feed 2 sources

HighVulnerabilityDisclosedPatched

In this article

What happened
Why it matters
What to do
For the technical team
Timeline
Sources

What happened

The Echo web framework for Go fixed a critical flaw in its Proxy middleware. A WebSocket upgrade request rejected by the upstream opened a raw tunnel that skipped Echo's router and route middleware. This could bypass authentication and authorization enforced only at Echo routes.

Why it matters

Applications using Echo's Proxy with access control only at the framework's routes can expose protected upstream resources, with risk of data disclosure and modification. GitHub rates the flaw critical, CVSS 9.1. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and an upstream resource without independent authorization.

What to do

Upgrade labstack/echo v4 to 4.16.1 and v5 to 5.4.1. Until then, reject WebSocket upgrade requests before they reach affected proxy routes or enforce authorization independently at every upstream resource.

For the technical team

Affected: Echo (labstack) Echo Proxy middleware (github.com/labstack/echo) · github.com/labstack/echo/v4 >= 4.0.0, < 4.16.1; github.com/labstack/echo/v5 >= 5.0.0, < 5.4.1. The advisory cites runtime reproductions confirmed on v4.15.0, v4.16.0, v5.0.0 and v5.4.0, and source history shows the missing upgrade-response validation since v4.0.0.
Exploitation: Sources cite no in-the-wild exploitation or public PoC. The GitHub Advisory Database rates it Critical, CVSS v4 9.1: network vector, low complexity, attack requirements present, no privileges or user interaction, high confidentiality and integrity impact on the vulnerable system. Reported by @Duodum.
Fix: Upgrade to github.com/labstack/echo/v4 4.16.1 or /v5 5.4.1 (go get github.com/labstack/echo/v4@v4.16.1 or v5@v5.4.1). The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response; rejected upgrades remain ordinary HTTP requests. Advisory workarounds: reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.
Vector: Echo's Proxy middleware (github.com/labstack/echo). On a client WebSocket upgrade request, the proxy selected a raw tunnel before validating the upstream's response. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection went straight to the same upstream, bypassing Echo's router and route-specific middleware. Conditions: an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource without independent authorization. No arbitrary-host proxying and no bypass of the upstream's own authentication.
More details: Identifier GHSA-cxf3-9h37-7rr8, no CVE cited in the sources. Published Oct 22, 2026 by vishr, updated and GitHub-reviewed Oct 23, 2026. Fix commits: 1855061 (v4) and 3fb0ba7 (v5); v4.16.1 and v5.4.1 releases shipped Oct 22, 2026. v4.16.1 requires Go 1.26 or later for patched golang.org/x dependencies; v5.4.1 keeps Go 1.25 as module minimum. In both versions the proxy now strips incoming Forwarded headers, and WebSocket requests honor the configured proxy transport, response modifier, target path and query like HTTP requests.