Em 30 de setembro de 2026, às 4 da tarde no horário de Riad, a Cisco publicou um comunicado de segurança sobre a CVE-2026-76504 no Cisco Catalyst SD-WAN Manager, o sistema que empresas com várias filiais usam para gerenciar toda a sua rede de filiais em uma única tela. A pontuação de severidade é 9.8 de 10, a exploração não exige conta nem senha, a Cisco diz que tomou conhecimento de exploração ativa em setembro, e não há solução alternativa. No mesmo dia, a Autoridade Nacional de Cibersegurança da Arábia Saudita (NCA) emitiu o alerta 2026-7889 com severidade Crítica, pedindo às organizações que revisem o comunicado e apliquem a atualização.

A pergunta principal não é técnica: quem aplica o patch?

Há duas semanas escrevemos sobre uma falha explorada em outro appliance da Cisco, aquele que controla identidade e acesso, e tratamos ali do básico da gestão de vulnerabilidades. Desta vez, a pergunta mais importante não é técnica. Talvez você nem opere a sua rede de filiais: uma operadora de telecomunicações ou uma empresa de TI pode operá-la para você sob um contrato de serviço gerenciado. Nesse caso, quem atualiza o sistema hoje à noite, quem verifica se alguém entrou antes da atualização, e o que diz o seu contrato se nenhuma das duas coisas acontecer?

O que a Cisco realmente publicou

A notícia tem poucas horas, então estes fatos vêm do próprio comunicado da Cisco e do alerta da NCA, não de reportagens da imprensa:

  • Produto: Cisco Catalyst SD-WAN Manager, antes conhecido como vManage. O comunicado afirma que ele é afetado independentemente de como está configurado.
  • Causa: o tratamento inadequado da codificação de URI em requisições HTTP permite que uma requisição forjada contorne uma regra de autenticação destinada a proteger um endpoint específico da API, de modo que o atacante alcança a API com os privilégios do usuário admin.
  • Pré-requisito: nenhum. Um atacante remoto, sem autenticação, e uma pontuação base CVSS de 9.8.
  • Situação: explorada ativamente. O Cisco PSIRT diz que tomou conhecimento da exploração em setembro de 2026, e que a falha foi encontrada durante a resolução de um chamado de suporte do Cisco Technical Assistance Center.
  • Solução alternativa: nenhuma. A correção é atualizar para uma versão corrigida.
  • Alerta local: alerta da NCA 2026-7889, de 30 de setembro de 2026. Ele lista 14 setores-alvo, na prática todos, de comércio e investimento, finanças e economia e saúde a educação, transporte e indústria.

As versões corrigidas, segundo o comunicado:

Linha de versão atualPrimeira versão corrigida
Anterior à 20.9Migrar para uma versão corrigida
20.920.9.10.1
20.1220.12.8.2
20.1520.15.6.1
20.1820.18.4.1
26.126.1.2.1
26.226.2.1

Repare na primeira linha. Quem está em uma versão anterior à 20.9 não tem pela frente uma pequena atualização, mas a migração para outra linha de versões. Isso exige planejamento, e não pode esperar.

Por que este sistema em particular

Uma rede SD-WAN conecta filiais, depósitos e a sede por qualquer conexão disponível, e tudo é gerenciado a partir de um sistema central. É ali que as políticas são escritas: qual tráfego passa por qual link, qual filial pode acessar qual sistema e quais configurações são enviadas ao roteador de cada unidade. Uma mudança no centro chega a todas as filiais. Esse é justamente o objetivo.

A mesma característica é o perigo. Quem alcança a API deste sistema com privilégios de admin não está diante de um único dispositivo, mas do console que gerencia a configuração de toda a rede. O ponto de venda de uma filial, o link com o depósito e o acesso ao sistema contábil fora da sede podem todos passar por uma rede que este sistema controla. Ele pertence ao topo da lista de ativos críticos, por mais distante que pareça da gestão do dia a dia.

Nuvem da Cisco ou seu data center? Isso decide quem age

