A vulnerabilidade, identificada como CVE-2026-20253 , recebeu nota 9,8 na escala CVSS.
“Nas versões do Splunk Enterprise anteriores a 10.2.4 e 10.0.7, um usuário não autenticado poderia criar ou truncar arquivos arbitrários por meio de um endpoint do serviço auxiliar do PostgreSQL”, informou a empresa em um alerta nesta semana.
“O problema existe porque o endpoint do serviço auxiliar do PostgreSQL não possui controles de autenticação, permitindo que qualquer usuário alcançável pela rede invoque operações de arquivo sem credenciais.”
A falha foi corrigida nas seguintes versões:
- Splunk Enterprise 10.0.0 a 10.0.6: corrigido na 10.0.7
- Splunk Enterprise 10.2.0 a 10.2.3: corrigido na 10.2.4
- Splunk Enterprise 10.4: não afetado
A Splunk, que faz parte da Cisco, afirmou que o Splunk Cloud não é afetado pela vulnerabilidade, já que o produto não utiliza auxiliares do Postgres.
## Entenda a falha
Na sexta-feira, a watchTowr Labs divulgou detalhes técnicos adicionais da CVE-2026-20253 e afirmou que ela poderia ser explorada para obter execução remota de código antes da autenticação em sistemas suscetíveis, por meio dos endpoints “/v1/postgres/recovery/backup” e “/v1/postgres/recovery/restore”.
A cadeia de ataque funciona da seguinte forma:
- Conectar-se a um banco de dados controlado pelo atacante e despejar seu conteúdo em um arquivo arbitrário usando o endpoint /backup
- Carregar o despejo desse banco de dados, também controlado pelo atacante, na instância local do PostgreSQL usando o endpoint /restore, com a inclusão de um argumento “passfile” que aponta para um arquivo “.pgpass” em “/opt/splunk/var/packages/data/postgres/.pgpass”, onde está a senha do usuário “postgres_admin”
- As consultas SQL definidas no despejo do banco passam a ser executadas pela instância PostgreSQL da Splunk
Um atacante poderia transformar essa fraqueza em uma rotina para definir uma nova função que usa lo_export, função empregada para extrair um BLOB do banco de dados e salvá-lo como arquivo no sistema de arquivos, a fim de gravar conteúdo malicioso em um arquivo.
Em seguida, essa função seria executada durante o processo de restauração.
“Neste ponto, conseguimos autenticar, restaurar SQL controlado pelo atacante e interagir com o banco local”, disseram os pesquisadores de segurança Piotr Bazydlo e Yordan Ganchev.
“Assim que conseguimos restaurar SQL controlado pelo atacante na instância local do PostgreSQL, rapidamente montamos um modelo de despejo de banco que nos deu uma gravação controlada de arquivo.”
De posse de uma capacidade de gravação arbitrária de arquivos no sistema da Splunk, um atacante poderia avançar para execução remota de código ao sobrescrever um script Python executado com frequência pela empresa, como “/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py”, inserindo o payload malicioso.
A sequência completa de ações é a seguinte:
- Criar um banco de dados e configurá-lo para que um usuário possa se autenticar sem senha e receber permissões suficientes para invocar funções como lo_export
- Usar o endpoint /backup para gravar um despejo do banco remoto no sistema de arquivos da Splunk
- Usar o endpoint /restore para carregar o despejo malicioso, acionar a execução da função maliciosa durante o processo de restauração e escrever um script Python controlado pelo atacante no sistema de arquivos da Splunk
Embora não haja evidências de exploração da falha em ambiente real, a divulgação dos detalhes do exploit pode ser suficiente para incentivar threat actors a tentar ataques oportunistas.
É fundamental que os usuários apliquem os patches rapidamente para se manterem protegidos.
