Arista EOS Unexpected Tunnel Protocol Decapsulation and Forwarding Bypass

Falha em plataformas específicas do Arista EOS que atuam como ponto de terminação de túnel (VXLAN VTEP, GRE ou ip decap-group): o switch verifica apenas o IP de destino do pacote tunelado, não o tipo de protocolo, e por isso decapsula e reenvia tráfego de protocolos de túnel que nunca foram configurados. Isso importa porque quebra a premissa de que só o protocolo configurado passa pelo endpoint de decapsulação — um atacante pode usar um protocolo de túnel não autorizado para atravessar segmentação de rede que dependia dessa restrição. Está no catálogo KEV da CISA com exploração confirmada, mas o impacto de confidencialidade e disponibilidade é nulo segundo o próprio CVSS do fornecedor (VC:N/VA:N); o risco real é de integridade — bypass de isolamento entre segmentos.

CWE-1023 (Incomplete Comparison with Missing Factors). O código de decapsulação de túnel no EOS identifica o pacote como candidato à decapsulação comparando somente o IP de destino contra o IP de terminação configurado (o VTEP address de uma interface VXLAN, o destination de um túnel GRE, ou o IP de um decap-group). Ele não valida se o protocolo de encapsulamento do pacote recebido corresponde ao protocolo que foi de fato configurado nesse endpoint. Resultado: um switch configurado só para VXLAN aceita e decapsula também GRE e IP-in-IP destinados ao mesmo IP; um switch configurado para GRE decapsula também VXLAN, GUE e IPoIP; e assim por diante, conforme a matriz de combinações publicada pela Arista.

Em vários desses cruzamentos a decapsulação indevida exige configuração adicional presente no switch — por exemplo, decapsular NVGRE via um endpoint VXLAN só funciona se o TNI do pacote NVGRE coincidir com um VNI já configurado, e decapsular GUE requer que exista um mapeamento de porta UDP de destino para payload já definido no decap-group. Ou seja, a falha em si é universal ao mecanismo de decapsulação, mas a superfície de exploração prática varia por combinação de protocolos e pela configuração já presente no dispositivo.

O atacante controla o cabeçalho externo do pacote (protocolo de túnel, portas, em alguns casos o TNI/VNI) e o IP de destino, que precisa coincidir com o IP de decapsulação do switch — informação que normalmente é roteável e, em cenários de data center/backbone, frequentemente alcançável de fora do domínio de confiança original do túnel legítimo. O conteúdo interno (payload após decapsulação) é encaminhado pelo switch como tráfego normal, ignorando qualquer controle que dependesse do protocolo de túnel usado.

Afetação é restrita a hardware/plataforma: 7020R Series, 7280R/R2 Series e 7500R/R2 Series têm exposição completa (todas as combinações da matriz); 7280R3, 7500R3 e 7800R3 têm exposição limitada, restrita aos cenários IP-in-IPv6 e GUEv6 Decap Group. Uma lista extensa de outras séries EOS (710, 720D, 750X, 7050X, 7060X, 7130 com EOS, 7150, 7160, 7170, 7250X, 7260X, 7280E/R4, 7300X, 7500E, 7800R4, 7700R4, entre outras) e produtos como CloudEOS, cEOS-lab, vEOS-lab e toda a linha CloudVision não são afetados.

Pré-requisito indispensável: o dispositivo precisa estar configurado como endpoint de decapsulação de túnel — VXLAN VTEP ativo, interface de túnel GRE up com source/destination definidos, ou um ip decap-group configurado. Um switch EOS sem nenhuma dessas configurações não processa decapsulação alguma e não está exposto, independentemente da versão de software. Isso restringe drasticamente o universo de dispositivos vulneráveis: majoritariamente switches de core/spine em fabrics VXLAN ou roteadores de borda com túneis GRE/GUE ativos, tipicamente em data centers e backbones de provedores — coerente com o fato de o relato ter vindo de pesquisadores associados à Comcast.

O ataque em si não exige autenticação nem acesso privilegiado ao switch: o vetor é tráfego de rede (AV:N, PR:N, UI:N conforme o CVSS4.0), bastando alcançar o IP de decapsulação configurado com um pacote do protocolo de túnel "errado". A complexidade de exploração é baixa (AC:L) na maioria das combinações, mas algumas exigem que o atacante conheça ou acerte parâmetros específicos já configurados no switch alvo (VNI, TNI, porta UDP de GUE), o que eleva a complexidade prática em ambientes onde esses valores não são triviais de adivinhar de fora.

O resultado da exploração é o encaminhamento de tráfego que deveria ter sido descartado, atravessando fronteiras de segmentação que dependiam do tipo de túnel configurado — um efeito de integridade/bypass, não de vazamento direto de dados nem de negação de serviço. A CISA confirma exploração ativa no catálogo KEV (adicionado em 2026-06-09, prazo de correção 2026-06-23), mas não há detalhes públicos sobre campanhas, atores ou objetivo final observado nos exploits reais.

A Arista não publicou, nas informações disponíveis, uma versão de EOS que corrija a falha — o advisory trata o problema via mitigação de configuração, não via patch de versão. A recomendação do fornecedor passou por revisões (a versão 1.3 do advisory atualizou a "Approach 2 - Applying ACL on Decapsulation Switches"), indicando que a mitigação primária é aplicar ACLs nos switches que fazem decapsulação para restringir quais protocolos de túnel podem chegar ao IP de decapsulação — mas o texto completo com os comandos exatos dessa ACL não está disponível nas fontes consultadas, e a própria Arista incluiu uma "nota de cautela" sobre essa abordagem na revisão 1.2, sinalizando que ela tem ressalvas operacionais não detalhadas aqui.

O primeiro passo prático é determinar exposição: verificar com `show interfaces vxlan 1` se há um VTEP ativo, com `show interfaces Tunnel` se há túnel GRE configurado, e com `show ip decap-group` se há decap-groups. Se nenhum desses existir, o dispositivo não processa decapsulação e não está exposto, independente de plataforma ou versão. Se existir, a exposição efetiva depende também da plataforma: 7020R, 7280R/R2 e 7500R/R2 têm superfície completa; 7280R3, 7500R3 e 7800R3 só são afetados nos cenários IP-in-IPv6 e GUEv6.

Não remover a configuração de decapsulação não é opção viável na maioria dos ambientes (é a função do dispositivo), e simplesmente confiar em ACLs de borda genéricas sem alinhar com a orientação específica de decapsulação do fornecedor não fecha a lacuna — a falha está no plano de dados do próprio switch aceitando protocolos não configurados, não em uma ACL ausente na borda da rede. Buscar diretamente o advisory oficial para a seção completa de Mitigation é necessário antes de aplicar qualquer controle compensatório.

A Arista faz referência a uma seção de Indicators of Compromise no advisory, mas o conteúdo completo dela não está disponível nas fontes consultadas para esta página — recomenda-se consultar diretamente a seção IoC do advisory 0137 para os sinais específicos publicados pelo fornecedor. Como indício operacional, vale monitorar contadores de decapsulação e tráfego decapsulado de protocolos não intencionais no switch (por exemplo, tráfego GRE ou IP-in-IP chegando a um IP que só deveria receber VXLAN, ou vice-versa) e revisar logs de encaminhamento por interfaces de túnel para volumes ou padrões de protocolo inesperados no IP de decapsulação configurado.