Resumo para quem decide

A Cisco confirmou exploração ativa de uma falha crítica no Cisco Identity Services Engine (ISE) e no ISE Passive Identity Connector (ISE-PIC). O CVE-2026-76460 tem CVSS 10.0, o score máximo possível. Um atacante sem credenciais e sem qualquer interação do usuário consegue enviar uma requisição forjada a um endpoint de API e obter execução de comando com privilégios de root no dispositivo.

Isso significa controle total sobre a ferramenta que decide quem entra na rede da empresa. Se sua organização usa o Cisco Identity Services Engine para autenticação de rede, controle de acesso 802.1X ou políticas de NAC, esse é motivo para tratar o assunto como incidente de segurança, não como item de backlog de patches.

A Cisco já publicou correção. Não há workaround. A CISA colocou a falha no catálogo de vulnerabilidades exploradas conhecidas (KEV) em 16 de setembro de 2026, com prazo de três dias, já vencido em 19 de setembro, para agências federais americanas corrigirem. Esse prazo curto é o sinal mais claro de que a severidade não é teórica.

Vale lembrar que APIs mal protegidas são hoje um dos vetores mais comuns de comprometimento e vazamento de dados corporativos, como já discutimos em Como APIs vulneráveis provocam vazamento de dados. No caso do ISE, o problema não é “só” uma API, é a API de um sistema que controla acesso à rede inteira.

O que é o CVE-2026-76460 e por que o CVSS é 10.0

O Cisco ISE é a plataforma de controle de acesso à rede (NAC) da Cisco: define quem pode entrar na rede corporativa, com que perfil, e aplica políticas de segmentação. O ISE-PIC é o componente que identifica usuários de forma passiva, sem exigir autenticação ativa.

O CVE-2026-76460 recebeu CWE-648 (controle de autenticação insuficiente) e vetor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Traduzindo os componentes principais:

• AV:N, ataque via rede, não precisa de acesso físico ou local.
• AC:L, baixa complexidade de exploração.
• PR:N, nenhum privilégio necessário, o atacante não precisa de credencial alguma.
• UI:N, nenhuma interação do usuário é necessária.
• C:H/I:H/A:H, impacto total em confidencialidade, integridade e disponibilidade.

Essa combinação é o motivo do score máximo. Não existe um cenário de ataque mais fácil de executar remotamente: nenhuma barreira de autenticação, nenhuma engenharia social necessária.

Como funciona o bypass de autenticação na API

Segundo o advisório da Cisco, a causa raiz é “insuficiente controle de autenticação em um endpoint de API”. Um atacante envia uma requisição forjada diretamente a esse endpoint e contorna a interface web de gerenciamento, que normalmente exigiria login. A Cisco não divulgou o nome, o caminho ou a porta exata do endpoint afetado.

O padrão é conhecido: uma API interna, criada para consumo por outros componentes do sistema, acaba exposta sem validação adequada de quem está chamando. Discutimos esse tipo de falha estrutural com mais profundidade em API Security: O Elo Crítico na Segurança de Microserviços, e o caso do ISE é um exemplo direto de como essa categoria de erro afeta produtos corporativos de peso, não só aplicações web comuns.

Um detalhe relevante: o advisório afirma que a falha afeta os produtos “independentemente da configuração do dispositivo”. Não há combinação de hardening que blinde a instalação sozinha. A única saída é aplicar o patch ou restringir acesso de rede ao dispositivo.

O que os atacantes conseguem fazer após explorar a falha

A Cisco descreve o resultado da exploração bem-sucedida como acesso não autorizado ao dispositivo, com possibilidade de execução de comando com privilégios de root. Root é o nível mais alto de acesso em um sistema baseado em Linux, equivalente a controle administrativo total sobre o sistema operacional subjacente.

Isso é comparável, em gravidade de acesso, a falhas de comprometimento total de plataformas corporativas que já cobrimos, como no caso de vulnerabilidades críticas em sistemas SAP que permitem invasão total de sistemas corporativos. A lógica de risco é a mesma: quando o atacante chega a nível de root ou administrador em um sistema central, ele não está mais limitado à aplicação, está no sistema operacional inteiro.

A Cisco não detalhou o que os atacantes fizeram concretamente após obter esse acesso nos ataques observados. Não há relato de malware específico, técnica de persistência ou dados exfiltrados. O que se sabe é que o nível de acesso obtido é suficiente para isso, e que evidências de exploração podem ser removidas pelo próprio atacante, o que complica a investigação posterior.

Cisco Identity Services Engine: produtos, versões afetadas e como corrigir

Estão afetados o Cisco ISE e o Cisco ISE-PIC, em qualquer configuração. A Cisco já disponibilizou patches:

Quem ainda roda o ISE 3.0 não encontra patch na lista: a Cisco informa que essa versão chegou ao fim da manutenção de software e orienta migrar para uma versão suportada que já traga a correção.

