Splunk Enterprise sob exploração ativa via falha RCE sem autenticação no sidecar PostgreSQL (CVE-2026-20253); CISA dá prazo até 21 de junho

A CISA incluiu esta semana a CVE-2026-20253, vulnerabilidade crítica de execução remota de código sem autenticação no Splunk Enterprise, em seu catálogo de Known Exploited Vulnerabilities (KEV) e ordenou que agências federais civis dos EUA apliquem mitigações até 21 de junho de 2026. A exploração ativa foi confirmada pelo próprio fornecedor e pela Resecurity, com potencial de comprometimento total dos ambientes de SIEM mais usados no mercado corporativo.

O que aconteceu

A Splunk publicou o aviso original sobre a CVE-2026-20253 em 10 de junho, junto com os patches corretivos para as versões 10.4.0, 10.2.4 e 10.0.7. Dois dias depois, em 12 de junho, pesquisadores da watchTowr divulgaram análise técnica detalhada e uma versão “neutralizada” do exploit para que organizações pudessem testar a própria exposição. Pouco depois, surgiu um template de detecção Nuclei público – e foi nesse ponto que a exploração in-the-wild deslanchou.

O Splunk Enterprise é a espinha dorsal de monitoramento e correlação de logs em milhares de organizações – de bancos a operadores de infraestrutura crítica – e funciona como peça central do SIEM em SOCs maduros. Um atacante com controle do Splunk não apenas se torna invisível para a maior parte das detecções como obtém acesso a credenciais armazenadas, integrações com cloud, conectores para Active Directory, scripts de orquestração e, frequentemente, dados regulados que atravessam os índices.

Detalhes técnicos

De acordo com o aviso oficial da Splunk, “nas versões 10.2 abaixo de 10.2.4 e nas versões 10 abaixo de 10.0.7, um usuário não autenticado poderia criar ou truncar arquivos arbitrários por meio de um endpoint do serviço sidecar PostgreSQL”. A causa raiz é simples e bastante familiar: o sidecar responsável por backup e recuperação do PostgreSQL expõe um endpoint HTTP sem qualquer controle de autenticação, aceitando operações de arquivo de qualquer requisição que alcance o serviço.

“Dado o papel central do Splunk no monitoramento de segurança e na inteligência operacional, o comprometimento da plataforma pode reduzir significativamente a visibilidade organizacional, permitindo que atividades maliciosas adicionais ocorram sem detecção.”

Resecurity

O caminho de RCE é direto: o atacante usa a primitiva de escrita/truncamento de arquivos para gravar payloads em diretórios executáveis ou de configuração, ou para sobrescrever scripts confiáveis que o próprio Splunk executa. A partir daí, o controle do app dá acesso a credenciais armazenadas, possibilita pivotar para sistemas internos, manipular ou apagar dados de auditoria e expor segredos colhidos pelos conectores de integração com fontes externas.

Quem é afetado

• Implantações on-premises de Splunk Enterprise nas versões 10.2 anteriores a 10.2.4 e 10 anteriores a 10.0.7;
• Agências federais civis dos EUA, obrigadas pela CISA a corrigir até 21 de junho de 2026 ou desativar o serviço afetado;
• Bancos, operadores de telecom, energia, saúde e qualquer setor que dependa do Splunk como SIEM principal;
• Provedores MSSP que orquestram detecção e resposta sobre cluster Splunk compartilhado entre clientes;
• Ambientes híbridos em que o sidecar PostgreSQL está exposto à rede corporativa – mesmo sem exposição direta à internet.

Análise

Comprometer um SIEM é, há anos, o “santo graal” para atacantes sofisticados. O Splunk concentra justamente o que um defensor mais protege e o que um atacante mais quer: registro centralizado do que acontece em todos os outros sistemas. Uma vez controlado, o adversário pode tanto apagar evidências quanto fabricar narrativas, dificultando enormemente a resposta a incidentes. A CVE-2026-20253 entra para uma categoria pequena, mas pesada, de falhas que invertem o jogo defensivo – ao lado de incidentes como o do SolarWinds Orion (2020) e o abuso de agentes EDR observado em campanhas de 2024.

Outro ponto que merece atenção é o vetor: o problema não está no Splunk Enterprise “core”, e sim em um serviço sidecar empacotado com a versão 10. Esse padrão arquitetural – rodar serviços auxiliares como containers ou processos paralelos para simplificar deploy – tem se mostrado um repositório consistente de superfícies de ataque mal mapeadas. Engenharia de segurança precisa começar a tratar sidecars com o mesmo rigor que componentes externos, exigindo threat models específicos, hardening por padrão e desativação opt-in quando o sidecar não for necessário.

O cronograma da exploração também é didático. Patch em 10 de junho, PoC neutralizado em 12 de junho, template Nuclei pouco depois e exploração ativa observada antes mesmo do prazo CISA de 21 de junho. A janela entre patch e exploitation segue encolhendo – e em algumas categorias, como appliances de segurança e ferramentas administrativas, já chega a ser negativa, com exploração começando antes que o patch esteja amplamente distribuído.

Recomendações práticas

• Atualize imediatamente o Splunk Enterprise para 10.4.0, 10.2.4 ou 10.0.7, conforme a linha em uso;
• Se o patch não puder ser aplicado de imediato, desative o serviço sidecar PostgreSQL (a Splunk confirma que essa mitigação funciona, embora alguma funcionalidade seja afetada);
• Restrinja o acesso de rede ao endpoint do sidecar por meio de firewall interno, regra iptables ou ACL de host;
• Use o template Nuclei público ou o exploit neutralizado da watchTowr para validar se a sua instalação está vulnerável – confiar apenas na versão reportada pode esconder builds custom;
• Audite logs do Splunk procurando criação de arquivos suspeitos, novos jobs agendados, alterações em configurações de autenticação e novos search heads adicionados ao cluster;
• Rotacione as credenciais armazenadas no Splunk (conexões a fontes de dados, tokens HEC, integrações com cloud) caso o ambiente tenha rodado versão vulnerável com o sidecar ativo;
• Considere o ambiente comprometido se houver indicadores, e acione plano de resposta a incidentes envolvendo isolamento, forense e revisão de logs externos (não originados do próprio Splunk);
• Reveja exposição do plano de gerência: o painel Splunk e seus sidecars não devem estar acessíveis a partir da internet.

Fonte: Help Net Security