O comunicado distingue duas formas de operar o sistema, e a diferença é muito prática:

  • Na nuvem da Cisco: o comunicado diz que a falha afeta o SD-WAN Manager independentemente da configuração e descreve dois casos de nuvem. Nos ambientes Cisco Catalyst SD-WAN Cloud Hosted, a Cisco já implantou a mitigação por restrição de acesso, mas mitigação não é correção, então a atualização para uma versão corrigida da tabela acima continua necessária, e você deve perguntar quem a executa. No Cisco SD-WAN Cloud (Cisco Managed), a versão 20.15.605 resolve a falha, a Cisco diz que nenhuma ação do usuário é necessária, e a versão pode ser verificada pela função Ajuda (Help) na interface do serviço. Somente neste último caso a atualização fica a cargo do fornecedor. Ainda assim, cabe a você obter confirmação por escrito e pedir que os logs sejam revisados para o período anterior.
  • Local, nas suas instalações ou no data center do seu provedor: aqui ninguém vai atualizar o sistema por você, a menos que o contrato diga isso. Até a atualização, a mitigação que a Cisco descreve é restringir o acesso ao sistema a partir de redes não seguras, como a internet, e proteger os componentes de controle do SD-WAN atrás de um dispositivo de filtragem, como um firewall.

Portanto, a primeira pergunta não é se você usa Cisco. É onde roda o seu sistema de gerenciamento de rede e de quem é a responsabilidade de atualizá-lo. Se só o provedor sabe a resposta, essa é a primeira lacuna a fechar, e ela não é técnica.

Uma atualização não diz se alguém entrou antes

A Cisco soube da exploração em setembro e publicou a correção no último dia do mês. Em outras palavras, a falha estava sendo explorada antes de existir qualquer atualização para aplicar. Atualizar hoje à noite fecha a porta. Não diz se alguém já passou por ela e deixou para trás uma conta ou uma alteração de configuração.

Por isso a Cisco publicou indicadores para a sua equipe de TI ou o seu provedor procurarem em dois logs específicos do sistema, serviceproxy-access.log e vmanage-server.log:

  • Requisições a j_security_check vindas de endereços IP desconhecidos ou não autorizados.
  • Qualquer caractere codificado em URI no caminho da requisição, como %6a_security_check, em que %6a é a letra j codificada. É assim que o exploit escapa da regra de autenticação. A Cisco destaca que %6a é apenas um exemplo: a codificação de qualquer caractere isolado na requisição pode ser usada, então a equipe deve buscar todas as variantes codificadas de j_security_check, não apenas %6a.
  • Especificamente em vmanage-server.log: requisições a j_security_check de endereços desconhecidos feitas para nomes de usuário que começam com viptela-reserved-. São contas de serviço nativas do sistema, então o nome aparecer no log não é, por si só, sinal de comprometimento. O que importa é a origem desconhecida.

A Cisco também alerta que esses indicadores às vezes podem aparecer durante a operação normal, então precisam ser comparados com a atividade habitual da rede antes de se tirar conclusões.

A mesma lição apareceu nesta semana com duas falhas críticas do Citrix NetScaler que a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) adicionou ao seu catálogo de Vulnerabilidades Conhecidas Exploradas em 27 de setembro. A CISA disse que agentes de ameaça as estão explorando ativamente em todo o mundo, incentivou as organizações a verificar sinais de comprometimento antes de aplicar o patch, sempre que possível, e disse que qualquer organização que suspeite de comprometimento deve preservar as evidências forenses antes de aplicar atualizações, porque as atualizações podem apagar os rastros do que aconteceu. A regra vale aqui também: verifique, guarde uma cópia dos logs e depois atualize, sem deixar que a verificação vire motivo para adiar a atualização por dias.

Se a sua rede é um serviço gerenciado: o que diz o seu contrato?

