← todos os artigos

Envoy corrigiu 13 CVEs de uma vez — e algumas são bypass de RBAC, não só crash

#service-mesh7 min

0

Em 27 de agosto de 2026, o projeto Envoy lançou patch pra quatro branches ativas ao mesmo tempo — v1.39.1, v1.38.4, v1.37.6 e v1.36.10 — cobrindo 13 CVEs. Não é o tipo de release que aparece só como “bug fixes” no changelog: várias das falhas têm impacto direto em autorização e isolamento entre requisições, não apenas estabilidade.

O motivo de importar mesmo se você nunca configurou Envoy diretamente: ele é o data plane por trás de Istio, Envoy Gateway, Contour, Emissary-Ingress, Gloo e vários outros. Se você roda service mesh ou um API gateway construído sobre Envoy, você está exposto ao que está nessas 13 CVEs até atualizar — mesmo que o produto que você usa tenha outro nome na capa.

O que de fato mudou

As 13 CVEs se dividem em dois grupos com implicações bem diferentes.

Grupo 1: falhas que quebram isolamento e autorização

Esse é o grupo que merece atenção prioritária, porque não é “o processo cai” — é “o controle de acesso não funciona como você configurou”:

  • RBAC com safe_regex falhando aberto (GHSA-23xh-2qxr-3xv8, alta severidade): headers HTTP com valores obs-text (bytes fora do padrão ASCII, mas válidos pela RFC) podiam fazer o matcher de regex do RBAC falhar silenciosamente — e quando falha, a política de autorização não bloqueia a requisição. Se seu RBAC depende de regex em headers, isso é bypass de política.
  • Bypass de autenticação via stripping de parâmetro de path (GHSA-m745-gh6x-349x, moderada) e canonicalização de path parameter que ignora regras de segurança (GHSA-77x5-xqjg-hprq, alta): duas variações do mesmo problema de fundo — a normalização de path que o Envoy faz antes de rotear pode divergir da normalização que o backend faz, abrindo brecha pra rotas que deveriam estar protegidas.
  • Poisoning de resposta entre usuários via HTTP upgrade em connection pool compartilhado (GHSA-3vhp-c83q-jqc2, alta): payload enviado antes de um upgrade genérico de HTTP ser aceito podia ser interpretado como requisição HTTP/1 pipeline e vazar pra outra conexão compartilhada no mesmo upstream. Em cenários de multi-tenant isso é vazamento de dados entre requisições de usuários diferentes.
  • XSS armazenado na interface admin (GHSA-pv9h-4fxf-7vrg, alta): /stats?format=html não sanitizava nomes de métricas antes de converter pra HTML. Se algum componente do seu sistema consegue injetar nome de métrica arbitrário (nem sempre trivial, mas possível em setups com labels dinâmicos) e alguém abre o painel admin, o payload executa no navegador de quem está olhando.
  • Null pointer deref no ext_authz com CONNECT (GHSA-87ph-jqwm-pg6r, alta): requisições sem path (o caso do método CONNECT) causavam crash ao chamar o serviço de ext_authz — isso é DoS pontual, mas se seu authz externo é obrigatório pra decisão de acesso, um crash ali também é falha de segurança, não só de disponibilidade.

Grupo 2: crashes e vazamento de memória

O restante são bugs de estabilidade sérios, mas sem o componente de “sua política de segurança não estava fazendo o que você achava”:

  • Use-after-free no HTTP/3 com sequência específica de frames, e outro use-after-free quando o ext_authz via HTTP rejeita uma requisição.
  • Crash no HTTP/2 ao receber trailers sem a flag END_STREAM, e no QUIC ao lidar com endereços IPv6 com escopo em clusters Original Dst.
  • Crash na negociação ALPN quando o upstream escolhido é HTTP/3.
  • Memory leak em SSL_get0_peer_certificates() e um mismatch de allocator que quebrava profiling de heap com tcmalloc.

O detalhe que muda comportamento default

Boa parte dos fixes de segurança vêm atrás de reloadable_features — flags que existem justamente porque a correção muda comportamento observável, não só corrige um bug isolado. Alguns exemplos:

envoy.reloadable_features.strip_path_parameters_per_segment
envoy.reloadable_features.strip_dotdot_segments_with_parameters
envoy.reloadable_features.rbac_respect_ignore_path_parameters
envoy.reloadable_features.re2_use_latin1_mode
envoy.reloadable_features.http2_track_size_of_dropped_host_header
envoy.reloadable_features.sanitize_html_stats_names

Todas vêm habilitadas por padrão a partir dessas versões — ou seja, o fix já está ativo assim que você atualiza, sem passo extra. A flag existe pra permitir reverter caso o novo comportamento quebre algo inesperado no seu tráfego (por exemplo, se você depende de path com parâmetro não normalizado em alguma rota legada). Mas desabilitar qualquer uma dessas flags volta o comportamento vulnerável — trate reversão como último recurso, não como configuração padrão pós-upgrade.

O que fazer

Antes de tudo, descubra qual versão de Envoy você está rodando de fato. Se você usa Envoy direto, é óbvio. Se você usa Istio, Envoy Gateway, Contour ou Emissary, o Envoy embutido tem seu próprio ciclo — a versão do seu control plane não é a versão do Envoy. Confere no changelog do seu projeto qual patch de Envoy ele já empacotou ou vai empacotar.

Prioriza pela combinação que mais te afeta:

  • Se você usa RBAC baseado em regex em headers ou expõe roteamento por path parameter em qualquer camada — os itens de bypass de autorização merecem atualização sem esperar a próxima janela de manutenção.
  • Se a interface admin do Envoy está acessível (mesmo que só internamente) — o XSS armazenado é motivo suficiente pra não adiar.
  • Se você usa ext_authz como decisão obrigatória de acesso — tanto o crash quanto o use-after-free ali têm efeito direto na sua política de autorização ficar de pé.

Vale atualizar? Sim, e não é “quando der”. Esse não é um patch de rotina com uma pilha de CVEs de baixa severidade — tem bypass de RBAC e de autenticação por path no meio, categorias de falha que normalmente saem sozinhas com aviso maior, não empacotadas junto com fixes de crash. O fato de terem saído juntas, pras quatro branches ativas ao mesmo tempo, é sinal de que o time levou a sério a superfície combinada.

Fontes