O Splunk lançou atualizações de segurança para solucionar uma falha crítica de segurança no Splunk Enterprise que poderia ser explorada para conduzir operações de arquivos não autenticados e até mesmo execução remota de código.
A vulnerabilidade, rastreada como CVE-2026-20253, é classificada como 9,8 no sistema de pontuação CVSS.
"Nas versões do Splunk Enterprise anteriores a 10.2.4 e 10.0.7, um usuário não autenticado pode criar ou truncar arquivos arbitrários por meio de um endpoint de serviço secundário do PostgreSQL", disse o Splunk em um alerta esta semana.
"A vulnerabilidade existe porque o endpoint de serviço secundário do PostgreSQL não possui controles de autenticação, permitindo que qualquer usuário acessível pela rede invoque operações de arquivo sem credenciais."
O problema foi resolvido nas seguintes versões -
- Splunk Enterprise 10.0.0 a 10.0.6 - Corrigido em 10.0.7
- Splunk Enterprise 10.2.0 a 10.2.3 - Corrigido em 10.2.4
- Splunk Enterprise 10.4 - Não afetado
Splunk, que faz parte da Cisco, disse que o Splunk Cloud não é afetado pela vulnerabilidade, pois os sidecars do Postgres não são usados no produto.
O que é a falha
Na sexta-feira, watchTowr Labs lançou detalhes técnicos adicionais do CVE-2026-20253, afirmando que ele poderia ser explorado para obter execução remota de código pré-autenticado em sistemas suscetíveis por meio de "/v1/postgres/recovery/backup" e "/v1/postgres/recovery/restore" pontos finais.
A cadeia de ataque funciona da seguinte forma -
- Conecte-se a um banco de dados controlado pelo invasor e despeje seu conteúdo em um arquivo arbitrário usando o endpoint /backup
- Carregue o dump do banco de dados controlado pelo invasor na instância local do PostgreSQL usando o endpoint /restore incluindo um argumento "passfile" que especifica o caminho para um arquivo ".pgpass" ("/opt/splunk/var/packages/data/postgres/.pgpass") contendo a senha do usuário "postgres_admin"
- As consultas SQL definidas no dump do banco de dados serão executadas pela instância PostgreSQL do Splunk
Um invasor pode transformar essa fraqueza em uma arma para definir uma nova função que usa lo_export - uma função usada para extrair um BLOB do banco de dados e salvá-lo como um arquivo no sistema de arquivos - para gravar conteúdo controlado pelo invasor em um arquivo, após o qual a função é executada durante o processo de restauração.
"Neste ponto, podemos autenticar, restaurar o SQL controlado pelo invasor e interagir com o banco de dados local", disseram os pesquisadores de segurança Piotr Bazydlo e Yordan Ganchev. "Assim que pudemos restaurar o SQL controlado pelo invasor na instância local do PostgreSQL, rapidamente montamos um modelo de despejo de banco de dados que nos forneceu uma gravação de arquivo controlada."
Armado com uma primitiva de gravação de arquivo arbitrária no sistema de arquivos Splunk, um invasor pode escalar ainda mais para a execução remota de código, sobrescrevendo um script Python que o Splunk executa com frequência (por exemplo, "/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py") para incluir a carga maliciosa.
§HTMLLTAG52§A sequência completa de ações está abaixo -- Crie um banco de dados e configure-o de forma que um usuário possa autenticar sem senha e conceder-lhe permissões suficientes para invocar funções como lo_export
- Use o endpoint /backup para descartar um dump do banco de dados remoto no sistema de arquivos Splunk
- Use o endpoint /restore para carregar o despejo de banco de dados malicioso, acione a execução da função maliciosa durante o processo de restauração e grave um script Python controlado pelo invasor no sistema de arquivos Splunk
Embora não haja evidências de que a falha esteja sendo explorada em estado selvagem, a disponibilidade dos detalhes da exploração pode ser suficiente para levar os atores da ameaça a desencadear tentativas oportunistas. É essencial que os usuários ajam rapidamente para aplicar as correções para permanecerem protegidos.