O relatório chegou no primeiro dia de abril
A 1 de abril de 2026, Adam Kues, da Assetnote, o braço de investigação da Searchlight Cyber, enviou à ServiceNow um relatório que descrevia uma forma de correr código na ServiceNow AI Platform sem quaisquer credenciais. A empresa mexeu-se depressa. No relato que fez da divulgação, a equipa de investigação escreve que a ServiceNow "aplicou mitigações fortes a todas as instâncias na nuvem nas 24 horas seguintes ao nosso relatório" e, nas semanas a seguir, corrigiu as causas de fundo. Todos os clientes com uma instância alojada pela ServiceNow estavam protegidos logo no arranque de abril, sem terem de mexer um dedo nem sequer de saber.
Os clientes que correm cópias próprias não ouviram nada até 13 de julho, quando a ServiceNow publicou o aviso de segurança KB3137947 e lançou atualizações para as instalações de alojamento próprio. A falha está registada como CVE-2026-6875. A ServiceNow, na qualidade de CNA de si própria, atribuiu-lhe uma pontuação CVSS 4.0 de 9,5 em 10. O vetor indica complexidade de ataque elevada, mas nenhum privilégio e nenhuma interação do utilizador, que é exatamente a combinação que torna uma instância acessível pela internet apetecível para quem anda a varrer a rede em larga escala.
Entre as duas datas cabem 103 dias. Para uma empresa de SaaS, isto é uma divulgação coordenada bem conduzida. Para a fatia de clientes que gere a plataforma por conta própria, é um trimestre inteiro na posse de uma falha crítica anterior à autenticação que o fornecedor já tinha fechado no seu próprio parque.
Uma sandbox que aceitou avaliar JavaScript
A vulnerabilidade está na sandbox da ServiceNow AI Platform, a camada de contenção que deveria deixar o código da plataforma correr sem chegar àquilo a que não deve chegar. O ponto de entrada é a API GlideRecord, que aceita avaliação de JavaScript dentro dos filtros de consulta. Uma entrada fornecida pelo utilizador chegava a uma chamada addQuery com o prefixo javascript: e a plataforma avaliava-a.
Uma segunda sandbox devia apanhar precisamente este caso e bloquear funções perigosas. Os investigadores passaram por cima dela com uma cadeia de gadgets montada a partir de Object.clone e Class.create.constructor, que em conjunto dão execução arbitrária de funções durante os script includes. O ponto de entrada demonstrado foi o endpoint /assessment_thanks.do, através do parâmetro sysparm_assessable_type, e nada disto exigia sessão iniciada.
O que isto oferece a um atacante não é um cantinho do produto. A análise da Searchlight descreve leitura de dados a partir das tabelas, criação de contas de administrador e execução de comandos de shell em qualquer proxy MID Server configurado que, como os investigadores fazem notar, costuma estar dentro das redes internas das empresas. O MID Server é a peça que volta a entrar no seu parque para descobrir ativos e correr automatismos. É a ponte, e a ponte fica ao alcance da falha.
Quem ficou de facto com o risco
O instinto habitual nas administrações europeias diz que o alojamento próprio é a opção conservadora. Os dados ficam em ferro da casa, a questão da residência resolve-se numa frase e evita-se pôr nas mãos de um regulador um diagrama incómodo. Em setores regulados por toda a UE, na administração pública, na banca e nos grupos maiores do Mittelstand, é este instinto que explica por que razão uma fatia relevante dos parques ServiceNow não está na nuvem da ServiceNow.
Este aviso de segurança vira a lógica do avesso. Quem escolheu a nuvem do fornecedor ficou protegido nos primeiros dias de abril por uma mitigação que nunca teve de pedir. Quem escolheu correr a plataforma em casa, em nome do controlo, carregou uma execução remota de código não autenticada por abril, maio, junho e meio julho, e só foi avisado quando a correção estava pronta a sair. O controlo sobre a instalação acabou por querer dizer propriedade da janela de exposição.
Nada disto faz da conduta da ServiceNow uma conduta imprópria. Aplicar mitigações a um parque que se opera é simplesmente mais rápido do que fazer chegar correções a um parque que não se opera, e guardar os pormenores do aviso até os clientes poderem agir é prática corrente e não ocultação. A lição para quem opera é mais estreita e mais útil: "o fornecedor corrigiu" e "nós estamos corrigidos" são duas frases diferentes, e desta vez ficaram cem dias entre uma e outra.
As duas afirmações são verdadeiras ao mesmo tempo
No fim de semana de 18 e 19 de julho, o grupo de informação sobre ameaças Defused deu conta de exploração ativa, com as primeiras tentativas observadas na sexta-feira, 17 de julho. O aviso de segurança da ServiceNow, na manhã de segunda-feira, continuava a dizer que a empresa "não tem atualmente conhecimento de exploração contra instâncias ServiceNow". Lidas lado a lado, parece um fornecedor lento a dar o braço a torcer.
A coisa é mais interessante do que isso, e a reconciliação das duas leituras é o ponto desta história. As duas partes estão a medir populações diferentes. A ServiceNow tem telemetria direta sobre o parque que aloja, e esse parque está mitigado desde o início de abril, pelo que ali não há de facto nada a ser explorado. A Defused observa tráfego por toda a internet, que é onde vivem as instâncias de alojamento próprio. A população que o fornecedor não consegue ver é exatamente a população que continua por corrigir.
A frase do fornecedor é portanto rigorosa e, ao mesmo tempo, inútil como dado de risco para si. "Sem exploração confirmada", vindo de um fornecedor de SaaS, é uma afirmação sobre o parque do próprio fornecedor, salvo se disser expressamente outra coisa. Se é o leitor que corre o software, o único estado de exploração que descreve a sua situação é aquele que retira dos seus próprios registos.
O exploit não esperou pela prova de conceito
A Defused foi específica quanto ao que viu. As cargas, relatou, "atingem o mesmo ponto de entrada anterior à autenticação documentado pela @SLCyberSec (/assessment_thanks.do), mas o gadget de fuga da sandbox chega à mesma primitiva de execução de código por uma via diferente da PoC que eles publicaram". Os atacantes não estavam a repetir o exploit dos investigadores. Tinham chegado à mesma primitiva de forma independente, tendo feito o seu próprio trabalho a partir do mesmo ponto de partida.
Esse pormenor desmonta um hábito de calendarização comum em casas com controlo de alterações: tratar o aparecimento de uma prova de conceito pública como o momento em que o relógio arranca e corrigir na janela seguinte a essa. Aqui a capacidade independente apareceu ao lado da análise pública e não depois dela, e o próprio aviso de segurança, a 13 de julho, foi o último alerta fiável que alguém ia receber.
O que verificar antes de terça-feira
Comece pela família de versões, porque os nomes das correções não são intuitivos. As versões corrigidas são Brazil EA e Brazil GA, Australia Patch 2, Zurich Patch 7b ou Zurich Patch 9 e Yokohama Patch 12 Hot Fix 1b ou Yokohama Patch 13. Tudo o que esteja abaixo da linha aplicável está vulnerável, e uma instância de alojamento próprio que não teve janela de manutenção desde 13 de julho não foi corrigida por ninguém em seu nome.
Depois, parta do princípio de que a janela contou. Puxe os registos de acesso a /assessment_thanks.do e olhe em particular para o parâmetro sysparm_assessable_type. Reveja a criação de contas de administrador em todo o período e não apenas nas últimas duas semanas, porque a falha permite a um atacante criar uma. A seguir vá aos MID Servers, procure execução inesperada de processos e lembre-se de que essas máquinas ficam dentro da rede interna e não à frente dela, que é o que transforma uma falha de plataforma num problema de movimento lateral.
Se encontrar alguma coisa, o relógio é regulatório além de técnico. Para as entidades essenciais e importantes na UE, a NIS2 exige um alerta precoce ao CSIRT nacional no prazo de 24 horas a contar do momento em que se toma conhecimento de um incidente significativo e uma notificação mais completa em 72 horas. No Reino Unido, onde a NIS2 não se aplica, o NCSC continua a ser a via de reporte e é o mesmo trabalho de recolha de prova que faz valer a pena apresentar a notificação.
Leia a seguir: Um pedido podia sequestrar o seu site WordPress | Aplicar o patch ao SharePoint já não fecha a porta
