Em 16 de setembro de 2026 a Cisco publicou um alerta de segurança sobre o CVE-2026-76460, que afeta o Identity Services Engine e o ISE Passive Identity Connector. A nota base do CVSS é 10.0, a máxima que a escala atribui. A causa são controles de autenticação insuficientes em um endpoint de API, e o efeito é que um invasor remoto não autenticado pode chegar à interface de gerenciamento enviando uma requisição forjada. A Cisco afirma com todas as letras que seu PSIRT tem conhecimento de exploração ativa e que não há soluções alternativas disponíveis.

O nome técnico diz pouco ao dono de uma empresa. O significado operacional diz tudo: o equipamento afetado não é um servidor de arquivos nem uma impressora de rede. É o appliance ao qual o resto da rede pergunta a identidade de todos que tentam se conectar. Ele decide que este notebook é de um funcionário autorizado, que este celular é de um visitante e vai para a rede de convidados, e que este fornecedor chega a exatamente um sistema. Quando cai a autoridade que toma essa decisão, você não perde um serviço. Perde a base sobre a qual todos os serviços se apoiam.

O que de fato sabemos

Estes fatos vêm do próprio alerta da Cisco e do catálogo Known Exploited Vulnerabilities (vulnerabilidades sabidamente exploradas) da CISA, não de matérias da imprensa:

  • Produtos afetados: Cisco Identity Services Engine e ISE Passive Identity Connector, versões 3.1 a 3.5.
  • Versões corrigidas: 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 e 3.5 Patch 4.
  • Pré-requisito para exploração: nenhum. Um invasor remoto e não autenticado, uma requisição forjada a um endpoint de API, sem conta e sem senha.
  • Status: explorada ativamente segundo o Cisco PSIRT, e incluída no catálogo Known Exploited Vulnerabilities em 16 de setembro de 2026, com prazo de correção em 19 de setembro de 2026 para as agências federais dos Estados Unidos.
  • Solução alternativa: nenhuma. A única mitigação que a Cisco menciona é restringir o acesso ao dispositivo com listas de controle de acesso de infraestrutura até que o patch seja aplicado.

Três expressões dessa lista merecem uma pausa: remoto, não autenticado e sem solução alternativa. Qualquer vulnerabilidade sem uma delas lhe dá espaço para respirar. Esta não lhe dá nada além de aplicar o patch ou isolar.

Por que appliances de identidade são piores do que qualquer outro servidor que você opera

Em uma rede corporativa, os sistemas não são iguais nas consequências de seu comprometimento. Comprometa o servidor de relatórios e você perde relatórios. Comprometa o equipamento que governa identidade e acesso e você não perdeu um dispositivo. Perdeu o significado da palavra permissão em toda a rede.

Quem obtém o controle administrativo de um sistema assim pode, em princípio, alterar as próprias políticas — criar uma identidade autorizada em vez de tentar burlar um controle. Essa é a diferença essencial. O ataque deixa de ser uma intrusão que parece anormal nos logs e passa a ser uma entrada que parece totalmente legítima, porque veio pelo mesmo portão em que você confia. É o caso mais difícil de detectar, porque o monitoramento parte do pressuposto de que tudo o que o sistema de identidade aprova está, por definição, aprovado.

Some a isso o lugar onde esses appliances ficam. Eles estão no meio da rede e se conectam a todos os segmentos, porque a função exige. Então, uma posição no appliance é uma posição em uma estrada aberta para tudo o que está atrás dele. É por isso que sistemas de identidade, acesso e autenticação devem estar no topo da lista de ativos críticos, e não no inventário geral de equipamentos de rede. Tratamos a mesma lógica por outro ângulo no nosso texto sobre o ponto único de falha que ninguém mapeia.

A lição não é sobre a Cisco

É fácil ler isto como notícia sobre um produto de um fabricante. Essa leitura é confortável e inútil. A Cisco lançou a correção e informou claramente o status da exploração, que é o que um fabricante maduro deve fazer. Appliances de segurança de todos os fabricantes têm vulnerabilidades, porque são software, e alertas semelhantes virão.

