Unauthenticated Arbitrary File Creation and Truncation in a PostgreSQL Sidecar Service Endpoint in Splunk Enterprise

Falha de ausência de autenticação (CWE-306) no serviço sidecar de PostgreSQL que acompanha o Splunk Enterprise a partir da versão 10, permitindo que qualquer usuário com acesso de rede crie ou trunque arquivos arbitrários sem credenciais. O CVSS 9.8 reflete o pior cenário possível (C:H/I:H/A:H), mas o impacto real depende de o sidecar estar instalado e habilitado — o que varia por forma de instalação e não é universal. Está no catálogo KEV da CISA com evidência de exploração limitada confirmada pelo próprio PSIRT da Splunk em junho de 2026.

O componente vulnerável é o 'splunk-postgres', um binário Go que roda como serviço sidecar e escuta por padrão em 127.0.0.1:5435 (e em outra porta efêmera, observada em 33669), aparentemente restrito ao loopback. Ele expõe uma API HTTP sob o prefixo /v1/postgres/, com endpoints como /v1/postgres/status, /v1/postgres/health, /v1/postgres/recovery/backup e /v1/postgres/recovery/restore. O endpoint de backup aceita um JSON com os campos 'database' e 'backupFile', ambos controláveis pelo requisitante — é essa combinação que abre a porta para escrita/truncamento de arquivo fora do escopo esperado (indicativo de um path traversal ou falta de validação de caminho, embora o mecanismo exato de resolução de caminho não esteja detalhado publicamente).

O problema central, segundo o advisory da Splunk, é que esse endpoint sidecar não implementa nenhum controle de autenticação — qualquer requisição alcançável na rede é aceita e executada. Pesquisadores da watchTowr demonstraram que, apesar do bind em loopback, a aplicação web principal do Splunk (splunkd, exposta em todas as interfaces na porta 8000) atua como proxy para essa API interna através de um caminho tipo /en-US/splunkd/__raw/v1/postgres/..., repassando a requisição ao sidecar sem exigir credenciais válidas — nos testes deles, um header 'Authorization: Basic Og==' (equivalente a usuário e senha vazios) foi suficiente para a requisição ser processada.

O CWE catalogado (306 — Missing Authentication for Critical Function) reflete exatamente isso: a superfície de rede real de exploração não é a porta 5435 isolada, e sim o proxy exposto pela interface web/API de gerenciamento do Splunk, que herda a falta de autenticação do sidecar.

O vetor prático não exige a porta 5435 diretamente acessível pela rede: basta alcançar a interface HTTP do Splunk (splunkd/management, tipicamente porta 8000 ou a porta de management) que repassa a requisição ao sidecar interno via proxy. Não há necessidade de autenticação válida — nos testes de pesquisadores, um cabeçalho Authorization vazio já foi suficiente para a requisição ser aceita pelo backend. Isso torna a explicação de complexidade baixa (AC:L) coerente com o CVSS: sem interação do usuário, sem privilégios, apenas alcance de rede ao endpoint.

A pré-condição real e pouco óbvia na manchete é que o serviço PostgreSQL sidecar precisa estar instalado e habilitado. Segundo a análise da watchTowr, isso varia por forma de instalação: em instalação manual no Windows o sidecar pode não estar instalado, ou estar instalado mas desabilitado por padrão; em Splunk Enterprise na AWS, o sidecar vem instalado e habilitado por padrão, tornando essa variante vulnerável 'out of the box'. Splunk Cloud não usa sidecars e não é afetado.

O resultado direto e confirmado pelo fornecedor é criação ou truncamento de arquivo arbitrário no sistema onde o Splunk roda. A Splunk PSIRT confirmou exploração limitada em ambiente real em junho de 2026, e o item está no catálogo KEV da CISA com prazo de correção de apenas três dias (18 a 21 de junho), sinal de urgência alta atribuída pela agência. O título do artigo da watchTowr aponta para potencial encadeamento até execução remota de código, mas o material disponível publicamente não detalha o mecanismo exato dessa escalada além da primitiva de escrita/truncamento de arquivo — trate a primitiva confirmada como file write/truncate, e a possibilidade de RCE como algo a validar no seu próprio ambiente, não como fato estabelecido pelo fornecedor.

A correção definitiva é atualizar o Splunk Enterprise para 10.4.0, 10.2.4, 10.0.7 ou versões superiores dentro de cada ramo. Versões 9.4 e anteriores não são afetadas por não possuírem o conceito de sidecar. Splunk Cloud Platform não é afetado e não requer ação.

Se a atualização imediata não for viável, o paliativo oficial é desabilitar o serviço sidecar de PostgreSQL, adicionando a stanza '[postgres]\ndisabled = true' em $SPLUNK_HOME/etc/system/local/server.conf e reiniciando a instância. O custo real desse workaround: ele quebra Edge Processor, OpAmp e pipelines de dados SPL2 que dependam do sidecar — não aplique se esses recursos estiverem em uso, pois a quebra pode cascatear para outros processos sidecar dependentes. Busca, indexação e dashboards principais não são afetados pela desativação.

Restringir a exposição de rede das portas de management/web do Splunk não elimina a falha caso o serviço sidecar esteja habilitado e o proxy interno continue ativo, mas reduz a superfície de ataque enquanto a atualização ou o workaround não são aplicados — não é substituto para nenhum dos dois.

O próprio advisory da Splunk lista o campo 'Detections' como 'None' — não há assinatura ou indicador de comprometimento oficialmente publicado pelo fornecedor. Na ausência de detecção oficial, procure em logs de acesso web/splunkd por requisições POST para caminhos contendo '/v1/postgres/recovery/backup' ou '/v1/postgres/recovery/restore' via o proxy '__raw', especialmente com cabeçalho Authorization ausente, vazio ou com credenciais Basic triviais (ex.: 'Basic Og=='), e por criação ou truncamento inesperado de arquivos no sistema de arquivos do host Splunk sem correlação com atividade administrativa legítima.