A Cisco publicou nesta quarta-feira, 16 de setembro, um advisory de severidade crítica para o Identity Services Engine (ISE): uma falha de bypass de autenticação em uma API, rastreada como CVE-2026-76460, com nota CVSS 10.0 e exploração ativa confirmada pelo fabricante e pela CISA. A falha afeta o Cisco ISE e o ISE Passive Identity Connector em qualquer configuração e não tem workaround. Para quem opera a plataforma, a prioridade é aplicar a versão corrigida e investigar todos os nós em busca de acesso não autorizado.
O que a falha permite
Segundo o advisory cisco-sa-ISE-ABP-VNSW7Tn5, a vulnerabilidade decorre de controle de autenticação insuficiente em um endpoint de API. Um atacante remoto e não autenticado pode enviar uma requisição forjada para esse endpoint e contornar a autenticação e tomar o dispositivo afetado, driblando a interface web de gerenciamento. A Cisco classifica o problema como CWE-648, uso incorreto de APIs privilegiadas, e atribuiu nota máxima na escala CVSS 3.1, com vetor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: explorável pela rede, sem pré-requisitos de privilégio e sem qualquer interação do usuário.
O impacto não para na porta de entrada. A própria Cisco alerta que, após a exploração bem-sucedida, o resultado pode ser execução de comandos com privilégios de root no appliance. Com esse nível de acesso, o invasor consegue apagar ou ocultar evidências e indicadores de comprometimento dentro do próprio equipamento, o que transforma qualquer perícia restrita ao dispositivo em análise incompleta. A recomendação do fabricante é cruzar logs de rede e de firewall externos ao ISE para identificar atividade suspeita que o disco comprometido não vai registrar.
Por que o ISE é crítico
O ISE é o ponto onde a rede decide quem entra, com qual perfil e em qual segmento. É a base de políticas de Network Access Control, autenticação 802.1X e atribuição dinâmica de VLANs e de regras de acesso baseadas em identidade. Quando a plataforma que deveria arbitrar o acesso vira o alvo, o atacante não compromete apenas um servidor: compromete o mecanismo que separa usuários, dispositivos e zonas da rede. Práticas de segmentação por identidade, discutidas neste portal na análise sobre microsegmentação por identidade, perdem eficácia se o controlador de identidade cai nas mãos do adversário.
Um ISE comprometido também abre caminho para persistência silenciosa: quem controla o motor de políticas pode alterar regras de autorização, emitir atribuições de acesso vantajosas para contas controladas e criar exceções que dificilmente aparecem em revisões de configuração rotineiras. O dano tende a durar mais do que o próprio incidente, porque as regras adulteradas continuam valendo depois que a porta de entrada foi fechada.
O contexto também pesa. Equipamentos de borda e de gestão da Cisco vêm sendo alvo recorrente de grupos de ransomware e de APTs, como mostrou a cobertura recente dos ataques que exploravam falhas no Cisco FMC. Uma falha sem autenticação prévia, com nota máxima e exploração em curso, em um produto de identidade, reúne exatamente as condições que esses grupos procuram: acesso remoto, alto privilégio e baixa complexidade de exploração.
Versões corrigidas e mitigação
Não existe workaround. A única correção definitiva é atualizar para uma das releases corrigidas listadas pelo fabricante. O release 3.0 do ISE já saiu do período de manutenção de software, e a Cisco orienta migrar para uma versão suportada que contenha o fix. A tabela abaixo resume o caminho de atualização:
| Release do ISE ou ISE-PIC | Primeira versão corrigida |
|---|---|
| 3.1 | 3.1 Patch 12 |
| 3.2 | 3.2 Patch 11 |
| 3.3 | 3.3 Patch 12 |
| 3.4 | 3.4 Patch 7 |
| 3.5 | 3.5 Patch 4 |
Enquanto a janela de manutenção não chega, a Cisco reconhece uma mitigação temporária: usar listas de controle de acesso de infraestrutura, as iACLs, para permitir apenas o tráfego de gerenciamento e de plano de controle necessário aos appliances afetados. Isso reduz a superfície remota, mas não elimina a falha. Restringir o acesso administrativo ao ISE a redes de gestão dedicadas já deveria ser prática padrão; este incidente é o argumento para auditar essa regra agora.
Como investigar os nós
Para confirmar tentativas de exploração, a Cisco orienta revisar o access.log e procurar nomes de usuário suspeitos. Em implantações distribuídas, a verificação precisa cobrir cada nó do cluster. Um exemplo de comando citado pelo fabricante é show logging application ise-kong/access.log | include dummyuser, que procura acessos com um usuário de teste inexistente, padrão típico de sondagem da API. Logs adicionais ficam no support bundle, com debug logs habilitados, no caminho./ise/logs/apigateway/.
- Verificar o access.log de todos os nós, não apenas do nó principal de administração.
- Cruzar logs de rede e de firewall externos ao appliance em busca de uploads inesperados para IPs externos e downloads de endereços suspeitos.
- Tratar qualquer entrada suspeita como comprometimento presumido: a recomendação do fabricante é reformatar o nó afetado e restaurar a partir de backup de configuração.
- Preservar evidências antes de reformatar, pois o invasor com acesso root pode já ter apagado rastros locais.
Prioridades para as próximas horas
A CISA acrescentou a CVE-2026-76460 ao Known Exploited Vulnerabilities Catalog em 16 de setembro, com base em evidências de exploração, e o direcionamento vale para qualquer organização, não apenas para agências federais americanas. Uma ordem de trabalho pragmática:
- P1 — Inventariar ISE e ISE-PIC em todas as versões, incluindo nós secundários e laboratórios esquecidos.
- P1 — Agendar a atualização para a release corrigida correspondente, priorizando appliances com interface acessível além da rede de gestão.
- P1 — Aplicar iACLs de restrição ao plano de gerenciamento enquanto o patch não entra em produção.
- P2 — Executar a busca no access.log em todos os nós e registrar o resultado, mesmo quando negativo.
- P2 — Revisar logs de firewall das últimas semanas para tráfego de saída anômalo originado nos appliances.
A descoberta da falha veio da resolução de um caso de suporte no TAC da Cisco, detalhe que sugere contato real com clientes afetados antes da divulgação. Trate a ausência de alertas internos como hipótese a testar, não como prova de que nada aconteceu.