Echo corrige bypass de controles de acesso via WebSocket

O que aconteceu

O framework web Echo, em Go, corrigiu uma falha crítica no middleware Proxy. Um pedido de upgrade WebSocket rejeitado pelo servidor de destino abria um túnel que ignorava o roteador e o middleware de rota do Echo. Isso permitia contornar autenticação e autorização aplicadas apenas nas rotas do Echo.

Por que importa

Aplicações que usam o Proxy do Echo e controlam acesso só nas rotas do framework podem expor recursos protegidos do servidor interno, com risco de leitura e alteração de dados. O GitHub classifica a falha como crítica, nota 9.1 no CVSS. A exploração exige rota de proxy acessível, servidor de destino que rejeite o upgrade sem fechar a conexão e recurso sem autorização própria no destino.

O que fazer

Atualize labstack/echo v4 para 4.16.1 e v5 para 5.4.1. Enquanto não atualizar, rejeite pedidos de upgrade WebSocket antes das rotas de proxy afetadas ou exija autorização independente em cada recurso do servidor de destino.

Para o time técnico

Afetados

Echo (labstack) Echo Proxy middleware (github.com/labstack/echo) · github.com/labstack/echo/v4 >= 4.0.0, < 4.16.1; github.com/labstack/echo/v5 >= 5.0.0, < 5.4.1. O advisory cita reproduções em runtime confirmadas em v4.15.0, v4.16.0, v5.0.0 e v5.4.0, e o histórico do código mostra a validação ausente desde a v4.0.0.

Exploração

As fontes não citam exploração na natureza nem PoC pública. O GitHub Advisory Database classifica como Critical, CVSS v4 9.1: vetor rede, complexidade baixa, requisitos de ataque presentes, sem privilégios nem interação do usuário, confidencialidade e integridade altas no sistema vulnerável. Reportada por @Duodum.

Correção

Atualizar para github.com/labstack/echo/v4 4.16.1 ou /v5 5.4.1 (go get github.com/labstack/echo/v4@v4.16.1 ou v5@v5.4.1). O patch roteia upgrades WebSocket pelo reverse proxy HTTP do Go e só entra em túnel após resposta válida de upgrade do upstream; upgrades rejeitados seguem como pedidos HTTP comuns. Workarounds do advisory: rejeitar pedidos de upgrade WebSocket antes das rotas de proxy afetadas ou aplicar autorização independente em cada recurso do upstream. Responder não-101 no upstream não evita o túnel vulnerável.

Vetor

Middleware Proxy do Echo (github.com/labstack/echo). Ao receber pedido de upgrade WebSocket, o proxy selecionava túnel raw antes de validar a resposta do upstream. Se o upstream respondia HTTP comum e mantinha a conexão viva, os pedidos HTTP seguintes nessa conexão iam direto ao mesmo upstream, sem passar pelo router nem pelo middleware de rota. Condições: rota de proxy acessível, upstream que rejeita o upgrade sem fechar a conexão e recurso de destino sem autorização independente. Não permite proxy para host arbitrário nem contorna a autenticação do próprio upstream.

Mais detalhes

Identificador GHSA-cxf3-9h37-7rr8, sem CVE citado nas fontes. Publicada em 22/10/2026 por vishr, atualizada e revisada pelo GitHub em 23/10/2026. Commits de correção: 1855061 (v4) e 3fb0ba7 (v5); releases v4.16.1 e v5.4.1 saíram em 22/10/2026. A v4.16.1 exige Go 1.26 ou posterior para as dependências golang.org/x corrigidas; a v5.4.1 mantém Go 1.25 como mínimo. Nas duas versões, o proxy passa a remover cabeçalhos Forwarded de entrada e pedidos WebSocket passam a respeitar transporte, response modifier, caminho e query configurados, como o HTTP.

Linha do tempo

1. 26/10/2026 13:11

   Incidente aberto.

Fontes 2 fontes

• GHSA-cxf3-9h37-7rr8: Rejected WebSocket upgrades can bypass Echo route-level access controls labstack/echo
• GHSA-cxf3-9h37-7rr8 GitHub Advisory Database
• Echo v4.16.1 release labstack/echo
• Echo v5.4.1 release labstack/echo

Ver todas as notícias