Vulnerabilidade RCE pré-autenticação no Splunk Enterprise CVE-2026-20253
Aprofundamento CEVIU
Aprofundamento
A CVE-2026-20253 não é só mais uma RCE pré-autenticação: é um colapso de camadas de segurança projetadas para proteger dados sensíveis. O PostgreSQL Sidecar Service foi introduzido na versão 10 como parte da migração para arquitetura modular, mas, ao contrário do que se esperaria, ele roda sem autenticação e com permissões elevadas do usuário splunk, mesmo em ambientes AWS onde está ativado por padrão. O ataque explora um desenho crítico: o endpoint /v1/postgres/recovery/backup aceita qualquer valor no campo database, inclusive strings de conexão completas. Isso faz o pg_dump ignorar o -h localhost hardcoded e conectar-se a um servidor externo controlado pelo atacante, transformando uma operação de backup legítima em um canal de exfiltração e injeção.
O ponto de inflexão técnico é o arquivo .pgpass: armazenado em texto simples no diretório do Splunk, ele contém credenciais do administrador do PostgreSQL local (postgres_admin). Uma vez obtidas, o atacante pode acessar diretamente a instância interna e substituir scripts Python executados pelo Splunk, como ssg_enable_modular_input.py, para obter RCE com privilégios persistentes. Isso não é teórico, o PoC da watchTowr demonstrou escrita arbitrária em /tmp e substituição de módulos do Secure Gateway, componente crítico para integrações com fontes externas.
Por que isso importa
Empresas que usam Splunk Enterprise como SIEM ou plataforma central de observabilidade estão expostas a um risco único: um atacante pode invadir o próprio sistema de detecção antes mesmo de tentar comprometer outros ativos. A falha permite bypass completo de controles de acesso, escalonamento de privilégios e persistência via substituição de código assinado, tudo sem credenciais. Como o Splunk é frequentemente exposto à internet (especialmente em implantações AWS), essa vulnerabilidade torna-se um alvo prioritário para ransomware e APTs. A ausência de mitigação eficaz além da atualização, como desabilitar o sidecar, mostra que a correção não é apenas técnica, mas arquitetural: confiar em 'localhost-only' sem isolamento de rede ou autenticação explícita é uma falha estrutural em sistemas de segurança.
Perguntas frequentes
Splunk Cloud Platform é afetado?
Não. O Splunk Cloud Platform não utiliza o PostgreSQL Sidecar Service. A vulnerabilidade afeta apenas instalações on-premise e Splunk Enterprise em AWS, onde o sidecar é instalado e habilitado por padrão.
Por que a versão 10.4 não é afetada?
A Splunk reestruturou o gerenciamento do PostgreSQL a partir da versão 10.4, removendo a dependência do serviço sidecar e migrando para uma abordagem integrada com controles de autenticação explícitos. Não é uma correção pontual, é uma substituição arquitetural.
Posso desabilitar o sidecar como mitigação temporária?
Sim. A Splunk confirmou em seu advisory atualizado em 15 de junho que é possível desabilitar o serviço via comando splunk disable postgres-sidecar. Mas isso exige reinicialização e pode impactar funcionalidades de recuperação de banco de dados e aplicações que dependem dele, como o Secure Gateway.
O arquivo .pgpass é sempre visível em texto simples?
Sim, por padrão. Ele é criado automaticamente durante a inicialização do sidecar com permissões 644 (leitura global). Não há opção nativa de criptografia ou uso de variáveis de ambiente para credenciais, o que viola práticas básicas de segurança de bancos de dados.
Fontes
- labs.watchtowr.comfonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 15 de junho de 2026
- Editoria
- CEVIU Segurança da Informação