Os Controles Essenciais de Cibersegurança da NCA, edição de 2024, são obrigatórios para entidades governamentais e suas empresas vinculadas, e para entidades do setor privado que possuem, operam ou hospedam Infraestrutura Nacional Crítica. A NCA incentiva fortemente todas as demais organizações do Reino a utilizá-los. Mesmo que a sua empresa não seja obrigada a segui-los, eles são a referência local mais clara sobre o que deve constar no contrato de qualquer provedor que opere parte da sua tecnologia:

  • Nos contratos com terceiros que, se comprometidos, poderiam afetar seus dados ou serviços, incluindo acordos de nível de serviço: confidencialidade e remoção segura dos seus dados ao fim do serviço, procedimentos de comunicação quando ocorre um incidente de cibersegurança e a obrigação de o terceiro aplicar os seus requisitos e políticas de cibersegurança (controle 4-1-2).
  • Especificamente nos contratos com provedores de terceirização de TI e de serviços gerenciados: uma avaliação de riscos de cibersegurança, com controles de mitigação confirmados, antes da assinatura, e os centros de serviços gerenciados de cibersegurança para monitoramento e operações que usam acesso remoto devem estar localizados inteiramente dentro do Reino (controle 4-1-3).
  • Na gestão de vulnerabilidades: classificar as vulnerabilidades por severidade e corrigi-las de acordo com essa classificação, assinar fontes confiáveis para notícias sobre novas vulnerabilidades e verificar as atualizações em um ambiente que não seja de produção antes de aplicá-las (controle 2-10-3).

Repare no que os controles de gestão de vulnerabilidades não dizem: eles não fixam nenhum prazo para aplicar uma atualização crítica. Esse número tem de estar escrito no seu próprio contrato. Caso contrário, o provedor aplica o patch quando pode, não quando você precisa.

Uma mensagem para enviar ao seu provedor hoje

Você não precisa ser técnico para fazer estas perguntas, nem precisa esperar uma reunião. Peça as respostas por escrito:

  • A nossa rede roda no Cisco Catalyst SD-WAN Manager? E onde ele roda: na nuvem da Cisco, nas nossas instalações ou no seu data center?
  • Em qual versão ele está, e quando será atualizado para a versão corrigida, com data e hora?
  • A interface de gerenciamento está acessível pela internet neste momento? Se sim, vocês restringiram o acesso até a atualização?
  • Vocês verificaram os dois logs indicados pela Cisco em busca dos indicadores publicados e guardaram uma cópia antes de atualizar? O que encontraram?
  • Quem nos avisou deste alerta primeiro: vocês, ou uma notícia que lemos? E qual é o procedimento acordado para nos notificar da próxima vez?

A última pergunta é a mais importante. Se você soube do alerta por um artigo e não pelo seu provedor, o problema é maior do que esta falha.

A visão da Origami

Nós construímos sistemas de negócio. Não vendemos nem operamos equipamentos de rede. Mas todo sistema que construímos para um cliente com várias filiais roda sobre uma rede que não projetamos: o ponto de venda da filial envia dados ao servidor, o depósito atualiza o estoque, a nota fiscal eletrônica sai para a plataforma. E a resposta habitual à pergunta sobre quem aplica o patch na rede é: o provedor cuida de tudo. É uma resposta tranquilizadora, e não é uma resposta.

Para um empresário saudita, lemos esta falha como um lembrete de que a terceirização transfere o trabalho, mas não a responsabilidade. Um serviço gerenciado é a escolha certa para muitas empresas, desde que o contrato contenha três coisas mensuráveis: um prazo definido para aplicar atualizações críticas, aviso por escrito de todo alerta que afete os seus sistemas e um relatório após cada incidente dizendo o que foi verificado e o que foi encontrado. Essas cláusulas não custam nada a um bom provedor, e expõem um provedor fraco antes que uma vulnerabilidade o faça.

Conclusão

  • Se você opera o Cisco Catalyst SD-WAN Manager nas suas instalações ou nas do seu provedor, atualizar para a versão corrigida é trabalho urgente, não agendado, e versões anteriores à 20.9 exigem migração para uma linha corrigida.
  • Até a atualização: bloqueie o acesso ao sistema a partir da internet e coloque os componentes de controle atrás de um firewall, como descreve o comunicado.
  • Verifique os dois logs e guarde uma cópia antes de atualizar, porque a exploração começou antes da publicação da correção.
  • Se a rede é um serviço gerenciado, envie hoje as perguntas acima e, na próxima renovação, inclua no contrato um prazo para atualizações críticas e um procedimento de notificação.

Fontes