A vulnerabilidade Splunk Enterprise CVE-2026-20253 é uma falha crítica (CVSS 9,8) que permite a um atacante remoto e sem autenticação executar código arbitrário por meio de um endpoint do serviço sidecar PostgreSQL. Em 18 de junho de 2026, a CISA incluiu a falha no catálogo KEV com prova de exploração ativa e prazo de correção em 21 de junho de 2026 — apenas três dias. Splunk é o SIEM dominante em bancos, operadoras e órgãos públicos brasileiros.

Pontos-chave

  • O que é: ausência de autenticação (CWE-306) no endpoint do sidecar PostgreSQL do Splunk Enterprise, escalável a execução remota de código (RCE).
  • Severidade: CVSS 3.1 9,8 Crítico, sem necessidade de credenciais ou interação do usuário.
  • Versões afetadas: Splunk Enterprise 10.2 (anteriores a 10.2.4) e 10.x (anteriores a 10.0.7). As 9.4 e anteriores não são afetadas.
  • Exploração ativa: confirmada pela equipe PSIRT da Splunk em junho de 2026.
  • Prazo KEV: correção obrigatória até 21 de junho de 2026 para agências federais dos EUA; a CISA recomenda o mesmo para toda organização.
  • Correção: atualizar para 10.4.0, 10.2.4 ou 10.0.7; como paliativo, desativar o sidecar PostgreSQL.

O que é a falha CVE-2026-20253

O CVE-2026-20253 é uma vulnerabilidade de ausência de autenticação para função crítica (CWE-306) que afeta o Splunk Enterprise, a plataforma de análise de logs e SIEM usada por equipes de segurança em todo o mundo. A falha foi divulgada oficialmente pela Splunk no aviso SVD-2026-0603, publicado em 10 de junho de 2026 e atualizado em 18 de junho.

Em termos práticos, o problema está num endpoint do serviço sidecar PostgreSQL embutido no Splunk. Esse endpoint simplesmente não exige credenciais — qualquer usuário alcançável pela rede pode invocar operações de arquivo sem login. A Splunk classifica a vulnerabilidade com nota CVSS 3.1 de 9,8 (Crítico), no vetor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, ou seja: ataque pela rede, baixa complexidade, sem privilégios, sem interação humana e com impacto total em confidencialidade, integridade e disponibilidade, conforme o registro no NVD do NIST.

Como o ataque funciona na prática

A análise da empresa de inteligência de ameaças Resecurity mostra que a falha não para na simples criação de arquivos. Ela é, na essência, uma cadeia de exploração que combina quatro pontos fracos: ausência de autenticação, autorização insuficiente, path traversal e manipulação insegura de parâmetros PostgreSQL fornecidos pelo usuário.

O fluxo do ataque é direto. O atacante abusa de endpoints expostos de backup e restauração para criar arquivos em locais arbitrários do sistema. Em seguida, força o Splunk a se conectar a um servidor PostgreSQL controlado pelo atacante e gera dumps de banco maliciosos. Aproveitando credenciais confiáveis do PostgreSQL já presentes no sistema e abusando da função de restauração, o atacante sobrescreve arquivos usados pelo Splunk e executa operações controladas — culminando em execução arbitrária de código com os privilégios da conta de serviço do Splunk. O resultado é comprometimento total do ambiente.

Quais versões estão expostas

Nem todo Splunk Enterprise é vulnerável, e essa é uma informação decisiva para priorizar o trabalho da equipe. A tabela abaixo resume o estado de cada ramo de versão, conforme o aviso oficial da Splunk:

Versão base Status Correção
10.4 Não afetada 10.4.0 (já segura)
10.2 (10.2.0 a 10.2.3) Vulnerável 10.2.4
10.0 (10.0.0 a 10.0.6) Vulnerável 10.0.7
9.4 e anteriores Não afetada —

Quem ainda roda o ramo 9.x está, paradoxalmente, mais seguro diante desta falha específica. O problema foi introduzido com o sidecar PostgreSQL nas versões 10.x. A recomendação imediata é inventariar todas as instâncias e identificar quais estão no intervalo vulnerável.

O prazo da CISA vence amanhã

