On this page (7 sections)
Echo, a popular Go web framework, has a critical flaw in its Proxy middleware. A client that asks for a WebSocket upgrade, and whose request the upstream server turns down, may be able to send further requests that never touch the access checks you defined on Echo routes. The bug is tracked as CVE-2026-118264 and fixed in Echo 4.16.1 and 5.4.1, per the GitHub advisory.
Teams that put Echo's Proxy middleware in front of another service should review this now. Applications that do not use that middleware do not meet the conditions the maintainers describe.
What happened
Echo's Proxy middleware forwards requests to an upstream service. In the affected releases, once a client requested a WebSocket upgrade, the middleware committed to a raw tunnel right away. It did not first confirm that the upstream had agreed to the upgrade.
If the upstream replied with a normal HTTP response and left the connection open, the next HTTP requests on that connection were passed straight to the upstream. They skipped Echo's router and any middleware attached to specific routes. Authentication or authorization that existed only at the Echo layer was therefore not applied. The weakness is classified as CWE-444 and CWE-863 in the CVE record data.
The weakness in plain terms
Picture a reception desk that checks every visitor. A visitor requests a private corridor, and the desk opens it before learning whether the room at the far end will accept visitors. The room says no but keeps its door unlocked. The visitor can keep passing requests down the corridor, and the desk no longer inspects them.
That is why the advisory frames this as a bypass of route-level access controls, not as a defect in the upstream.
Who is affected, and what limits the risk
The advisory lists conditions that all need to be true for exploitation:
- An accessible proxy route exists in an Echo application.
- The upstream refuses the upgrade but does not close the connection.
- The targeted resource on the upstream has no authorization of its own.
The maintainers also state that the issue gives no arbitrary-host proxying and does not defeat the upstream's own authentication. A service whose upstream verifies credentials itself is much less exposed. The CVSS v4 metrics on the advisory show a network attack vector, low complexity, no privileges, no user interaction, and high confidentiality and integrity impact on the vulnerable system. The deployment conditions above still narrow who can realistically be hit.
According to the advisory, the raw proxy code exists throughout the v4 and v5 lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0, and source history shows validation of the upstream's upgrade response was already missing in v4.0.0. Treat every version in the affected ranges as vulnerable.
How to check your exposure
Start with the version. This read-only command, run from your Go project root, lists Echo modules in the dependency graph. Look for echo/v4 below 4.16.1 or echo/v5 below 5.4.1.
go list -m all | grep labstack/echoThen find where the Proxy middleware is configured, since the flaw only matters there. This read-only search prints matching lines so you can see which routes forward to an upstream.
grep -rn "middleware.Proxy" --include=*.go .For every proxy route, ask whether the upstream enforces authorization on its own. If protection lives only in your Echo routes, make that service a priority.
What to do now
The patch sends WebSocket upgrades through Go's HTTP reverse proxy and only opens a tunnel after the upstream returns a valid upgrade response, so rejected upgrades stay ordinary HTTP requests. Release notes: v4.16.1 and v5.4.1.
Use the command matching your major version. Each one edits go.mod and go.sum, so run your tests before deploying.
go get github.com/labstack/echo/v4@v4.16.1go get github.com/labstack/echo/v5@v5.4.10 of 6 done
Workarounds if patching must wait
The advisory gives two options: reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. It warns that simply having the upstream return a non-101 response does not stop the vulnerable raw tunnel, so do not count on the upstream refusing the upgrade.
Detection and monitoring
The research describes no indicators of compromise and no known attacks, so there is no confirmed signature to search for. Reasonable hygiene is to review upstream logs for access to protected resources that you cannot tie to an authenticated Echo session, and to alert on anything unexpected after you patch.
If a public endpoint fronts such a service, watch for unexpected changes in what it serves. Webforta monitoring tracks uptime, certificate, DNS and header changes, and our explainer on what a WAF is shows where a firewall layer fits. Neither replaces upgrading the framework.
Timeline and sourcing
- Oct 22, 2026: advisory published in the labstack/echo repository.
- Oct 23, 2026: added to the GitHub Advisory Database and reviewed.
- Oct 28, 2026: advisory last updated; the CVE record lists the same date as publication.
- Reporter credited in the advisory: @Duodum.
For broader habits that limit the damage from an access-control bypass, see our guide to small business website security.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.