A ação imediata é confirmar a versão instalada e aplicar o patch correspondente. Não há necessidade de aguardar janela de manutenção estendida: dado o CVSS 10.0 e a exploração ativa confirmada, esse patch deveria entrar como prioridade de emergência, fora do ciclo normal de gestão de patches.

Vale registrar que o mesmo lote da Cisco fecha outras falhas graves no ISE, de dois tipos diferentes. Três delas (CVE-2026-20176, CVSS 9.9; CVE-2026-20211 e CVE-2026-20307, CVSS 9.1 cada) permitem executar comandos no sistema operacional do equipamento, mas, segundo o advisório, só funcionam para quem já tem credencial administrativa válida: o risco é real, e é de outra natureza, mais perto de abuso de acesso legítimo do que de invasão direta. O segundo pacote reúne seis falhas no ISE e no ISE-PIC (CVE-2026-76423, com CVSS 10.0, até CVE-2026-76428) que, em conjunto, permitem contornar a autenticação da API REST, executar código remotamente, injetar SQL e explorar entidades externas de XML.

Para todas essas, a Cisco afirma não ter conhecimento de anúncio público nem de uso malicioso. Ainda assim, elas são corrigidas no mesmo pacote de versão: aplicar só o patch do CVE-2026-76460 sem subir para a versão completa recomendada deixa a instalação exposta ao resto do lote.

No total, esse ciclo de divulgação da Cisco trouxe 77 novos CVEs, sendo 41 relacionados ao ISE e 28 ao portfólio Secure Firewall (ASA, FTD, FMC). A recomendação prática é tratar a atualização do ISE como pacote único, não como correção isolada de um único CVE.

Exploração ativa: o que se sabe (e o que ainda não se sabe)

A Cisco confirmou, através do PSIRT (Product Security Incident Response Team), que está “ciente de exploração ativa” do CVE-2026-76460. Isso é uma afirmação direta do fabricante, não uma suspeita de terceiros.

O que a Cisco não divulgou:

• Quem está por trás dos ataques.
• A natureza técnica dos ataques (ferramentas, malware, técnicas específicas).
• Volume de organizações afetadas, setores ou países alvo.
• Quando a exploração ativa começou (só se sabe a data de publicação do advisório, 16 de setembro de 2026).
• Existência de prova de conceito pública.

Essa falta de detalhe é comum em divulgações iniciais de zero-day sob exploração ativa: o fabricante prioriza lançar o patch e as orientações de mitigação antes de detalhar a campanha de ataque, para não fornecer roteiro adicional a outros atacantes.

Vale contexto de comparação: outra falha com CVSS 10.0 em produto corporativo amplamente usado, cobrimos em Falha CVSS 10 no kernel SAP: OVERPASS e S4GET. O padrão se repete: pontuação máxima em sistemas de missão crítica atrai atenção de atacantes rapidamente após a divulgação, independente de quem divulgou primeiro.

A mesma matéria que trouxe essa notícia também menciona que a Cisco reportou exploração ativa de outra falha, o CVE-2026-76461 (CVSS 9.8), no AsyncOS do Cisco Secure Email Gateway, dias antes desta divulgação. Não há advisório detalhado disponível sobre essa falha específica além dessa menção.

Como identificar se sua instalação foi comprometida (IoCs)

A Cisco forneceu um indicador de comprometimento (IoC) concreto: buscar nomes de usuário suspeitos no log de acesso da API. O comando é:

admin# show logging application ise-kong/access.log | include dummyuser

Substitua “dummyuser” pelo nome de usuário suspeito que você está investigando. Em implantações distribuídas, com múltiplos nodes, é preciso repetir essa verificação em cada node individualmente, não apenas no node de administração primário.

Para investigação mais profunda, a Cisco recomenda coletar um support bundle incluindo “debug logs”, usando criptografia de chave compartilhada, e depois descriptografar o pacote para localizar o log completo em:

./ise/logs/apigateway/access.log.<data>.gz

O nome do arquivo traz o carimbo de data da rotação do log, que muda a cada arquivo. Qualquer entrada suspeita nesse log, segundo a Cisco, “pode indicar atividade maliciosa” e deve ser tratada como sinal de alerta em todos os nodes do ambiente.

Limitações da verificação por log e a recomendação de reimageamento

Aqui está o ponto que times de resposta a incidentes precisam entender: a própria Cisco alerta que “evidências podem ser removidas ou ocultadas” pelos atacantes. Ou seja, a ausência de entradas suspeitas no log não é prova de que o sistema não foi comprometido. Um atacante com acesso root, como o que essa falha permite, tem capacidade total de editar ou apagar logs locais antes de sair.

Por isso, a Cisco recomenda cruzar essa verificação com logs externos ao dispositivo afetado: logs de firewall e de rede, verificando especificamente uploads inesperados do dispositivo ISE para IPs externos, ou downloads originados de IPs maliciosos conhecidos. Esses logs, por estarem fora do sistema comprometido, são mais confiáveis como evidência.

