Falha crítica no Splunk Enterprise abre brecha para execução remota de código sem login
A Splunk publicou um conjunto de atualizações de segurança para corrigir uma vulnerabilidade classificada como crítica em instalações on‑premises do Splunk Enterprise. O problema permite que um invasor realize operações em arquivos sem qualquer autenticação e, em cenários específicos, evolua o ataque até a execução remota de código no servidor comprometido.
Catalogada como CVE-2026-20253, a falha recebeu pontuação 9,8 no sistema CVSS, o que a coloca na faixa mais alta de gravidade. De acordo com o comunicado da empresa, versões do Splunk Enterprise anteriores às releases 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 exposto de um serviço auxiliar (sidecar) baseado em PostgreSQL.
O ponto central do problema está na ausência de controles de autenticação nesse serviço PostgreSQL sidecar. Na prática, qualquer pessoa com acesso de rede ao serviço é capaz de acionar operações sobre arquivos sem precisar apresentar credenciais válidas. Em ambientes onde o servidor Splunk Enterprise está acessível a partir de redes menos confiáveis, isso amplia significativamente a superfície de ataque.
A Splunk disponibilizou correções específicas para cada ramo de versão afetado. As instalações do Splunk Enterprise da versão 10.0.0 até a 10.0.6 devem ser atualizadas para a 10.0.7. Já os ambientes executando das versões 10.2.0 a 10.2.3 devem ser atualizados para a 10.2.4. A linha 10.4 do Splunk Enterprise não é afetada por essa vulnerabilidade. A empresa também esclareceu que o Splunk Cloud permanece imune à falha, pois não faz uso de sidecars PostgreSQL em sua arquitetura.
Análises técnicas publicadas por pesquisadores da watchTowr Labs mostram que a CVE-2026-20253 pode, em determinadas condições, ser explorada antes mesmo de qualquer autenticação, permitindo execução remota de código em sistemas vulneráveis. O vetor de ataque envolve os endpoints “/v1/postgres/recovery/backup” e “/v1/postgres/recovery/restore”, usados rotineiramente para processos de backup e restauração relacionados ao componente PostgreSQL integrado ao Splunk.
O fluxo de exploração descrito começa com o invasor estabelecendo conexão com um banco de dados PostgreSQL sob seu controle. Em seguida, o conteúdo desse banco é despejado em um arquivo arbitrário no servidor de destino por meio do endpoint “/backup”. O próximo passo é acionar o endpoint “/restore” para restaurar esse dump malicioso no PostgreSQL local do Splunk, utilizando o parâmetro “passfile” apontando para o arquivo “.pgpass” localizado em:
“/opt/splunk/var/packages/data/postgres/.pgpass”
Esse arquivo armazena a senha do usuário “postgres_admin”, utilizado internamente pelo Splunk. Ao explorar esse mecanismo, o invasor consegue fazer com que as consultas SQL contidas no dump malicioso sejam executadas pela instância PostgreSQL local, assumindo controle sobre o fluxo de restauração.
Com o banco de dados manipulável, torna-se possível interagir diretamente com a instância PostgreSQL usada pelo Splunk e, a partir daí, obter uma primitiva de escrita controlada no sistema de arquivos. Os pesquisadores Piotr Bazydlo e Yordan Ganchev demonstraram que a possibilidade de restaurar SQL sob controle do atacante permite a criação de um modelo de dump desenhado especificamente para gravar arquivos arbitrários no servidor.
Uma das técnicas descritas utiliza a criação de uma função que chama “lo_export”, recurso nativo do PostgreSQL para extrair BLOBs do banco e salvá-los como arquivos no sistema operacional. Assim, o invasor empacota no dump uma função que exporta conteúdo malicioso para um caminho específico em disco e garante que essa função seja executada durante o processo de restauração.
A partir do momento em que o atacante obtém escrita arbitrária em arquivos dentro do ambiente Splunk, o impacto pode ser elevado a execução remota de código. Um cenário possível seria sobrescrever um script Python executado periodicamente pelo Splunk, como “/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py”, inserindo uma carga maliciosa. Quando o Splunk executa esse script modificado, o código do atacante é rodado com os privilégios do processo Splunk.
O encadeamento completo do ataque, conforme descrito pelos pesquisadores, envolve a criação prévia de um banco PostgreSQL remoto configurado para permitir autenticação sem senha (por exemplo, em um ambiente preparado pelo próprio invasor) e com permissões para chamar funções como “lo_export”. Em seguida, o endpoint “/backup” é usado para gravar localmente, no servidor Splunk, um dump desse banco remoto. Por fim, o endpoint “/restore” realiza a restauração do dump malicioso, executa a função durante o processo e grava um script Python controlado pelo adversário no filesystem do Splunk, culminando na execução remota do payload.
Até o momento da divulgação, não foram identificados casos públicos de exploração ativa dessa vulnerabilidade em ataques reais. No entanto, a publicação dos detalhes técnicos e da cadeia de exploração completa tende a reduzir a barreira de entrada para criminosos, aumentando o risco de tentativas oportunistas, especialmente contra instâncias expostas à internet ou mal segmentadas dentro da rede corporativa.
Para organizações que utilizam Splunk Enterprise, a recomendação imediata é priorizar a aplicação das atualizações de segurança, com foco especial em ambientes que ainda executam versões anteriores à 10.2.4 e à 10.0.7. A simples atualização para as versões corrigidas elimina o vetor de ataque ligado ao PostgreSQL sidecar e reduz drasticamente o risco.
Além do patch, é essencial revisar a exposição dos serviços internos do Splunk. Endpoints administrativos e interfaces de serviço não devem estar acessíveis a partir da internet ou de redes de baixa confiança. O ideal é que o acesso seja restrito a segmentos de rede administrativos, protegidos por firewall, VPN e, sempre que possível, autenticação multifator para interfaces de gestão.
Outra medida prática é implementar regras de firewall e controles de rede que limitem o tráfego aos endpoints envolvidos em backup e restauração. Mesmo após a correção, reduzir a superfície exposta é uma boa prática que mitiga o impacto de futuras falhas ainda desconhecidas. A segmentação adequada impede que um invasor com presença em uma parte da rede alcance diretamente o serviço PostgreSQL sidecar.
Monitorar integridade de arquivos também se torna um ponto crítico nesse contexto. Como a cadeia de ataque depende da escrita e possível sobrescrita de arquivos sensíveis, mecanismos de detecção de alteração indevida – como soluções de monitoramento de integridade (FIM), trilhas de auditoria robustas e alertas de modificação em diretórios do Splunk – podem ajudar a identificar tentativas de exploração ou atividades anômalas precocemente.
Equipes de segurança devem incluir essa vulnerabilidade em seus processos de gestão de riscos e em programas de bug bounty internos, quando existirem. Mapear todos os servidores Splunk Enterprise, verificar versões, priorizar os que possuem maior exposição de rede e coordenar janelas de manutenção para atualização reduz a chance de que alguma instância esquecida permaneça vulnerável e se torne o elo fraco do ambiente.
Também é recomendável que administradores revisem periodicamente a configuração de bancos auxiliares e sidecars, verificando parâmetros de autenticação, permissões e acesso de rede. Mesmo quando não há vulnerabilidades conhecidas, serviços auxiliares muitas vezes são negligenciados, mantidos com configurações padrão e expostos além do necessário, o que favorece esse tipo de falha de alta criticidade.
Por fim, essa falha reforça um ponto importante para o ecossistema de observabilidade e segurança: soluções de monitoramento, SIEM e análise de logs, como o Splunk Enterprise, geralmente concentram dados sensíveis e possuem alta visibilidade dentro da rede. Quando comprometidas, podem dar ao invasor não apenas acesso a informações críticas, mas também um ponto privilegiado para movimentação lateral. Mantê-las sempre atualizadas, com arquitetura endurecida e sob vigilância constante, deve ser tratado como prioridade máxima em qualquer estratégia de cibersegurança corporativa.