Splunk Enterprise: falha crítica CVE-2026-20253 (CVSS 9.8) permite RCE sem autenticação via PostgreSQL sidecar

Splunk publicou correção emergencial para a CVE-2026-20253, falha crítica de gravidade 9.8 (CVSS) que permite a um atacante remoto e não autenticado escrever arquivos arbitrários e obter execução de código no Splunk Enterprise — o ponto de partida é o endpoint do sidecar PostgreSQL, exposto sem qualquer controle de autenticação. Pesquisadores da watchTowr Labs já divulgaram a cadeia técnica de exploração, elevando o risco de tentativas oportunistas em massa contra instâncias on-premise.

O que aconteceu

A Splunk, hoje parte do portfólio da Cisco, divulgou esta semana um patch de segurança que cobre o Splunk Enterprise nas versões abaixo de 10.2.4 e 10.0.7. A descrição oficial é direta: “Em versões do Splunk Enterprise abaixo de 10.2.4 e 10.0.7, um usuário não autenticado poderia criar ou truncar arquivos arbitrários através de um endpoint do serviço sidecar PostgreSQL”, aponta o aviso. A causa-raiz é a ausência completa de autenticação no endpoint que controla operações de backup e restauração do banco interno do produto.

A vulnerabilidade não atinge o Splunk Cloud — segundo a empresa, a arquitetura SaaS não utiliza o sidecar Postgres exposto no produto on-premise. Ainda assim, o universo de instâncias autogerenciadas que rodam SIEM/observabilidade na borda corporativa é grande, e muitas estão acessíveis a partir de redes internas amplas, o que torna a janela de exposição relevante mesmo sem internet aberta.

Pouco depois do aviso oficial, a watchTowr Labs publicou os detalhes técnicos completos, com a sequência exata de chamadas que leva da escrita de arquivos ao RCE. Esse padrão se repete em CVEs críticas recentes em produtos corporativos: a divulgação técnica acelera a corrida entre defensores e atacantes, e o vencedor é quem aplica patch mais rápido.

Detalhes da vulnerabilidade

O ponto de entrada é o serviço PostgreSQL sidecar que o Splunk Enterprise usa para operações internas de armazenamento. Dois endpoints expostos sem autenticação carregam a maior parte do peso do ataque: /v1/postgres/recovery/backup e /v1/postgres/recovery/restore. A partir deles, um invasor pode injetar SQL controlado durante o processo de restauração.

A escalada para RCE depende de um truque clássico em PostgreSQL: a função lo_export, usada legitimamente para gravar BLOBs em disco. O exploit define uma função SQL maliciosa que grava conteúdo arbitrário em um caminho do sistema de arquivos do Splunk e, em seguida, é executada como parte do fluxo de restauração. Com primitiva de escrita arbitrária em mãos, basta sobrescrever um script Python que o Splunk executa rotineiramente — os pesquisadores citam o caminho /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py como alvo para colocar a carga útil em execução com privilégios do daemon.

“Uma vez que conseguimos restaurar SQL controlado pelo atacante na instância local do PostgreSQL, montamos rapidamente um template de dump de banco que nos deu uma escrita de arquivo controlada.”

Piotr Bazydlo e Yordan Ganchev, watchTowr Labs

Quem é afetado

• Splunk Enterprise on-premise em versões anteriores a 10.2.4 e 10.0.7 — alvo direto da CVE.
• Ambientes híbridos que mantêm coletores e indexadores autogerenciados ao lado do Splunk Cloud.
• Pipelines de observabilidade com dependência crítica do Splunk para detecção: a falha permite ao atacante apagar evidências, comprometer regras de correlação e operar com persistência no próprio SIEM.
• Distribuições que repackage o Splunk em appliances internos ou containers proprietários — o sidecar PostgreSQL acompanha o pacote.

Análise

A CVE-2026-20253 entra numa série crescente de vulnerabilidades pré-autenticação em produtos de segurança que, ironicamente, são contratados para defender o perímetro. Os últimos 18 meses trouxeram um padrão consistente: ataques contra Ivanti, Fortinet, Citrix NetScaler e, agora, Splunk — sempre com a mesma combinação tóxica de exposição de rede ampla, código legado em serviços auxiliares e janela curta entre disclosure e exploração ativa.

O detalhe que merece atenção é o vetor: o atacante não precisa quebrar o Splunk em si — basta abusar de um serviço acessório (PostgreSQL sidecar) que foi adicionado para acelerar funções internas e que, no design original, presumiu confiança implícita do ambiente. Essa hipótese de “rede confiável” é exatamente o que abordagens zero-trust tentam eliminar, e cada CVE como esta reforça a urgência de revisitar serviços expostos por padrão em produtos complexos. Vale também olhar para a integração Splunk-Cisco: a empresa-mãe terá pressão regulatória e contratual para acelerar correções e comunicação, em especial para clientes federais que mantêm Splunk como SIEM principal.

Embora não haja relato de exploração ativa no momento, a publicação dos exploit specifics pela watchTowr funciona como acelerador. Atores oportunistas — particularmente brokers de acesso inicial — costumam escanear a internet em busca de instâncias vulneráveis nas primeiras 72 horas após detalhes técnicos virem públicos.

Recomendações práticas

• Atualize imediatamente para Splunk Enterprise 10.2.4 ou 10.0.7. Não trate este como patch de fim de mês.
• Inventarie a exposição: identifique todas as instâncias Splunk on-premise, incluindo as gerenciadas por outras equipes (DevOps, redes, segurança aplicacional).
• Bloqueie acesso à porta do sidecar PostgreSQL em redes não administrativas; idealmente isole o Splunk em VLAN dedicada com listas de acesso restritas.
• Procure indicadores de comprometimento em arquivos modificados sob /opt/splunk/etc/apps/, especialmente scripts Python recentemente alterados; revise logs do PostgreSQL sidecar em busca de chamadas anômalas aos endpoints /v1/postgres/recovery/*.
• Considere rotacionar credenciais e tokens armazenados no Splunk se você operava versão vulnerável com exposição ampla.
• Monitore o feed da CISA KEV: se a CVE for adicionada nos próximos dias, agências federais (e fornecedores) terão prazo formal para correção.

Fonte: The Hacker News