ServiceNow corrige vulnerabilidade explorada em instâncias de clientes

A ServiceNow corrigiu em 5 de junho de 2026 uma vulnerabilidade crítica em seu ambiente em nuvem que permitia acesso não autenticado a dados sensíveis por meio do endpoint de API /api/now/related_list_edit/create. Diferentemente de falhas genéricas, essa vulnerabilidade estava ligada à configuração incorreta requires_authentication=false, o que desabilitava a verificação de identidade mesmo em chamadas HTTP diretas — um cenário raro, mas explorável em instâncias configuradas nas versões 'Australia' ou com personalizações antigas. A empresa detectou atividades anômalas a partir de 2 de junho e recebeu relatos oficiais via programa de bug bounty entre 3 e 4 de junho, após já ter ciência interna desde 7 de abril. Embora ainda sem CVE atribuído, o caso ganhou destaque em fóruns técnicos como o Reddit, onde administradores relataram consultas bem-sucedidas a tabelas de instâncias sem credenciais.

O ServiceNow confirmou que a exploração foi limitada a um subconjunto de clientes e que as atividades observadas provavelmente vieram de pesquisadores éticos — não de atores maliciosos — já que nenhum dado foi retido ou abusado. A correção envolveu uma atualização forçada que redefiniu o endpoint para exigir autenticação obrigatória, alinhando-se às práticas recomendadas de segurança da API. É relevante destacar que essa não é a primeira falha crítica da plataforma: em 2024, foram corrigidos ao menos quatro CVEs graves, incluindo CVE-2024-4879, CVE-2024-5178, CVE-2024-5217 (todos com potencial de RCE não autenticada) e CVE-2024-8923, reforçando um padrão de riscos recorrentes em endpoints de API mal configurados.

Essa vulnerabilidade importa porque expõe uma fragilidade estrutural na forma como plataformas de TI corporativa gerenciam controles de acesso em APIs — especialmente quando configurações padrão são alteradas manualmente por administradores. O fato de um endpoint crítico como /api/now/related_list_edit/create ter sido deixado sem autenticação demonstra o risco de 'configuração errada como vulnerabilidade', categoria cada vez mais comum em ambientes SaaS. Para empresas que dependem do ServiceNow para gerenciar incidentes, mudanças e ativos de TI, o acesso não autorizado a tabelas de instâncias pode comprometer dados de conformidade (LGPD, ISO 27001), logs de auditoria e até credenciais armazenadas em fluxos de trabalho. Além disso, o atraso entre a detecção interna (7 de abril) e a correção (5 de junho) evidencia desafios operacionais em ciclos de resposta a ameaças em nuvem — um ponto crítico para equipes de segurança que buscam reduzir a 'janela de exposição'.

Para desenvolvedores e administradores de ServiceNow, o impacto vai além da aplicação imediata do patch: exige revisão proativa de todos os endpoints de API personalizados com requires_authentication=false, especialmente em instâncias baseadas na versão 'Australia' ou com upgrades parciais. A ServiceNow recomenda auditar logs de acesso a /api/now/ buscando requisições HTTP 200 sem cabeçalhos de autorização (como 'Authorization' ou 'Cookie') e verificar se tokens de suporte ou credenciais de integração foram expostos em workflows antigos. Também é essencial validar se scripts customizados ou integrações de terceiros (ex.: com Power Automate ou Zapier) dependem de endpoints agora restritos — o que pode gerar quebras funcionais pós-atualização. Por fim, o caso reforça a necessidade de usar o ServiceNow Security Operations Workspace e habilitar o API Access Control List (ACL) para todas as rotas expostas, não apenas as padrão.