<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>VulnFeed.org: labstack echo</title><link>https://vulnfeed.org/</link><description>Every disclosure, as it lands. Critical-only feed available.</description><language>en</language><atom:link href="https://vulnfeed.org/feed/product/labstack-echo.xml" rel="self" type="application/rss+xml"/><item><title>CVE-2026-118650: Echo: middleware.Static: `%2F`-encoded path bypasses route/group middleware guarding a statically-served path</title><link>https://vulnfeed.org/cve/CVE-2026-118650/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-118650/</guid><pubDate>Wed, 28 Oct 2026 19:25:02 +0000</pubDate><description>Echo is a Go web framework. Prior to 4.16.0 and 5.4.0, a globally mounted middleware.Static instance can interpret an encoded request path differently from Echo&apos;s router because the router matches the still-encoded path while the static handler uses the decoded URL.Path. The advisory demonstrates an encoded slash resolving to a file under the static root through the global static middleware, but the source is internally inconsistent about whether a route or group guard protects the corresponding literal path in that global-mount configuration. This issue is fixed in 4.16.0 and 5.4.0.</description></item><item><title>CVE-2026-118264: Echo: Rejected WebSocket upgrades can bypass Echo route-level access controls</title><link>https://vulnfeed.org/cve/CVE-2026-118264/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-118264/</guid><pubDate>Wed, 28 Oct 2026 19:17:31 +0000</pubDate><description>Echo is a Go web framework. From 4.0.0 until 4.16.1 and 5.4.1, Echo&apos;s Proxy middleware selects a raw tunnel from a client WebSocket upgrade request before verifying that the configured upstream accepted the upgrade. If the upstream rejects the upgrade with an ordinary keep-alive response, later HTTP requests on the connection are sent directly to that upstream without passing through Echo&apos;s router or route-specific middleware. This can bypass authentication or authorization enforced only by Echo routes, but requires an accessible proxy route, a cooperating rejected-upgrade response, and a target without independent upstream authorization. This issue is fixed in 4.16.1 and 5.4.1.</description></item><item><title>CVE-2026-118260: Echo: BodyDump captures request and response bodies without size limits in v4</title><link>https://vulnfeed.org/cve/CVE-2026-118260/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-118260/</guid><pubDate>Wed, 28 Oct 2026 19:17:30 +0000</pubDate><description>Echo is a Go web framework. From 4.0.0 until 4.16.1, Echo v4&apos;s opt-in BodyDump middleware reads complete request bodies into memory before handlers run and retains complete response bodies for the dump callback without capture limits. An unauthenticated client that can reach a route using BodyDump can submit large bodies or influence large responses, causing repeated or concurrent allocations that exhaust process memory. BodyDump is not enabled by default, and external request limits may reduce request-side exposure but do not bound response capture. This issue is fixed in 4.16.1.</description></item><item><title>CVE-2026-118262: Echo: WebSocket proxy can retain connections and handlers after client disconnect</title><link>https://vulnfeed.org/cve/CVE-2026-118262/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-118262/</guid><pubDate>Wed, 28 Oct 2026 19:17:30 +0000</pubDate><description>Echo is a Go web framework. From 4.15.0 until 4.16.1 and 5.4.1, Echo&apos;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.</description></item></channel></rss>
