Categories: ALERTAS

Zero-day no Cisco ASA derruba firewalls com VPN SSL ativa

A Cisco publicou em 28 de outubro de 2026 uma atualização de segurança para um zero-day no Cisco ASA e no Secure Firewall Threat Defense que atacantes já estão usando para reiniciar remotamente firewalls corporativos. O problema recebeu o identificador CVE-2026-76418 e atinge os softwares Cisco Secure Firewall Adaptive Security Appliance (ASA) e Cisco Secure Firewall Threat Defense (FTD), a base dos appliances de borda usados por empresas, governos e operadoras para publicar acesso remoto por VPN.

O cenário de ataque é direto: um invasor sem credenciais envia uma requisição manipulada ao serviço de VPN SSL de acesso remoto e o equipamento reinicia, interrompendo todo o tráfego que passa por ele. Não há execução de código nem roubo de dados — o efeito é negação de serviço (DoS), mas em um ponto da rede cuja queda normalmente derruba o acesso remoto inteiro da organização.

Segundo o próprio aviso da Cisco, a equipe de resposta a incidentes de produto da empresa, o PSIRT, tomou conhecimento da exploração ativa ao longo de outubro de 2026. A fabricante não divulgou indicadores de comprometimento, não informou quais setores foram atingidos e não atribuiu a atividade a nenhum grupo. É a segunda falha de negação de serviço explorada como zero-day nesses mesmos produtos em menos de três meses.

Contexto: a borda da rede como alvo recorrente

Appliances de VPN e firewall concentram duas características que os tornam atraentes para atacantes: ficam expostos à internet por definição e raramente podem ser reiniciados ou atualizados em horário comercial. Em agosto de 2026 a Cisco já havia corrigido a CVE-2026-20349, outra falha de negação de serviço explorada ativamente nos mesmos ASA e FTD, naquele caso afetando os recursos de VPN IKEv2, VPN SSL e Zero Trust Network Access. Essa vulnerabilidade foi incluída no catálogo de falhas exploradas da agência norte-americana CISA, com prazo de correção para órgãos federais civis em 14 de agosto de 2026.

O histórico é mais longo. Em setembro de 2025 a Cisco corrigiu duas falhas nos mesmos produtos (CVE-2025-20362 e CVE-2025-20333) exploradas contra appliances da série 5500-X com serviços web de VPN habilitados; a CISA respondeu com a Diretiva Emergencial 25-03, de 25 de setembro de 2025, determinando ação imediata das agências federais. A Cisco associou aquela atividade à campanha ArcaneDoor, que desde novembro de 2023 vinha abusando de outros dois zero-days (CVE-2024-20353 e CVE-2024-20359) para invadir redes governamentais.

Esse acúmulo explica por que uma falha “apenas” de disponibilidade merece atenção: o padrão de exploração contra a borda Cisco é persistente, e a indisponibilidade de um concentrador de VPN tem efeito operacional comparável ao de um incidente maior. O Plugged Ninja já tratou do caso mais recente envolvendo outro produto de segurança da fabricante, a falha de nota 9.8 no Cisco Secure Email Gateway.

O que o zero-day no Cisco ASA faz e quem está exposto

A causa técnica declarada pela Cisco são erros de lógica no tratamento da autenticação secundária quando ela está configurada em um tunnel group — o perfil de conexão que define como cada grupo de usuários se autentica na VPN. A requisição maliciosa é processada durante a tentativa de conexão, antes de qualquer autenticação bem-sucedida. A Cisco é explícita nesse ponto: não é necessário concluir um login na VPN para alcançar o trecho de código vulnerável.

Três condições precisam estar presentes ao mesmo tempo para que o equipamento seja vulnerável:

  • o dispositivo roda uma versão afetada de ASA ou FTD;
  • o serviço de login da VPN SSL de acesso remoto está acessível — na prática, a configuração contém a palavra-chave webvpn e a VPN SSL está habilitada em pelo menos uma interface;
  • existe autenticação secundária configurada no escopo de algum tunnel group.

