A falha CVE-2026-20253, com pontuação CVSS 9.8 (crítica), foi divulgada pela Splunk em 10 de junho de 2026 e afeta o Splunk Enterprise. Ela permite que qualquer atacante, sem autenticação e acessível pela rede, crie ou trunque arquivos arbitrários por meio de um endpoint do serviço PostgreSQL Sidecar que não exige credenciais, abrindo caminho direto para execução remota de código.

Como a falha funciona

O PostgreSQL Sidecar Service, introduzido no Splunk Enterprise a partir da versão 10, é um processo auxiliar escrito em Go que gerencia operações de backup e restauração do banco de dados embarcado. Ele expõe uma API HTTP com endpoints como /v1/postgres/recovery/backup e /v1/postgres/recovery/restore. O problema central: nenhum desses endpoints exige autenticação, classificado como CWE-306, de modo que qualquer host que alcance a porta do serviço pode invocar operações de arquivo sem credenciais.

Embora o serviço escute por padrão na interface de loopback (porta 5435), pesquisadores da watchTowr demonstraram que o endpoint pode ser alcançado através da aplicação web principal do Splunk, transformando a falha aparentemente local em um vetor remoto. Com a capacidade de criar ou truncar arquivos arbitrários, um atacante consegue manipular configurações do banco de dados e, em seguida, alcançar execução remota de código com os privilégios do processo do Splunk.

Versões afetadas e correção

A Splunk publicou o advisory SVD-2026-0603 em 10 de junho de 2026 e não oferece mitigação alternativa — a única solução é atualizar. A tabela resume o status de cada versão:

Versão do Splunk Enterprise Status Versão de correção
10.0.0 a 10.0.6 Afetada 10.0.7
10.2.0 a 10.2.3 Afetada 10.2.4
10.4.x Não afetada
Splunk Cloud Platform Não afetada

O PostgreSQL Sidecar não é utilizado no Splunk Cloud, conforme esclarecimento do advisory atualizado em 12 de junho de 2026, o que deixa as instâncias gerenciadas em nuvem da própria Splunk fora de risco para esta falha específica.

Risco elevado em nuvem

Um detalhe crítico destacado pelos pesquisadores: em implantações do Splunk Enterprise na AWS, o PostgreSQL Sidecar Service vem instalado e habilitado por padrão, tornando essas instâncias vulneráveis sem qualquer configuração adicional. Já em instalações on-premise no Windows, o serviço não é instalado ou não vem habilitado por padrão, reduzindo a superfície de ataque nesses ambientes. A descoberta é do pesquisador Alex Hordijk (hordalex).

A pontuação máxima de criticidade reflete o vetor CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — explorável pela rede, com baixa complexidade, sem privilégios e sem interação do usuário, com impacto total em confidencialidade, integridade e disponibilidade. A falha se soma a um cenário de zero-days recentes em produtos de infraestrutura que exigem resposta imediata das equipes de segurança.

Outras falhas no mesmo lote

O advisory de junho incluiu ainda três vulnerabilidades de alta severidade. A CVE-2026-20251 (CVSS 8.8), no app Splunk Secure Gateway, permite execução remota de código por desserialização insegura de dados via biblioteca jsonpickle, exigindo apenas privilégios baixos. A CVE-2026-20258 (CVSS 7.1) é um XSS armazenado em painéis HTML de dashboards clássicos, e a CVE-2026-20252 (CVSS 7.6) é uma SSRF no exportador de PDF do Dashboard Studio. Nenhuma das falhas tem, até o momento, registro de exploração ativa na natureza — padrão semelhante ao observado em correções de falhas antigas em softwares amplamente usados.

Como se proteger agora

  • Atualize imediatamente o Splunk Enterprise para 10.4.0, 10.2.4 ou 10.0.7 — não existe workaround oficial para a CVE-2026-20253.
  • Priorize instâncias na AWS, pois o Sidecar vem ativo por padrão e fica vulnerável sem ajuste manual.
  • Restrinja o acesso de rede ao host do Splunk com firewall e segmentação para limitar quem pode alcançar o endpoint afetado, como defesa em profundidade até concluir o patch.
  • Aplique também as correções do Splunk Secure Gateway (versões 3.8.67+, 3.9.20+ ou 3.10.6+) para mitigar a CVE-2026-20251.
  • Monitore os logs do Splunk em busca de requisições anômalas aos endpoints /v1/postgres/recovery/, principal indicador de tentativa de exploração.

Fontes