Jelly Template Injection Vulnerability in ServiceNow UI Macros

Falha de Jelly Template Injection nos UI Macros do ServiceNow Now Platform que permite a um atacante não autenticado executar código remotamente no contexto da instância. É crítica de fato: está no catálogo KEV da CISA com exploração confirmada em ambiente real, tem PoC pública e template Nuclei, e o vetor não exige nenhuma pré-condição de autenticação — qualquer instância exposta e não corrigida é alvo direto.

Jelly é o motor de template baseado em XML (Apache Commons Jelly) que o Now Platform usa para renderizar UI Macros — componentes de interface reutilizados em páginas do sistema, incluindo algumas acessíveis sem login. A falha é uma validação de entrada insuficiente (CWE-1287, conforme classificado pela CISA no KEV) em que dados fornecidos pelo usuário, esperados como texto simples, acabam sendo interpretados pelo parser Jelly como diretivas/tags do próprio template.

O efeito é equivalente a um Server-Side Template Injection: em vez de o valor de entrada aparecer apenas renderizado na página, ele é avaliado como código do template, que por sua vez pode invocar objetos e scripts Java/Rhino do lado do servidor. Como determinados UI Macros são carregados em fluxos pré-autenticação (páginas de login, recuperação de senha e afins), o ponto de injeção fica alcançável sem qualquer credencial.

O fornecedor não publicou o trecho de código exato nem o nome do macro vulnerável nos artigos de suporte disponíveis publicamente (KB1644293 e KB1645154 exigem login no portal ServiceNow para o conteúdo completo), então não há confirmação pública detalhada de qual macro específico carrega a entrada não sanitizada — apenas a confirmação, pelo fornecedor e pela CISA, de que a classe de falha é injeção de template Jelly em UI Macros.

O vetor é uma requisição HTTP para um endpoint que renderiza um UI Macro afetado, com um parâmetro controlado pelo atacante sendo interpretado pelo mecanismo Jelly em vez de tratado como dado literal. Não há necessidade de autenticação, interação do usuário, nem configuração não padrão — isso é coerente com o vetor CVSS AV:N/AC:L/PR:N/UI:N reportado. A complexidade de exploração é baixa: existe PoC pública e template Nuclei, o que reduz drasticamente a barreira técnica e favorece varredura em massa contra instâncias expostas à internet.

A CISA adicionou a falha ao catálogo KEV em 29/07/2024 com prazo de correção em 19/08/2024 para agências federais dos EUA, confirmando exploração ativa observada, não apenas risco teórico. Reportagens da época (ex.: Dark Reading) descreveram campanhas de exploração ativa contra instâncias ServiceNow logo após a divulgação, reforçando a urgência do patch.

O resultado final da exploração é execução de código no contexto do processo do Now Platform, o que em uma instância ServiceNow tipicamente expõe acesso a dados de tabelas internas (tickets, credenciais armazenadas em integrações, configurações), e potencialmente movimento lateral dependendo de como a instância se integra com sistemas internos da organização.

A correção é aplicar os patches e hotfixes de segurança listados pelo fornecedor nos artigos KB1644293 e KB1645154 do portal de suporte ServiceNow, específicos para a família de release da instância (Vancouver e Washington DC, segundo a descrição oficial do fornecedor; a CISA também lista Utah — há divergência entre as duas fontes quanto ao alcance exato das versões afetadas, o que deve ser verificado diretamente nos KBs para a versão/patch da instância). Os números exatos de build/patch não estão disponíveis fora do portal autenticado de suporte ServiceNow nas fontes consultadas, então não é possível listar aqui uma versão-corrigida numérica confiável — o caminho correto é abrir os KBs citados com uma conta de suporte válida e confirmar o hotfix aplicável à sua release específica.

ServiceNow aplicou a correção automaticamente em instâncias hospedadas por eles; instâncias self-hosted e de parceiros dependem de aplicação manual do patch. Isso significa que, mesmo tendo sido divulgada há tempo, instâncias geridas por terceiros ou com ciclos de patch mais lentos continuam expostas se ninguém aplicar o hotfix manualmente.

Não há mitigação equivalente a patch via WAF confirmada pelo fornecedor — filtrar por assinaturas de Jelly em WAF pode reduzir ruído de exploração automatizada, mas não elimina a causa raiz, que está na validação de entrada do próprio código de renderização do UI Macro. Restringir acesso não autenticado à instância na borda de rede reduz superfície, mas não é substituto do patch quando páginas pré-auth legítimas (login, etc.) precisam continuar acessíveis publicamente.

Procure por requisições HTTP anômalas direcionadas a endpoints que renderizam UI Macros, especialmente em fluxos acessíveis sem autenticação (login, redefinição de senha e páginas públicas do portal), contendo parâmetros com sintaxe típica de template Jelly (tags no estilo XML customizado, expressões com chaves ou colchetes fora do padrão esperado para o campo). Nos logs de aplicação do Now Platform, eventos de erro ou execução de script vinculados a `sys_ui_macro` fora do fluxo normal de renderização são um indício. Como há template Nuclei público, o mesmo padrão de assinatura pode ser usado defensivamente para testar a própria instância — mas na ausência de logging detalhado habilitado previamente, não há garantia de sinal retroativo confiável para confirmar tentativas de exploração já ocorridas antes da aplicação do patch.