Falha crítica no Splunk Enterprise permite execução remota de código sem autenticação

A Splunk lançou atualizações de segurança para corrigir uma vulnerabilidade crítica no Splunk Enterprise que pode permitir operações não autenticadas em arquivos e, em determinados cenários, execução remota de código em sistemas vulneráveis.

A falha, identificada como CVE-2026-20253, recebeu pontuação 9.8 no sistema CVSS, classificação considerada crítica. Segundo o alerta publicado pela Splunk, versões do Splunk Enterprise anteriores à 10.2.4 e à 10.0.7 permitem que um usuário não autenticado crie ou trunque arquivos arbitrários por meio de um endpoint do serviço PostgreSQL sidecar.

De acordo com a empresa, o problema existe porque o endpoint do serviço PostgreSQL sidecar não possui controles de autenticação. Isso permite que qualquer usuário com acesso de rede ao serviço consiga acionar operações de arquivo sem precisar de credenciais.

A correção foi disponibilizada para as versões afetadas. O Splunk Enterprise 10.0.0 até 10.0.6 foi corrigido na versão 10.0.7. Já o Splunk Enterprise 10.2.0 até 10.2.3 foi corrigido na versão 10.2.4. A versão Splunk Enterprise 10.4 não é afetada.

A Splunk, que faz parte da Cisco, informou ainda que o Splunk Cloud não é impactado pela vulnerabilidade, já que o produto não utiliza sidecars PostgreSQL.

Detalhes técnicos divulgados pela watchTowr Labs indicam que a CVE-2026-20253 pode ser explorada para alcançar execução remota de código antes da autenticação em sistemas suscetíveis. A exploração envolve os endpoints “/v1/postgres/recovery/backup” e “/v1/postgres/recovery/restore”, usados no fluxo de backup e restauração relacionado ao PostgreSQL.

A cadeia de ataque descrita pelos pesquisadores começa com a conexão a um banco de dados controlado pelo invasor. Em seguida, o conteúdo desse banco é despejado em um arquivo arbitrário por meio do endpoint “/backup”. Depois, o invasor usa o endpoint “/restore” para carregar esse dump no PostgreSQL local, incluindo um argumento “passfile” que aponta para o arquivo “.pgpass” localizado em:

“/opt/splunk/var/packages/data/postgres/.pgpass”. Esse arquivo contém a senha do usuário “postgres_admin”.

Com isso, consultas SQL definidas no dump do banco de dados controlado pelo invasor são executadas pela instância PostgreSQL usada pelo Splunk. Na prática, essa sequência permite ao atacante interagir com o banco local e avançar para escrita controlada de arquivos no sistema.

Segundo os pesquisadores Piotr Bazydlo e Yordan Ganchev, a possibilidade de restaurar SQL controlado pelo atacante na instância PostgreSQL local permitiu a criação de um modelo de dump capaz de realizar escrita controlada de arquivos.

Uma das formas de abuso envolve a criação de uma função que utiliza “lo_export”, recurso usado para extrair um BLOB do banco de dados e salvá-lo como arquivo no sistema. Com essa técnica, o invasor pode gravar conteúdo controlado em um arquivo e acionar a execução da função durante o processo de restauração.

A partir de uma primitiva de escrita arbitrária no sistema de arquivos do Splunk, o atacante pode escalar o impacto para execução remota de código. Para isso, poderia sobrescrever um script Python executado com frequência pelo Splunk, como “/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py”, inserindo uma carga maliciosa.

A sequência completa descrita pela watchTowr envolve a criação de um banco de dados configurado para permitir autenticação sem senha e com permissões suficientes para invocar funções como “lo_export”. Em seguida, o invasor usa o endpoint “/backup” para gravar o dump do banco remoto no sistema de arquivos do Splunk. Por fim, o endpoint “/restore” carrega o dump malicioso, executa a função durante a restauração e grava um script Python controlado pelo atacante no ambiente do Splunk.

Até o momento, não há evidências de exploração ativa da falha em ataques reais. No entanto, a divulgação dos detalhes técnicos aumenta o risco de tentativas oportunistas por parte de invasores, especialmente contra instâncias expostas ou acessíveis pela rede.

Organizações que utilizam Splunk Enterprise devem priorizar a aplicação das atualizações de segurança, principalmente em ambientes que executam versões anteriores à 10.2.4 e à 10.0.7. Também é recomendável revisar a exposição de serviços internos, restringir o acesso de rede aos endpoints administrativos e monitorar sinais de alteração indevida em arquivos do ambiente Splunk.