O detalhe que mais costuma passar batido na verificação está na segunda condição combinada com a terceira. Se tunnel-group-list enable estiver configurado, todos os grupos precisam ser checados em busca de secondary-authentication-server-group — inclusive o grupo padrão DefaultWEBVPNGroup e inclusive perfis que não aparecem na lista exibida na página de login. E se a lista de grupos estiver desabilitada, o DefaultWEBVPNGroup ainda precisa ser verificado: desligar a lista não remove a exposição quando o grupo padrão usa autenticação secundária. Em FTD, a verificação equivalente é feita na política de VPN de acesso remoto implantada e na configuração resultante no dispositivo, pelo Secure Firewall Management Center (FMC) ou pelo Secure Firewall Device Manager (FDM).

A Cisco confirmou que os produtos Cloud-delivered Firewall (CDFW), Cloud-delivered Firewall Management Center (cdFMC), Secure Access (CSA) e o software Secure FMC não são afetados.

Dados técnicos e versões corrigidas

O aviso recebeu o identificador cisco-sa-asaftd-tunnel-dos-s6mgkb75, foi publicado em 28 de outubro de 2026 às 19h15 GMT na versão 1.0 e está marcado como final. A classificação é a seguinte:

Identificador CVE-2026-76418
Gravidade Alta — CVSS base 8.6 (atribuído pela Cisco)
Classe CWE-690
Bug ID Cisco CSCwx26625
Impacto Negação de serviço por recarga inesperada do dispositivo
Pré-requisito de ataque Nenhuma autenticação
Solução alternativa Não existe; há mitigação parcial
Descoberta Eric Fernald, durante atendimento de um caso de suporte no TAC da Cisco

As primeiras versões corrigidas do Cisco Secure Firewall ASA são 9.16.4.104 (para 9.16 e anteriores), 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48 e, no ramo 9.24, as versões 9.24.1.27 e 9.24.10.1. No Cisco Secure FTD, as primeiras versões corrigidas são 7.0.11 (para 7.0 e anteriores), 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3 e 10.1.1.

Dois pontos sobre o estado dos registros públicos, verificados na manhã de 29 de outubro de 2026. Primeiro: a CVE-2026-76418 não constava no catálogo de vulnerabilidades exploradas conhecidas (KEV) da CISA na versão 2026.10.28, liberada em 28 de outubro às 19h00 GMT — quinze minutos antes da publicação do aviso da Cisco. Segundo: a página do NVD para o identificador ainda redirecionava para a home do serviço, indicação de que o registro não havia sido publicado. Ou seja, a nota 8.6 disponível no momento é a da própria fabricante, e ainda não havia pontuação independente nem prazo regulatório associado.

Sobre a superfície exposta, o BleepingComputer cita a plataforma de monitoramento Shadowserver, que acompanha mais de 51 mil dispositivos Cisco ASA com VPN SSL acessíveis pela internet. Esse número é o total de dispositivos visíveis, não o de vulneráveis: ele não distingue os que já foram atualizados, os que não usam autenticação secundária e os que são honeypots. Serve como ordem de magnitude da superfície, não como contagem de vítimas.

Impactos, possibilidades e limitações

O impacto prático é operacional. Um ataque bem-sucedido não entrega acesso ao atacante, mas interrompe o túnel de acesso remoto de quem trabalha fora do escritório, as integrações que trafegam por esse appliance e, em muitas arquiteturas, o próprio caminho de administração remota do equipamento. Reinícios repetidos também dificultam a resposta: a janela para aplicar a atualização encurta a cada recarga.

Há limitações que reduzem o alcance. A condição de autenticação secundária configurada em tunnel group não é universal — muitas implantações usam apenas um fator no concentrador e delegam o segundo fator a um provedor de identidade externo por SAML, configuração que não cai na descrição do aviso. Isso provavelmente explica por que a Cisco descreve exploração ativa sem relatar um volume grande de incidentes.

Em contrapartida, existem incertezas relevantes que a fabricante não resolveu e que não devem ser preenchidas por suposição: não há indicadores de comprometimento publicados, não se sabe quando os ataques começaram, quantas organizações foram atingidas, se há relação com as campanhas anteriores contra os mesmos produtos, nem se o mesmo defeito permite algo além de derrubar o dispositivo. A ausência de indicadores é, em si, um problema para quem precisa investigar retroativamente: sem artefatos conhecidos, a detecção depende de sinais genéricos como recargas não programadas.