Se atividade suspeita for identificada, a orientação da Cisco não é remover artefatos manualmente ou reverter alterações específicas. É reimageamento completo dos nodes afetados, com restauração a partir de um backup de configuração conhecido e limpo. Essa recomendação, por si só, é um indicador de quão pouco a própria Cisco confia na integridade de um sistema após esse tipo de acesso root remoto: não há checklist de limpeza parcial, a resposta padrão é reconstruir o sistema do zero.

Para equipes de segurança, isso muda o cálculo de custo do incidente. Não se trata de aplicar um patch e seguir. Se houver qualquer indício de exploração, o ciclo de resposta inclui isolar o node, coletar evidência externa, reimagear e restaurar configuração, o que consome tempo de equipe e pode gerar indisponibilidade temporária do controle de acesso à rede.

Mitigação, resposta a incidentes e o prazo da CISA

Não existe workaround para o CVE-2026-76460. A única mitigação que a Cisco oferece, além do patch, é o uso de listas de controle de acesso de infraestrutura (iACLs), configuradas para permitir apenas o tráfego de management e control plane estritamente necessário em direção ao dispositivo ISE afetado. Isso reduz a superfície de exposição do endpoint de API vulnerável, mas não elimina o risco: é uma medida de contenção temporária até o patch ser aplicado, não substituto para ele.

A gravidade dessa falha já tem reconhecimento regulatório concreto. A CISA (Cybersecurity and Infrastructure Security Agency, dos Estados Unidos) adicionou o CVE-2026-76460 ao catálogo KEV (Known Exploited Vulnerabilities) em 16 de setembro de 2026, com prazo até 19 de setembro de 2026 para que agências federais americanas (FCEB) apliquem o patch, prazo que já venceu. Três dias é um prazo extremamente curto no padrão da CISA, reservado a falhas de exploração confirmada e alto risco sistêmico.

Empresas brasileiras não estão sob a obrigação legal desse prazo, mas o prazo da CISA funciona como referência prática de urgência: se o próprio governo americano trata isso como emergência de três dias, qualquer organização que dependa do ISE para controle de acesso à rede deveria adotar o mesmo ritmo internamente. O padrão já se repetiu em outros casos de infraestrutura crítica: quando o fabricante confirma exploração ativa, o prazo de tolerância para aplicar patch cai de semanas para dias.

Na prática, o plano de ação recomendado é:

1. Identificar todas as instalações de ISE e ISE-PIC no ambiente, com suas respectivas versões.
2. Aplicar o patch correspondente imediatamente (Patch 12 para 3.1 e 3.3, Patch 11 para 3.2, Patch 7 para 3.4, Patch 4 para 3.5; na 3.0, migrar de versão).
3. Enquanto o patch não é aplicado, restringir acesso à rede do dispositivo via iACL.
4. Rodar a verificação de log em todos os nodes do ambiente, cruzando com logs de firewall e rede.
5. Se houver qualquer indício de comprometimento, isolar o node, reimagear e restaurar a partir de backup de configuração limpo.

Perguntas frequentes

O Cisco Identity Services Engine precisa estar exposto à internet para ser explorado?
O advisório não faz essa distinção. A falha é explorável por rede (AV:N no vetor CVSS), e o risco existe para qualquer atacante que tenha alcance de rede até o endpoint de API vulnerável, seja de fora da organização ou de dentro dela.

Aplicar o patch é suficiente ou preciso verificar comprometimento antes?
As duas coisas são necessárias. Aplicar o patch fecha a porta de entrada, mas não desfaz um comprometimento que já tenha ocorrido antes da correção. Se sua instalação estava exposta antes da aplicação do patch, rode a verificação de log e cruze com logs de firewall, independentemente de já ter corrigido a versão.

A falha afeta o ISE-PIC mesmo sem o módulo completo do ISE instalado?
Sim. A Cisco lista o ISE-PIC como afetado da mesma forma que o ISE completo, independentemente da configuração do dispositivo.

Existe prova de conceito pública para essa falha?
Não há menção de prova de conceito pública nas informações divulgadas até o momento. A Cisco também não revelou detalhes técnicos específicos do endpoint vulnerável, o que reduz o risco de exploração em massa por atores menos sofisticados no curto prazo, mas não elimina o risco de exploração direcionada.

As outras vulnerabilidades divulgadas no mesmo lote também precisam ser corrigidas com a mesma urgência?
A Cisco não relatou exploração ativa nem anúncio público para as demais falhas do lote, incluindo o grupo de seis que traz outro CVSS 10.0 (CVE-2026-76423) e tem contorno de autenticação da API REST entre os efeitos. Ainda assim, como são corrigidas no mesmo pacote de versão, a recomendação prática é aplicar a versão completa recomendada pela Cisco, e não apenas o patch mínimo necessário para o CVE explorado ativamente.

Fonte: Cisco Warns of New Zero-Day ISE Auth Bypass (CVSS 10.0) Exploited in Active Attacks, The Hacker News, com dados do advisório oficial da Cisco.