Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability

Falha de bypass de autenticação (CWE-287) no mecanismo de peering/handshake de controle do Cisco Catalyst SD-WAN Controller, SD-WAN Manager e SD-WAN Validator, que permite a um atacante remoto não autenticado logar como usuário interno privilegiado e, a partir daí, assumir controle administrativo da fábrica SD-WAN inteira. É a segunda falha desse tipo no mesmo subsistema em três meses — a primeira (CVE-2026-20127) foi corrigida em fevereiro de 2026, e esta foi descoberta depois, no mesmo processo de handshake. CVSS 10.0, no catálogo KEV da CISA com exploração confirmada e prazo de correção de 3 dias (raríssimo), além de módulo Metasploit e PoC pública — não é um CVSS inflado, o risco é real e imediato para qualquer instância exposta.

A causa é uma implementação defeituosa da autenticação de peering entre os componentes de controle do SD-WAN (vBond/Validator, vManage/Manager, vSmart/Controller e os vEdges). Esse peering estabelece as sessões de controle DTLS/TLS que formam a fabric SD-WAN — cada nó autentica os outros nós antes de aceitar comandos e trocar configuração. A Cisco descreve o problema genericamente como 'o mecanismo de autenticação de peering em um sistema afetado não está funcionando corretamente', sem detalhar publicamente o defeito criptográfico ou lógico exato — o advisory evita expor o mecanismo interno da falha.

O que se sabe com certeza: um atacante envia requisições manipuladas ('crafted requests') diretamente ao handshake de conexão de controle, sem apresentar credenciais válidas, e consegue autenticar-se como se fosse um peer legítimo. O resultado documentado pela Cisco é login bem-sucedido como conta interna de alto privilégio não-root (o padrão observado em IOCs é a conta 'vmanage-admin' via SSH com autenticação de chave pública).

A gravidade extra vem do que essa conta permite: acesso à interface NETCONF do controlador. NETCONF é o protocolo de gerência de configuração usado internamente pelo SD-WAN para propagar políticas de roteamento, firewall e segmentação para toda a fabric. Com acesso NETCONF, o atacante não fica restrito ao controlador comprometido — ele pode reescrever a configuração de rede de todos os dispositivos gerenciados por aquele Controller/Manager.

O vetor afeta os três componentes de controle (Controller/vSmart, Manager/vManage, Validator/vBond) independentemente da configuração do dispositivo e em todos os modelos de deployment (on-prem, cloud hospedado pela Cisco, e ambiente FedRAMP), segundo o próprio advisory.

O pré-requisito real é conectividade de rede até a porta de peering de controle do componente SD-WAN — não é necessária nenhuma credencial, conta de usuário ou configuração não padrão (PR:N, UI:N no vetor CVSS). Isso torna qualquer Controller, Manager ou Validator com portas de controle expostas à internet um alvo direto, e é exatamente essa exposição que a Cisco cita como fator de risco no próprio advisory ('systems exposed to the internet ... are at risk of exposure to compromise').

A exploração completa consiste em enviar requisições forjadas ao handshake de peering para obter uma sessão autenticada como peer legítimo, o que resulta em login efetivo com a conta interna privilegiada (não-root). A partir dessa conta, o passo seguinte documentado é o uso de NETCONF para alterar a configuração da fabric — ou seja, o comprometimento não fica restrito ao gerenciamento do dispositivo, ele se propaga para a rede que o SD-WAN controla.

Há exploração ativa confirmada e catalogada pela CISA no KEV (adicionado com prazo de correção de apenas 3 dias, o que sinaliza campanha em andamento ou risco avaliado como extremo), além de módulo Metasploit e PoC pública disponíveis, o que baixa a barreira técnica para qualquer atacante replicar o ataque sem depender de pesquisa própria.

A Cisco não oferece nenhum workaround para esta CVE — o advisory (versão 2.0, final) declara explicitamente 'no workarounds available'. A única remediação é atualizar para uma versão corrigida listada na seção 'Fixed Software' do advisory oficial; não temos aqui os números exatos de release corrigida, então consulte diretamente o advisory cisco-sa-sdwan-rpa2-v69WY2SW para a tabela de versões fixas antes de agir.

Antes de atualizar, a Cisco recomenda rodar o comando 'request admin-tech' em cada componente de controle do deployment SD-WAN para preservar evidência forense, já que a atualização por si só não remove um comprometimento pré-existente — se os logs mostrarem indicadores de comprometimento, é necessário abrir caso com o TAC da Cisco (severidade 3, citando o CVE no título) para remediação específica, pois aplicar apenas o patch não reverte um sistema já comprometido.

A CISA emitiu a Emergency Directive 26-03 e orientação suplementar de hunt/hardening especificamente para esta falha, determinando que agências federais avaliem exposição e mitiguem risco seguindo BOD 22-01, incluindo desligar o produto se não houver mitigação aplicável — um sinal da gravidade tratada. Como controle compensatório imediato, se a atualização não puder ocorrer agora, remover a exposição das portas de peering de controle à internet reduz a superfície de ataque, mas não é substituto do patch: a vulnerabilidade está na autenticação do próprio protocolo de peering, não em uma configuração de acesso externo específica.

O advisory lista IOCs concretos: auditar /var/log/auth.log em busca de entradas 'Accepted publickey for vmanage-admin' vindas de IPs desconhecidos ou não autorizados, comparando o IP de origem contra os System IPs cadastrados em WebUI > Devices > System IP no Cisco Catalyst SD-WAN Manager. Também recomenda-se revisar manualmente todos os eventos de peering nos logs de controle (mensagens 'control-connection-state-change'), com foco em eventos de peer-type 'vmanage', validando timestamp contra janelas de manutenção conhecidas, IP público contra inventário de infraestrutura autorizada, peer-system-ip contra a topologia documentada, e correlacionando múltiplos eventos da mesma origem para identificar reconhecimento ou acesso persistente.

A própria Cisco alerta que alguns desses eventos podem ocorrer durante operação normal, então cada achado deve ser avaliado contra a postura de rede usual antes de ser tratado como comprometimento — não há assinatura única e confiável, o processo é de correlação manual, e em caso de suspeita a orientação é abrir caso com severidade 3 no TAC citando o CVE, fornecendo o output de 'request admin-tech'.