
Falha no Cisco SD-WAN já dá acesso de administrador — não há atalho

Em 6 de outubro de 2026, a Agência de Cibersegurança de Singapura publicou um alerta sobre a exploração ativa da CVE-2026-76504 no Cisco Catalyst SD-WAN Manager e recomendou atualização imediata. A falha, classificada com 9,8 no CVSS v3.1, permite que um atacante remoto sem credenciais alcance a API com privilégios de administrador.
O desvio ocorre porque um caractere codificado na URI de uma requisição HTTP pode impedir que uma regra de autenticação reconheça o caminho protegido. Para quem opera o Manager, a resposta exige comparar a versão instalada com a primeira versão corrigida do respectivo ramo e examinar os registros de acesso. Restringir o alcance do sistema enquanto a atualização é preparada reduz a exposição, mas não elimina a falha.
Quais versões do Manager precisam de correção
O aviso do Center for Internet Security discrimina os ramos afetados e seus pontos de correção. A comparação deve usar a versão completa do Cisco Catalyst SD-WAN Manager: permanecer no mesmo ramo de uma versão corrigida não significa que a instalação já recebeu a atualização.
- Versões anteriores ao ramo 20.9: migrar para um ramo com versão corrigida.
- Ramo 20.9: atualizar para 20.9.10.1 ou posterior.
- Ramo 20.12: atualizar para 20.12.8.2 ou posterior.
- Ramo 20.15: atualizar para 20.15.6.1 ou posterior.
- Ramo 20.18: atualizar para 20.18.4.1 ou posterior.
- Ramo 26.1: atualizar para 26.1.2.1 ou posterior.
- Ramo 26.2: atualizar para 26.2.1 ou posterior.
Em cada ramo listado, as versões anteriores ao ponto de correção continuam vulneráveis. A configuração do Manager não muda essa condição: desativar um recurso ou ajustar uma opção de autenticação não substitui a conferência da versão. Para instalações anteriores ao ramo 20.9, a saída indicada é migrar para uma versão corrigida, pois a relação de correções não aponta um lançamento seguro dentro desses ramos antigos.
O que procurar nos dois arquivos de log
O aviso técnico da Cisco, atualizado em 2 de outubro, indica dois arquivos para investigar uma possível exploração: /var/log/nms/containers/service-proxy/serviceproxy-access.log e /var/log/nms/vmanage-server.log. O primeiro registra a requisição recebida pelo serviço; o segundo ajuda a relacioná-la ao processamento no Manager. Os exemplos publicados são indicadores para análise, pois ocorrências semelhantes também podem aparecer em operações normais.
No serviceproxy-access.log, o foco são entradas relacionadas a j_security_check provenientes de endereços IP desconhecidos ou não autorizados. Um exemplo de requisição é POST /%6a_security_check: %6a representa a letra “j” codificada na URI. O exemplo mostra resposta HTTP 200, mas esse código isolado não estabelece que houve acesso indevido. Origem, horário e comportamento habitual da instalação precisam ser considerados em conjunto.
No vmanage-server.log, a investigação procura chamadas relacionadas a j_security_check associadas a nomes de usuário que começam por viptela-reserved-. O caminho /%6a_security_check é apenas um exemplo: a exploração pode usar outro caractere codificado. Por isso, pesquisar somente a sequência %6a pode deixar tentativas fora da análise, enquanto tratar toda correspondência como comprometimento pode produzir falsos positivos.
Quando os registros levantarem suspeita, preservar os dados antes da atualização ajuda a manter o contexto necessário à investigação. O procedimento de suporte prevê gerar o arquivo de diagnóstico com request admin-tech no Manager e abrir um caso no Cisco Technical Assistance Center como Severity 3, incluindo CVE-2026-76504 no título. A revisão deve relacionar os dois registros e a origem das requisições, em vez de depender de uma única linha de log.
O que reduz a exposição e o que elimina a falha
Em instalações locais, restringir o acesso ao Manager a redes e hosts confiáveis pode impedir que origens não autorizadas alcancem a interface de gerenciamento. Quando o acesso pela internet for necessário, a filtragem deve permitir apenas hosts conhecidos nas portas e nos protocolos exigidos pela implantação. Essa medida depende da arquitetura de cada rede e pode afetar a operação se bloquear tráfego legítimo; ela reduz o alcance do sistema, mas não corrige o tratamento da URI.
O Live Protect Shield oferece cobertura parcial e temporária para dar tempo ao planejamento da atualização. Sua aplicação também pode impedir o login de usuários legítimos que utilizem codificação de URI. Assim, a decisão de usá-lo precisa considerar tanto a proteção oferecida quanto esse possível efeito sobre o acesso ao Manager.
Há uma distinção entre os ambientes em nuvem: a mitigação por restrição de acesso já está implantada no Cisco Catalyst SD-WAN Cloud Hosted. No Cisco SD-WAN Cloud (Cisco Managed), a vulnerabilidade foi corrigida a partir da versão 20.15.605, sem ação exigida do cliente para essa correção. Essas condições não dispensam a verificação da versão nas instalações locais.
A correção definitiva exige migrar cada instalação vulnerável para uma versão corrigida do ramo aplicável. Até a conclusão da atualização, os controles de acesso e o Live Protect podem limitar a exposição; os registros determinam se, além de corrigir o software, a equipe precisa investigar um possível acesso administrativo.
Leia também:
Artigos relacionados


Cisco corrige duas falhas 9,8 no IOS XR — não existe contorno

WordPress sob ataque: atualizar para 7.1.2 é só o primeiro passo

Falha do SharePoint já é explorada — versões antigas chegaram ao fim

Cisco leva sua fábrica de IA ao rack inteiro — com entrega prevista para outubro

Wellhub libera mais R$ 100 milhões — recebíveis viram garantia de expansão
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.