Echo: WebSocket proxy can retain connections and handlers after client disconnect
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 4.16.1, 5.4.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Echo Go web framework's Proxy middleware, used for WebSocket proxying, is affected. When a client disconnects while the upstream server keeps its connection open, the proxy can hold on to connections and goroutines, so repeated connections may build up and lead to denial of service.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Echo is a Go web framework. From 4.15.0 until 4.16.1 and 5.4.1, Echo's Proxy middleware can retain a handler, copy goroutines, and network connections after a WebSocket client disconnects when the upstream keeps its connection open. The raw proxy waits for both copy directions without reliably closing the peer connection when one direction ends, including when a rejected upgrade response uses HTTP keep-alive. Repeated connections can accumulate resources and cause denial of service, depending on proxy-route accessibility, upstream behavior, and connection deadlines. This issue is fixed in 4.16.1 and 5.4.1.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- labstack echo
From 4.15.0 · fixed in 4.16.1; From 5.0.0 · fixed in 5.4.1
- github.com/labstack/echo/v4Go
From 4.15.0 · fixed in 4.16.1
- github.com/labstack/echo/v5Go
From 5.0.0 · fixed in 5.4.1