Recomendações práticas

  • Atualizar para a primeira versão corrigida do ramo em uso, conforme as listas acima. A Cisco trata a mitigação como solução temporária até a atualização.
  • Confirmar a exposição antes de assumir que não se aplica. Verifique se a configuração em execução contém webvpn com VPN SSL habilitada em alguma interface e, em seguida, procure secondary-authentication-server-group em todos os tunnel groups, incluindo o DefaultWEBVPNGroup e perfis fora da lista de login.
  • Aplicar a mitigação só com consciência do custo. Se o DefaultWEBVPNGroup não usa autenticação secundária, a Cisco orienta desabilitar a lista de grupos com no tunnel-group-list enable — os usuários passam a precisar saber o nome exato do perfil de conexão. Se o grupo padrão usa autenticação secundária, a orientação é removê-la com no secondary-authentication-server-group, o que reduz a postura de segurança do acesso remoto. Nenhuma das duas é indolor, e a própria Cisco pede que cada organização avalie o impacto no seu ambiente.
  • Monitorar recargas inesperadas dos appliances e correlacioná-las com tentativas de conexão à VPN SSL. Garanta que o syslog do equipamento esteja sendo coletado fora dele, já que o dispositivo reinicia.
  • Reduzir a exposição do serviço onde for viável, restringindo por origem o acesso ao portal de VPN SSL e revisando se o serviço precisa estar publicado para toda a internet.
  • Consultar o aviso oficial e o Cisco Software Checker para a combinação exata de versão e plataforma, em vez de confiar em listas de terceiros.

Conclusão

A CVE-2026-76418 não é a falha mais grave do ano em termos de capacidade técnica — não há execução de código nem vazamento de dados —, mas é a segunda falha de disponibilidade explorada como zero-day nos firewalls ASA e FTD em menos de três meses, e isso diz mais sobre a borda da rede do que a nota 8.6 isolada. A correção já está disponível, a condição de exposição é verificável em poucos comandos e a mitigação existe, com custo.

Os pontos a acompanhar nos próximos dias são três: a eventual inclusão da falha no catálogo KEV da CISA, que criaria prazo formal para órgãos federais norte-americanos e serve de referência para o setor privado; a publicação do registro no NVD com pontuação independente; e a divulgação de indicadores de comprometimento, hoje ausentes. Enquanto isso não acontece, o critério de decisão é simples e não depende de atribuição: a configuração descrita no aviso existe no seu appliance ou não existe.

Fontes e referências

Ninja

Na cena de cybersecurity a mais de 25 anos, Ninja trabalha como evangelizador de segurança da informação no Brasil. Preocupado com a conscientização de segurança cibernética, a ideia inicial é conseguir expor um pouco para o publico Brasileiro do que acontece no mundo.

Recent Posts

Apple anima avatares 3D em tempo real a 196 FPS no iPhone

O método GHARP, descrito por pesquisadores ligados à Apple e aceito no ACCV 2026, separa…

3 horas ago

Memória de agentes de IA falha e decide por prova social

Pesquisadores publicaram em 27 de outubro de 2026 um benchmark que isola quem detém cada…

3 horas ago

Unit 42 mapeia ameaças ao varejo na alta temporada de vendas

A Unit 42 publicou em 28 de outubro de 2026 um levantamento das ameaças que…

3 horas ago

Estudo: 21 de 42 chatbots de IA vazam conversas a rastreadores

A medição instrumentou o navegador no nível do motor JavaScript para atribuir cada fluxo de…

1 dia ago

Framework Sleep do Google faz LLM consolidar memória offline

Pesquisadores do Google e de Cornell propõem alternar atendimento e uma fase offline em que…

1 dia ago

eMudhra: chaves previsíveis derrubam oito CAs intermediárias

As oito chaves privadas P-384 correspondiam a inteiros abaixo de 256 e podiam ser recalculadas…

1 dia ago