A CISA adicionou CVE-2026-20253 ao seu catálogo de vulnerabilidades conhecidas exploradas, dando apenas três dias para agências federais corrigirem a falha crítica no Splunk Enterprise. A vulnerabilidade de CVSS 9.8 permite execução remota de código sem autenticação e já é explorada na natureza, segundo confirmou a própria Splunk em 18 de junho de 2026.

O que aconteceu

A Cisco, proprietária do Splunk desde a aquisição de 28 bilhões de dólares em 2024, anunciou correções para CVE-2026-20253 em 10 de junho de 2026. Dois dias depois, pesquisadores da watchTowr Labs publicaram prova de conceito funcional detalhando como um atacante sem credenciais poderia executar código arbitrário em servidores Splunk Enterprise expostos.

Oito dias após a divulgação inicial, em 18 de junho de 2026, a equipe de resposta a incidentes de segurança de produto do Splunk (PSIRT) confirmou exploração limitada da falha. No mesmo dia, a CISA adicionou CVE-2026-20253 ao seu catálogo KEV (Known Exploited Vulnerabilities), estipulando 21 de junho de 2026 como prazo final para que agências federais apliquem a correção. É a primeira vulnerabilidade do Splunk a entrar no KEV da CISA, conforme documentado pelo SecurityWeek.

Como funciona o ataque

A falha reside no endpoint do serviço PostgreSQL sidecar, que carece de controles de autenticação. Qualquer usuário com acesso à rede pode invocar operações de arquivo sem credenciais através dos endpoints /v1/postgres/recovery/backup e /v1/postgres/recovery/restore.

A cadeia de ataque descrita pelos pesquisadores Piotr Bazydlo e Yordan Ganchev, da watchTowr Labs, funciona em quatro etapas. Primeiro, o atacante se conecta a um banco de dados que controla e usa o endpoint /backup para despejar seu conteúdo em um arquivo arbitrário no servidor Splunk. Segundo, usa o endpoint /restore para carregar esse dump malicioso na instância PostgreSQL local, incluindo um argumento passfile que especifica o caminho para um arquivo .pgpass contendo a senha do usuário postgres_admin.

Terceiro, as consultas SQL definidas no dump malicioso são executadas pela instância PostgreSQL do Splunk. O atacante define uma função que usa lo_export — uma função que extrai um BLOB do banco e o salva como arquivo no sistema — para gravar conteúdo controlado em disco. Quarto, com a capacidade de escrita arbitrária de arquivos no sistema Splunk, o atacante sobrescreve um script Python executado frequentemente pela plataforma, como /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, para incluir payload malicioso e obter execução remota de código completa.

Versões afetadas e correções

A vulnerabilidade afeta versões específicas do Splunk Enterprise. O Splunk Cloud não é impactado porque não usa sidecars PostgreSQL. Versões 9.4 e anteriores também não são afetadas. O EPSS (Exploit Prediction Scoring System) atribuiu probabilidade de 10% de exploração nos próximos 30 dias.

Versão do Splunk Enterprise Status Versão corrigida
10.0.0 a 10.0.6 Vulnerável 10.0.7
10.2.0 a 10.2.3 Vulnerável 10.2.4
10.4 Não afetada —
Splunk Cloud Não afetada —
  • 10 de junho de 2026 — Splunk anuncia patches para CVE-2026-20253 (CVSS 9.8).
  • 12 de junho de 2026 — watchTowr Labs publica prova de conceito e detalhes técnicos.
  • 18 de junho de 2026 — Splunk confirma exploração limitada; CISA adiciona ao KEV.
  • 21 de junho de 2026 — Prazo final da CISA para agências federais aplicarem a correção.

Resposta da CISA e Splunk

A inclusão no KEV da CISA obriga agências do Poder Executivo Civil Federal dos Estados Unidos a aplicar as correções dentro do prazo de três dias, um dos mais curtos já estipulados. O catálogo KEV serve como referência global de prioridade de patches — organizações privadas em todo o mundo frequentemente adotam os mesmos prazos como padrão mínimo de resposta.

A Splunk afirmou em comunicado que seu PSIRT tomou conhecimento da exploração limitada em junho de 2026 e recomendou fortemente que clientes atualizem para versões corrigidas. Não há informações públicas detalhadas sobre os ataques específicos, incluindo quem está por trás da exploração ou quantas organizações foram comprometidas. A disponibilidade imediata de prova de conceito funcional aumenta o risco de exploração oportunista por diversos grupos criminosos, segundo avaliação do The Hacker News.

Como corrigir e mitigar

A correção definitiva é atualizar o Splunk Enterprise para a versão 10.0.7 ou 10.2.4, disponíveis através do portal oficial da Splunk. Organizações que executam versões 10.4 ou superiores não precisam agir.

Para administradores que não conseguem aplicar o patch imediatamente devido a restrições operacionais, a Splunk recomenda desabilitar completamente o serviço PostgreSQL sidecar como workaround temporário. Essa ação bloqueia o vetor de ataque ao eliminar o endpoint vulnerável. A restrição de acesso à rede aos endpoints /v1/postgres/recovery/backup e /v1/postgres/recovery/restore no perímetro também reduz a superfície de exposição.

As equipes de segurança devem procurar sinais de comprometimento prévio: arquivos .pgpass inesperados no caminho /opt/splunk/var/packages/data/postgres/, modificações em scripts Python dentro de /opt/splunk/etc/apps/, especialmente ssg_enable_modular_input.py, consultas SQL anômalas nos logs do PostgreSQL sidecar e conexões de saída para servidores de banco de dados não autorizados.

Fontes e referências