A pergunta que fica não é se você usa Cisco. É se você sabe quais dispositivos e sistemas autenticam os usuários da sua rede, em que versões estão, quem é responsável por aplicar os patches neles e quanto tempo isso realmente leva. Uma organização que responde a essas quatro perguntas em meia hora trata este alerta como uma tarefa de fim de tarde. Uma organização que não sabe quem administra o appliance precisa de uma semana para chegar à linha de largada, e toda essa semana é exposição.

É exatamente isso que os Controles Essenciais de Cibersegurança emitidos pela Autoridade Nacional de Cibersegurança (NCA) pedem em seu domínio de gestão de vulnerabilidades: avaliação e detecção periódicas de vulnerabilidades, classificação por gravidade, correção conforme essa classificação e o risco associado, assinatura de fontes confiáveis para notícias sobre novas vulnerabilidades e gestão de patches que verifique a integridade e a eficácia das atualizações em um ambiente que não seja de produção antes de aplicá-las. O controle que costuma falhar não é a aplicação de patches em si. É a fonte confiável: uma organização que nunca recebe o alerta do fabricante fica sabendo por uma matéria dias depois, ou nunca fica sabendo.

A visão da Origami

Construímos sistemas de negócio em vez de vender hardware de rede, e ainda assim vemos as consequências disso em todo projeto de integração. Cada vez que conectamos um novo sistema à rede de um cliente surge a mesma pergunta: quem concede as permissões aqui, e onde essa decisão fica registrada. A observação recorrente é que a parte frágil raramente é a nova aplicação ou seu hardening. É a camada que a aplicação presume estar correta e que ninguém inspeciona, porque é antiga e roda em silêncio há anos.

Por isso tratamos qualquer componente no caminho da identidade como parte da segurança da aplicação, e não como algo ao lado dela. Ele é registrado na lista de ativos com nome, versão e responsável. Recebe uma janela de manutenção acordada com antecedência, em vez de uma improvisada no dia em que chega um alerta. E sua interface de gerenciamento fica restrita a uma rede de administração separada, em vez de acessível pela rede geral. São três práticas que não exigem orçamento novo, e são a diferença entre uma empresa que lê o alerta da Cisco e sabe o que fazer, e outra que o lê e começa perguntando quem tem a senha do appliance. Faz parte de como trabalhamos em nossos serviços.

Cinco perguntas para responder nesta semana

Isto não é um programa de segurança completo. São cinco respostas que revelam sua prontidão para o próximo alerta, porque haverá um próximo alerta.

  • Se você usa Cisco ISE ou ISE-PIC: em que versão está, e ela fica entre 3.1 e 3.5? Se sim, as versões corrigidas estão listadas acima, e isto é trabalho urgente, não agendado. Até que o patch seja aplicado, restrinja o acesso ao dispositivo com listas de controle de acesso, como o alerta descreve.
  • Lista de ativos: você tem uma lista escrita dos sistemas de autenticação e acesso que opera, com suas versões? Se a resposta está na cabeça de uma única pessoa, não é uma lista.
  • Fonte de alertas: quem na sua organização está inscrito nos alertas de segurança de cada fabricante que você usa? Essa inscrição é gratuita e leva minutos, e sua ausência costuma ser o motivo do atraso, mais do que qualquer falta de ferramentas.
  • Tempo até o patch: quantas horas ou dias se passaram entre o último alerta crítico que você recebeu e a aplicação do patch? Anote o número. Essa é sua métrica real, e ela é mais honesta do que qualquer plano escrito.
  • Interfaces de gerenciamento: os consoles de administração dos seus dispositivos críticos podem ser acessados de qualquer ponto da rede, ou só de uma rede de gerenciamento definida? Restringir o acesso não elimina a vulnerabilidade, mas transforma um ataque potencialmente aberto a toda a internet em um que primeiro precisa de uma posição interna.

A conclusão prática é objetiva. Vulnerabilidades não são um acidente excepcional que pega sua empresa de surpresa; são um evento recorrente para o qual você pode ensaiar. O que separa uma organização que se mantém de pé de outra que para não é a ausência da falha, mas as horas que passam entre a publicação da correção e a sua aplicação.

Fontes