GHSA-9969-6676-49h5: Go/github.com/labstack/echo/v5 vulnerability

Q: Which deployments are most exposed to this issue?

Deployments with accessible Echo proxy routes that handle WebSocket upgrades are exposed, particularly where upstream servers keep connections open or reject upgrades while using HTTP keep-alive. The practical impact also depends on configured connection deadlines.

Q: What does an attacker need to do to trigger resource retention?

An attacker needs to make repeated connections through an affected proxy route and disconnect while the upstream connection remains open. A rejected WebSocket upgrade response with HTTP keep-alive is one identified trigger.

Q: Is there a workaround if upgrading is not immediately possible?

The available information identifies proxy-route accessibility and configured connection deadlines as factors affecting impact. Restricting access to affected proxy routes and ensuring connection deadlines are configured can reduce exposure, but the provided data does not describe a complete workaround.

Q: How can I determine whether my application is affected?

Check whether it uses Echo v4.15.0 through v4.16.0 or v5.0.0 through v5.4.0 and exposes proxy routes for WebSocket traffic. Resource accumulation after clients disconnect, especially when upstream connections remain open, is consistent with the issue.

Published Oct 23, 2026

Updated

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.

Fix commits: v4, v5.

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.

Affected Software

2 affected componentsFixes available

go/github.com/labstack/echo/v5>=5.0.0<5.4.1

5.4.1

go/github.com/labstack/echo/v4>=4.15.0<4.16.1

4.16.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade go/github.com/labstack/echo/v5 to a version that resolves this vulnerability.
Fixed in 5.4.1
Upgrade
Upgrade go/github.com/labstack/echo/v4 to a version that resolves this vulnerability.
Fixed in 4.16.1
Upgrade
Upgrade labstack/echo to a version that resolves this vulnerability.
Fixed in v4.16.1
Upgrade
Upgrade labstack/echo to a version that resolves this vulnerability.
Fixed in v5.4.1
Configuration
Disable WebSocket proxy routes until upgrading.
Echo Proxy middleware WebSocket proxy routes = disabled
Compensating control
Apply bounded connection lifetimes and resource limits at the frontend and upstream for WebSocket proxying.

Event History

Oct 23, 2026

Advisory Published

via GitHub·08:50 PM

Data Sourced

via GitHub·08:50 PM

DescriptionWeaknessAffected Software

Frequently Asked Questions

Which deployments are most exposed to this issue?

Deployments with accessible Echo proxy routes that handle WebSocket upgrades are exposed, particularly where upstream servers keep connections open or reject upgrades while using HTTP keep-alive. The practical impact also depends on configured connection deadlines.

What does an attacker need to do to trigger resource retention?

An attacker needs to make repeated connections through an affected proxy route and disconnect while the upstream connection remains open. A rejected WebSocket upgrade response with HTTP keep-alive is one identified trigger.

Is there a workaround if upgrading is not immediately possible?

The available information identifies proxy-route accessibility and configured connection deadlines as factors affecting impact. Restricting access to affected proxy routes and ensuring connection deadlines are configured can reduce exposure, but the provided data does not describe a complete workaround.

How can I determine whether my application is affected?

Check whether it uses Echo v4.15.0 through v4.16.0 or v5.0.0 through v5.4.0 and exposes proxy routes for WebSocket traffic. Resource accumulation after clients disconnect, especially when upstream connections remain open, is consistent with the issue.

GHSA-9969-6676-49h5: Go/github.com/labstack/echo/v5 vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are most exposed to this issue?

What does an attacker need to do to trigger resource retention?

Is there a workaround if upgrading is not immediately possible?

How can I determine whether my application is affected?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are most exposed to this issue?

What does an attacker need to do to trigger resource retention?

Is there a workaround if upgrading is not immediately possible?

How can I determine whether my application is affected?