O que torna esta vulnerabilidade particularmente urgente não é apenas a nota 9,8, mas o prazo dado pela CISA. Em 18 de junho de 2026, a agência adicionou o CVE-2026-20253 ao seu catálogo de Vulnerabilidades Conhecidas e Exploradas (KEV), com base em evidências de exploração ativa no mundo real.

O registro no catálogo KEV estabelece data-limite de 21 de junho de 2026 — uma janela de apenas três dias, incomumente curta e reservada a falhas de altíssimo risco. Isso significa que órgãos federais dos EUA têm até domingo para aplicar a correção ou mitigação, e a CISA recomenda explicitamente que todas as organizações, públicas ou privadas, sigam o mesmo calendário. A diretiva BOD 26-04 ainda exige que as equipes verifiquem se o sistema já foi comprometido antes da aplicação do patch — não basta apenas corrigir.

Como corrigir e mitigar agora

A correção definitiva é atualizar o Splunk Enterprise para as versões 10.4.0, 10.2.4 ou 10.0.7 (ou superior). Para quem não conseguir fazer o upgrade imediatamente, a Splunk oferece um paliativo: desativar o serviço sidecar PostgreSQL. Basta adicionar a seguinte estrofe ao arquivo $SPLUNK_HOME/etc/system/local/server.conf:

[postgres]
disabled = true

Depois, é preciso reiniciar o Splunk Enterprise para a mudança ter efeito. Há uma ressalva importante: esse paliativo não deve ser aplicado em instâncias que usem Edge Processor, OpAmp ou pipelines de dados SPL2, pois desativar o PostgreSQL interrompe essas funcionalidades. Nesses casos, a única saída segura é o upgrade — o que reforça por que o prazo de três dias é tão apertado.

O contexto brasileiro amplifica o risco: bancos, fintechs, operadoras de telecomunicações e órgãos públicos do país usam o Splunk como SIEM central, frequentemente em ambientes híbridos expostos à internet. Um comprometimento do Splunk não vaza apenas logs — expõe credenciais, topologia de rede e configurações de segurança que podem abrir caminho para movimentação lateral e ataques de ransomware.

Sinais de comprometimento a procurar

Como a exploração já está confirmada, correção sem investigação é trabalho pela metade. A Resecurity lista indicadores concretos que equipes de monitoramento (blue team) devem procurar nos logs e no tráfego:

  • Requisições contendo sequências de path traversal (../) direcionadas ao endpoint do PostgreSQL.
  • Parâmetros de conexão PostgreSQL como hostaddr=, dbname=, port= ou passfile= em entradas suspeitas.
  • Execução inesperada dos binários pg_dump ou pg_restore no host do Splunk.
  • Criação de arquivos de dump de banco em locais incomuns do sistema de arquivos.
  • Conexões de saída dos serviços do Splunk para servidores PostgreSQL desconhecidos.

Há também um template de detecção Nuclei publicado pela comunidade (referência em github.com/0xBlackash/CVE-2026-20253) que pode identificar instâncias potencialmente vulneráveis — desde que usado apenas em sistemas próprios e autorizados. Ferramentas de evasão e técnicas de defesa em profundidade são discutidas em nosso material sobre evasão de IDS, firewalls e honeypots, e o controle de acesso adequado é exatamente o tipo de falha catalogada no mapeamento OWASP de riscos em aplicações sob a categoria de quebra de controle de acesso.

Por que três dias mudam tudo

Janelas de correção de três dias são raras e indicam que a CISA considera o risco imediato. A diferença entre uma falha de CVSS 9,8 com patch disponível e uma com exploração ativa confirmada é enorme: na segunda, já existem atacantes automatizando o ataque contra instâncias expostas. Quanto mais o Splunk estiver visível na internet — o que não deveria ocorrer, mas acontece com frequência em implantações mal configuradas —, maior a janela de oportunidade.

A lição de arquitetura vai além deste CVE. Endpoints administrativos de serviços internos, como um sidecar de banco de dados, não devem jamais ficar sem autenticação nem expostos à rede aberta. A falha recente no LiteSpeed cPanel que dava root segue o mesmo padrão: um componente de infraestrutura confiável vira porta de entrada porque ninguém protegeu o acesso. Em ambientes onde o Splunk concentra a visibilidade de segurança, comprometê-lo é comprometer todo o SOC.

Referências