O ServiceNow confirmou que uma falha de autenticação em sua API permitiu o acesso não autorizado a dados de instâncias corporativas de clientes. A vulnerabilidade foi explorada entre 2 e 3 de junho de 2026 e corrigida no dia 5. A empresa atribui a atividade a pesquisadores, mas não revelou quantos clientes foram afetados nem quais dados foram acessados.

Dados corporativos expostos no ServiceNow

Uma falha de autenticação em um endpoint de API do ServiceNow permitiu que qualquer pessoa acessasse dados sensíveis de múltiplas instâncias corporativas sem nenhum login. A vulnerabilidade foi explorada entre 2 e 3 de junho de 2026 e só recebeu correção oficial no dia 5 do mesmo mês. A empresa confirmou a violação e começou a notificar clientes afetados, mas não revelou quantas instâncias foram comprometidas nem quais dados foram acessados.

O que é o ServiceNow

O ServiceNow é uma das plataformas SaaS mais usadas no mundo corporativo. Empresas de toda a Fortune 500 dependem dele para gerenciar tickets de TI, recursos humanos, inventário de ativos, documentação interna e até incidentes de segurança. Em suma: é o repositório central de operações de milhares de organizações. Quando algo sai errado nessa plataforma, o impacto potencial é enorme.

A falha técnica

O problema residia no endpoint /api/now/related_list_edit/create, um recurso REST configurado com requires_authentication=false. Isso significava que requisições HTTP não autenticadas conseguiam acessar diretamente as tabelas de dados das instâncias dos clientes. As requisições eram processadas como o usuário Guest, contornando os controles de acesso que deveriam proteger informações confidenciais.

A falha afetou principalmente clientes na versão Australia platform release e instâncias mais antigas com determinadas alterações de configuração. Segundo análises independentes da Rescana e da Mallory, o IP suspeito 51.159.98.241 foi identificado realizando queries contra múltiplos tenants durante os dois dias de exploração.

44 dias com falha aberta

O aspecto mais preocupante deste incidente é a linha do tempo. De acordo com a BleepingComputer, o ServiceNow recebeu um relatório confidencial sobre a vulnerabilidade em 22 de abril de 2026. Internamente, a empresa já havia documentado o problema desde 7 de abril. Mesmo assim, a correção só foi aplicada nas instâncias hospedadas em 5 de junho — uma janela de 44 dias em que a falha permaneceu aberta em produção.

Para uma empresa que gerencia dados sensíveis de organizações globais, um gap desse tamanho é inaceitável. A Breached.Company observou que o aviso inicial ficou restrito ao portal de suporte, exigindo login de cliente para ser acessado. Organizações que precisavam avaliar sua exposição não conseguiam sequer ler a divulgação sem já estarem autenticadas na plataforma.

Dados em risco

As tabelas acessíveis via essa API armazenam informações críticas de empresas. Entre os tipos de dados potencialmente expostos:

  • Chamados de suporte de TI e registros de incidentes
  • Dados de funcionários e registros de RH
  • Inventário de ativos e configurações de sistemas
  • Documentação interna e artigos da base de conhecimento
  • Tokens de API e credenciais compartilhadas em fluxos de suporte

O tipo de informação variava conforme o uso de cada organização, mas o ponto central permanece: qualquer estruturação corporativa que dependa do ServiceNow teve parte do seu backend exposto sem barreira de autenticação.

O que o ServiceNow diz

A empresa atribui a atividade suspeita a pesquisadores de segurança e equipes de pesquisa de clientes vinculados a programas de bug bounty. Dois pesquisadores teriam submetido relatórios em 7 de junho e afirmado não ter retido nenhum dado obtido durante os testes.

A narrativa é reconfortante, mas incompleta. A Dark Reading e a TechCrunch apontaram que não é possível confirmar que todas as queries executadas no endpoint vieram exclusivamente de pesquisadores. A ausência de malware ou ferramentas de exploração avançada não descarta a possibilidade de que outros atores tenham descoberto e explorado a mesma falha de forma independente durante a janela de 44 dias.

Histórico recente de falhas

Este não é um incidente isolado no ServiceNow. Em outubro de 2025, a empresa corrigiu o CVE-2025-12420, que tratava de escalonamento de privilégios e impersonação em sua plataforma com IA. Depois, no início de 2026, veio o CVE-2026-0542, envolvendo ameaças de execução remota de código. A diferença desta vez: nos casos anteriores, as correções antecederam a exploração confirmada. Desta vez, os atacantes chegaram primeiro.

O que empresas brasileiras devem fazer

Mesmo que a correção já tenha sido aplicada nas instâncias hospedadas, empresas que utilizam o ServiceNow precisam tomar medidas proativas:

  1. Revisar logs de API — buscar requisições para /api/now/related_list_edit/create vindas de IPs não reconhecidos ou do usuário Guest.
  2. Auditar dados expostos — verificar quais tabelas contêm informações sensíveis que podem ter sido acessadas durante a janela de vulnerabilidade.
  3. Rotacionar credenciais — trocar tokens de API e senhas que foram transitadas em workflows de suporte ou integrações.
  4. Ativar logging completo de API — garantir que qualquer atividade futura em endpoints seja reconstrutível para fins forenses.
  5. Confirmar status com o vendor — contatar o suporte do ServiceNow para verificar se a instância específica da organização faz parte do grupo afetado.

Como detalhamos em artigo recente sobre vazamento de documentos, atrasos na correção e transparência limitada na divulgação são padrões recorrentes em incidentes de grande escala. A responsabilidade de verificar a própria exposição recai sobre cada organização.

Risco sistêmico de APIs

Este incidente evidencia um problema estrutural no ecossistema SaaS. Plataformas que centralizam operações corporativas dependem de milhares de endpoints de API. Quando qualquer um deles opera sem autenticação adequada, o blast radius é determinado pelo volume de dados que a plataforma armazena — não pela complexidade técnica da exploração.

O caso ServiceNow mostra que não é preciso zero-day sofisticado nem malware avançado para causar um vazamento massivo. Basta um parâmetro de configuração mal definido: requires_authentication=false. Ferramentas de gestão de vulnerabilidades como Qualys VMDR e plataformas de segurança cloud como Prisma Cloud podem ajudar a identificar configurações inseguras em APIs antes que sejam descobertas por quem não deveria encontrá-las.

Referências