Echo: WebSocket proxy can retain connections and handlers after client disconnect
Impact
Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior.
Source excerpt · OSVWhat to do
Affected packages
Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.
| Affected range | Recorded fix |
|---|---|
| From 4.15.0 before 4.16.1Semantic versions | 4.16.1 |
Version evidence: OSV · GHSA-9969-6676-49h5
View original version evidence (0 explicit versions)
| Affected range | Recorded fix |
|---|---|
| From 5.0.0 before 5.4.1Semantic versions | 5.4.1 |
Version evidence: OSV · GHSA-9969-6676-49h5
View original version evidence (0 explicit versions)
Affected products
Vendor version evidence. Product records are separate from automatic dependency matching.
labstack · GitHub_M
echo
2 ranges
labstack · GitHub_M
echo
Compare with this publisher’s ranges. This does not inspect your installation.
affected
>= 4.15.0, < 4.16.1
>= 5.0.0, < 5.4.1
Other versions: unknown
Original source description
Impact
Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior.
Repeated connections can accumulate resources and cause denial of service. The impact depends on the proxy route's accessibility, upstream behavior and configured connection deadlines. This is a medium-severity resource-retention issue; no confidentiality or integrity impact is claimed.
Affected versions and patch
Affected versions are v4.15.0 through v4.16.0 and v5.0.0 through v5.4.0. The regression was introduced by commit e2133320c7, merged in #2852.
Upgrade to v4.16.1 or v5.4.1. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.
Workarounds
Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.
Credits
Reported by @irisitymichaelgrundberg.
Inside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-118262View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Underlying weaknesses
The source’s classification of what caused the vulnerability.
Contributing organizations · 1
Assigning organization
What changed
Follow changesLarge field values are marked as truncated previews. Original source snapshots remain retained.