CVE-2026-76418: falha no Cisco ASA e FTD já é explorada
| |

CVE-2026-76418: falha no Cisco ASA e FTD já é explorada

A Cisco confirmou em 28 de outubro de 2026 que uma falha na VPN SSL de acesso remoto do ASA e do FTD está sendo explorada ativamente. A CVE-2026-76418 tem CVSS 8.6, não exige autenticação nem login bem-sucedido na VPN e permite reiniciar o equipamento à força — ou seja, derrubar o firewall remotamente. A CISA incluiu a falha na KEV em 29 de outubro, com prazo até 1º de novembro de 2026 para órgãos federais americanos corrigirem ou mitigarem.

O que é a falha

O problema está na lógica de autenticação secundária quando ela é configurada em um tunnel group da VPN SSL de acesso remoto. Segundo a Cisco, um atacante remoto não autenticado envia uma requisição malformada durante a tentativa de conexão à VPN — não é preciso completar o login, só alcançar o serviço. O resultado é a reinicialização inesperada do dispositivo, interrompendo todo o tráfego que passa por ele enquanto reinicia.

Quem é afetado

Estão expostos o Cisco ASA Software e o Secure Firewall Threat Defense (FTD) quando, ao mesmo tempo:

  • a configuração tem webvpn habilitado em pelo menos uma interface;
  • o serviço de login da VPN SSL de acesso remoto está acessível pela rede;
  • algum tunnel group usa secondary-authentication-server-group — inclusive o grupo padrão DefaultWEBVPNGroup, mesmo que ele não apareça na tela de login.

A Cisco alerta que desativar a lista de tunnel groups (tunnel-group-list) não remove a exposição se o DefaultWEBVPNGroup usar autenticação secundária. Cloud-delivered Firewall, cdFMC, Secure Access e o Secure FMC Software não são afetados.

Como verificar se você está exposto

  1. No ASA/FTD via CLI, rode show running-config tunnel-group e confira cada grupo — incluindo o DefaultWEBVPNGroup — por secondary-authentication-server-group.
  2. No FTD gerenciado por FMC ou FDM, revise a política de RA VPN implantada e a configuração em execução, não só a política salva.
  3. Confirme se o webvpn está habilitado em alguma interface exposta à internet.

O que fazer agora

A Cisco não tem workaround definitivo: a recomendação é atualizar para uma versão corrigida o quanto antes.

Linha ASA Primeira versão corrigida
9.16 e anteriores 9.16.4.104
9.18 9.18.4.96
9.20 9.20.4.50
9.22 9.22.3.200
9.23 9.23.1.48
9.24 9.24.1.27 ou 9.24.10.1
Linha FTD Primeira versão corrigida
7.0 e anteriores 7.0.11
7.2 7.2.13
7.4 7.4.9
7.6 7.6.7
7.7 7.7.14
10.0 10.0.3
10.1 10.1.1

Enquanto o patch não entra em produção, a Cisco descreve duas mitigações temporárias, mutuamente exclusivas:

  1. Se o DefaultWEBVPNGroup não usa autenticação secundária: desative a lista de grupos com no tunnel-group-list enable. Efeito colateral: os usuários precisam saber de cor o nome do connection profile para conectar, já que o menu de seleção desaparece.
  2. Se o DefaultWEBVPNGroup usa autenticação secundária: remova-a com no secondary-authentication-server-group. Isso reduz a postura de segurança da VPN — é uma mitigação temporária, não uma solução.

Perguntas frequentes

Preciso estar logado na VPN para ser atingido?
Não. O atacante só precisa alcançar o serviço de login da VPN SSL; completar a autenticação não é necessário.

O ataque rouba dados ou dá acesso ao atacante?
Não. É uma negação de serviço (DoS): o impacto é reiniciar o equipamento à força, derrubando o tráfego que passa por ele.

Existe prova de conceito pública?
A Cisco não detalhou a exploração nem quem está por trás dela, só confirmou que identificou uso ativo em outubro de 2026.

Qual o prazo da CISA?
Órgãos federais dos EUA têm até 1º de novembro de 2026 para corrigir ou mitigar, conforme a KEV. Para quem não é órgão federal, o prazo não é obrigatório, mas é a referência prática de urgência.

Conclusão

Com exploração ativa confirmada pela própria Cisco e sem workaround permanente, o caminho é verificar a configuração de autenticação secundária em todos os tunnel groups — não só nos visíveis no login — hoje, e agendar a atualização para uma das versões corrigidas o mais rápido possível. A mitigação via CLI resolve a emergência, mas sempre com uma concessão: ou o usuário perde o seletor de perfil, ou a VPN perde a camada extra de autenticação.

Gostou? Compartilhe.

Posts Similares

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *