GHSA-cxf3-9h37-7rr8: Rejected WebSocket upgrades bypass Echo route access controls

Echo's Proxy middleware versions 4.0.0 through 4.16.0 and 5.0.0 through 5.4.0 contain a vulnerability that lets rejected WebSocket upgrades bypass route-level access controls. When an upstream server rejects a WebSocket upgrade but keeps the connection open, subsequent HTTP requests travel directly to that upstream without passing through Echo's router or route-specific middleware.

Identify proxy routes where rejected upgrades could expose protected resources

Your application is vulnerable when all of these conditions are met:

• You expose at least one Echo proxy route that clients can reach.
• The upstream server behind that proxy can reject a WebSocket upgrade (returns a non-101 response) without closing the connection.
• A protected resource on the upstream lacks its own independent authorization layer.
• Echo route middleware enforces authentication or authorization for that resource.

Check your proxy route configuration for routes that forward to upstreams whose WebSocket handling you control or understand. The vulnerability does not permit arbitrary-host proxying or bypass the upstream's own authentication systems.

Understand how a rejected upgrade bypasses route access controls

Echo's raw proxy implementation switched to a bidirectional tunnel as soon as a client requested a WebSocket upgrade, before checking whether the upstream agreed. When the upstream returned an ordinary HTTP response instead of status 101 Switching Protocols, the tunnel remained open. The next request sent by the client over that connection reached the same upstream without re-entering Echo's router or triggering any route middleware that would normally enforce access controls.

This routing failure affects only the connection that carried the rejected upgrade. It does not grant access to resources on other hosts, nor does it weaken authorization that the upstream enforces independently.

Check affected versions and apply the patch

The advisory confirms the flaw throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0, with runtime reproductions on v4.15.0, v4.16.0, v5.0.0 and v5.4.0, and source-history evidence in v4.0.0.

Upgrade to v4.16.1 or 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.

For Echo v4, run:

go get github.com/labstack/echo/[email protected]

Go 1.26 or later is required to use the patched golang.org/x/ dependencies bundled in v4.16.1. The v4.16.1 release also removes incoming Forwarded headers and changes WebSocket proxy transport, response-modifier, and path settings to match HTTP behavior; review your proxy configuration if you rely on those headers or settings. Build your deployments with a supported, patched Go toolchain.

Use the advisory's workarounds when an immediate update is unavailable

If you cannot upgrade immediately, reject WebSocket upgrade requests before they reach Echo's Proxy middleware, or enforce authorization independently at every upstream resource. Returning a non-101 response from the upstream does not prevent the vulnerable tunnel; the rejection must happen upstream of Echo's proxy route, or the upstream must close the connection after rejecting the upgrade.

These workarounds reduce exposure but do not eliminate the underlying routing flaw.

Upgrade and verify proxy routes

Plan to upgrade as soon as practical. After deployment, confirm that protected routes remain accessible only to authenticated users and that WebSocket connections to the upstream continue to function as expected.

Verification status: Supported by official documentation only under the conditions below; not reproduced in a test environment by IGPROD. Checked 2026-10-23.

Applies to: v4.16.1 or v5.4.1; v4.16.1.

Conditions:

• Exploitation requires an accessible Echo proxy route.
• The upstream must reject the WebSocket upgrade without closing the connection.
• The target upstream resource must lack independent authorization.
• Authentication or authorization must be enforced only at Echo's routes for that control to be bypassed.
• The v4.16.1 release notes require Go 1.26 or later for patched golang.org/x dependencies.

Related advisories

• obsidian-tc: missing Origin and DNS-rebinding checks: a web page reaching a local server.
• ASP.NET Core Kestrel request smuggling (CVE-2026-88092): another web server fix to apply.

Sources:

• github.com/labstack/echo/security/advisories/GHSA-cxf3-9h37-7rr8
• github.com/labstack/echo/releases/tag/v4.16.1