Falha crítica no Splunk Enterprise expõe empresas a execução remota de código sem login
Uma vulnerabilidade grave identificada no Splunk Enterprise está colocando em risco ambientes corporativos que utilizam a plataforma para análise de logs e observabilidade. A falha permite que um invasor, sem qualquer autenticação, execute operações não autorizadas em arquivos e, em determinadas condições, alcance execução remota de código (RCE) nos servidores afetados.
Classificada como CVE-2026-20253, a vulnerabilidade recebeu pontuação 9,8 no CVSS, o que a posiciona na categoria crítica. De acordo com o alerta oficial da fabricante, todas as versões do Splunk Enterprise anteriores à 10.2.4 e à 10.0.7 são impactadas por um problema específico no serviço PostgreSQL sidecar, componente utilizado em determinadas rotinas internas da solução.
O núcleo do problema está na ausência de mecanismos de autenticação em um endpoint exposto pelo serviço PostgreSQL sidecar. Em outras palavras, qualquer usuário com acesso de rede a esse serviço pode acionar operações de leitura, criação ou truncamento de arquivos, sem precisar fornecer credenciais ou comprovar identidade. Em ambientes corporativos onde o Splunk está acessível a partir de redes internas amplas, isso amplia significativamente a superfície de ataque.
Para mitigar o risco, a Splunk liberou correções específicas. As versões do Splunk Enterprise da linha 10.0.0 até 10.0.6 foram corrigidas por meio da atualização para a versão 10.0.7. Já as versões entre 10.2.0 e 10.2.3 receberam correções na versão 10.2.4. A edição 10.4 do Splunk Enterprise não é afetada por esse problema. Segundo a empresa, o Splunk Cloud também não sofre impacto, uma vez que não utiliza sidecars PostgreSQL na sua arquitetura.
Pesquisadores da watchTowr Labs divulgaram detalhes técnicos demonstrando que a CVE-2026-20253 pode ser explorada para obter execução de código remoto antes mesmo de qualquer processo de autenticação, desde que o atacante consiga se conectar ao serviço vulnerável. A exploração se concentra nos endpoints “/v1/postgres/recovery/backup” e “/v1/postgres/recovery/restore”, usados no fluxo de backup e restauração do PostgreSQL integrado ao Splunk.
O cenário de ataque descrito inicia com o invasor conectando o Splunk a um banco de dados PostgreSQL sob seu controle. Em seguida, o conteúdo desse banco malicioso é despejado em um arquivo arbitrário no sistema de arquivos do servidor de destino por meio do endpoint “/backup”. Posteriormente, o atacante utiliza o endpoint “/restore” para carregar o dump nesse PostgreSQL local, inserindo um parâmetro “passfile” que aponta para o arquivo “.pgpass” localizado em:
/opt/splunk/var/packages/data/postgres/.pgpass
Esse arquivo “.pgpass” armazena a senha do usuário “postgres_admin”, utilizado pela instância interna do PostgreSQL no Splunk. Ao manipular esse fluxo de backup e restauração, o invasor consegue fazer com que consultas SQL incluídas no dump sob seu controle sejam executadas pela instância PostgreSQL local.
Na prática, essa cadeia permite ao atacante interagir com o banco de dados utilizado pelo Splunk e, a partir daí, avançar para formas mais perigosas de comprometimento, como a escrita de arquivos arbitrários no sistema. Os pesquisadores Piotr Bazydlo e Yordan Ganchev demonstraram que a possibilidade de restaurar SQL controlado pelo atacante na instância local abre espaço para criação de dumps especificamente desenhados para viabilizar escrita controlada no sistema de arquivos.
Um dos métodos descritos envolve a criação de uma função que utiliza o recurso “lo_export”, mecanismo do PostgreSQL capaz de extrair um BLOB (objeto binário grande) do banco e salvá‑lo como arquivo no sistema operacional. Ao incluir essa função no dump malicioso e forçar sua execução durante o processo de restauração, o invasor passa a conseguir gravar conteúdo escolhido em qualquer caminho de arquivo ao qual o serviço tenha permissão de escrita.
A partir do momento em que o atacante obtém uma primitiva de escrita arbitrária no sistema de arquivos onde o Splunk está instalado, o passo seguinte é transformar essa capacidade em execução de código. Um dos cenários apresentados consiste em sobrescrever um script Python executado com frequência pela própria plataforma, como o arquivo:
/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py
Ao substituir esse script legítimo por uma versão contendo código malicioso, o invasor garante que, na próxima execução do processo rotineiro do Splunk, sua carga será disparada com os privilégios da aplicação, resultando em execução remota de código no servidor.
A cadeia completa proposta pelos pesquisadores inclui a criação de um banco de dados PostgreSQL preparado especialmente para o ataque, configurado para aceitar autenticação sem senha e com permissões suficientes para chamar funções como “lo_export”. O invasor então utiliza o endpoint “/backup” para gravar o dump desse banco remoto no sistema de arquivos do Splunk. Em seguida, o endpoint “/restore” importa o dump no PostgreSQL local, executa as consultas e funções maliciosas definidas no arquivo e, por fim, grava um script Python adulterado no ambiente do Splunk, viabilizando o comprometimento total do sistema.
Até o momento, não há relatos públicos de exploração ativa em ataques direcionados ou em larga escala. Porém, a divulgação detalhada do vetor e da cadeia de ataque aumenta significativamente a probabilidade de uso oportunista por criminosos, principalmente contra instâncias expostas à internet ou acessíveis a partir de redes internas com muitos usuários e dispositivos.
Para organizações que utilizam o Splunk Enterprise, a recomendação é tratar essa vulnerabilidade como prioridade máxima. Isso inclui aplicar imediatamente as atualizações de segurança para as versões afetadas, com especial atenção para ambientes que ainda executam versões anteriores às edições 10.2.4 e 10.0.7. Ambientes de produção, que normalmente concentram grandes volumes de dados sensíveis e registros de segurança, devem ser atualizados com urgência.
Além do patch oficial, boas práticas de segurança de rede podem reduzir de forma significativa o risco de exploração. É essencial revisar a exposição dos serviços internos do Splunk, garantindo que endpoints administrativos e serviços auxiliares – como o PostgreSQL sidecar – não estejam acessíveis desnecessariamente a redes amplas ou segmentos pouco confiáveis. A segmentação de rede, o uso de listas de controle de acesso (ACLs) e a limitação de portas e IPs autorizados são medidas complementares que fortalecem a defesa.
Outra camada importante de proteção está na monitoração de integridade de arquivos críticos do ambiente Splunk. Como o vetor de ataque se apoia em escrita arbitrária no sistema de arquivos, a implementação de mecanismos que detectem alterações inesperadas em scripts, binários e diretórios de configuração pode ajudar a identificar uma tentativa de exploração ou um comprometimento em andamento. Ferramentas de detecção de intrusão em host (HIDS) e soluções de segurança focadas em comportamento podem ser aliadas importantes.
Equipes de segurança também devem considerar a realização de uma varredura proativa em seus ambientes para identificar sinais de abuso dos endpoints “/v1/postgres/recovery/backup” e “/v1/postgres/recovery/restore”. Logs de acesso a esses caminhos, especialmente oriundos de origens incomuns ou fora de janelas de manutenção planejadas, podem indicar tentativas de exploração ou sondagem de vulnerabilidades.
Para organizações que, por motivos operacionais, não podem aplicar o patch imediatamente, é fundamental adotar medidas de mitigação temporárias. Entre elas, restringir o acesso à interface de administração do Splunk e ao serviço PostgreSQL sidecar apenas a administradores e sistemas estritamente necessários, isolar o servidor em segmentos de rede mais protegidos e avaliar a possibilidade de implementar controles adicionais, como firewalls de aplicação ou proxies de segurança, que filtrem requisições suspeitas.
Do ponto de vista de governança de segurança, a CVE-2026-20253 reforça a importância de tratar ferramentas de observabilidade e análise de logs como ativos críticos de infraestrutura. Muitas vezes, plataformas como o Splunk concentram registros de autenticação, eventos de sistemas, dados de aplicações e informações sensíveis sobre a arquitetura interna da organização. Um comprometimento nessa camada pode abrir caminho para ataques mais amplos, movimentos laterais e uso de dados de logs para planejar novos vetores de intrusão.
Por fim, é recomendável que empresas revisem suas políticas de atualização de software e gestão de vulnerabilidades especificamente para soluções de monitoramento e segurança. A adoção de processos de patch management mais ágeis, testes regulares de segurança em ambientes de observabilidade e integração entre equipes de infraestrutura e segurança ajudam a reduzir a janela de exposição sempre que novas falhas críticas são divulgadas.
A vulnerabilidade no Splunk Enterprise evidencia como falhas em componentes auxiliares, como sidecars de banco de dados, podem resultar em comprometimentos graves quando não contam com controles robustos de autenticação e autorização. A resposta rápida – combinando atualização, endurecimento de configurações e monitoramento – é essencial para evitar que essa falha se transforme em porta de entrada para invasores em ambientes corporativos.