A 10 de junho de 2026, a Splunk divulgou a vulnerabilidade CVE-2026-20253 com pontuação CVSS de 9.8, a classificação mais severa do espectro crítico. A falha permite que qualquer atacante com acesso de rede execute código arbitrário no servidor Splunk Enterprise sem fornecer credenciais. Oito dias após a divulgação, em 18 de junho, a empresa confirmou exploração ativa limitada. A CISA respondeu de imediato, adicionando o CVE ao catálogo de Vulnerabilidades Conhecidas Exploradas (KEV) e impondo um prazo de apenas 72 horas às agências civis federais dos Estados Unidos para aplicar o patch. O contador para empresas privadas corre em paralelo.
O Que é o CVE-2026-20253 e Porque o CVSS 9.8 É Relevante
O CVE-2026-20253 é classificado como CWE-306, ausência de autenticação para funções críticas. O vetor CVSS completo é AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: ataque pela rede, baixa complexidade, sem privilégios prévios, sem interação do utilizador, impacto alto em confidencialidade, integridade e disponibilidade. Na prática, qualquer atacante que consiga alcançar o serviço sidecar PostgreSQL do Splunk Enterprise pela rede pode invocar operações de ficheiro sem qualquer credencial.
A pontuação de 9.8 coloca este CVE a apenas 0.2 pontos do máximo absoluto de 10.0, território reservado para falhas sem qualquer condição de exploração. Para efeitos práticos, a distinção é irrelevante: a cadeia de exploração demonstrada por investigadores é totalmente pré-autenticada e leva a execução remota de código (RCE) num servidor que, na maioria das organizações, contém dados de segurança dos últimos meses ou anos. O aviso oficial da Splunk foi publicado com o identificador SVD-2026-0603 e atualizado a 18 de junho após confirmação de exploração ativa.
Cronologia: 10 a 21 de Junho de 2026
A sequência de eventos entre a divulgação e a ordem da CISA aconteceu em 11 dias, mas o ritmo real foi muito mais comprimido. A janela efetiva entre um PoC público e exploração em larga escala é tipicamente inferior a 72 horas para falhas CVSS acima de 9.0:
- 10 de junho: A Splunk publica o aviso SVD-2026-0603 e divulga simultaneamente três outras vulnerabilidades de severidade elevada, incluindo uma falha de SSRF (SVD-2026-0602) e um ataque de XSS persistente na aplicação Splunk Secure Gateway.
- 12 de junho: O watchTowr Labs publica análise técnica completa demonstrando pré-auth RCE através dos endpoints
/v1/postgres/recovery/backupe/v1/postgres/recovery/restoredo serviço sidecar PostgreSQL. - 15 de junho: A NetSPI publica análise detalhada da cadeia de exploração via função
lo_exportdo PostgreSQL e disponibiliza prova de conceito (PoC) pública no GitHub. - 18 de junho: A Splunk PSIRT atualiza o aviso: “Em junho de 2026, a equipa Splunk PSIRT tomou conhecimento de exploração limitada desta vulnerabilidade.”
- 18 de junho: A CISA adiciona CVE-2026-20253 ao catálogo KEV da mesma data.
- 21 de junho: Prazo final para agências FCEB aplicarem o patch ou desativarem o serviço sidecar PostgreSQL.
O intervalo de 8 dias entre a divulgação e a confirmação de exploração ativa é preocupante, mas esperado. Com um PoC público disponível a partir do dia 15, os atacantes tiveram 3 dias para desenvolver variantes antes de qualquer organização ser oficialmente alertada para exploração real. Conforme documentado no Relatório Unit 42 2026, os atacantes roubam dados em média em 72 minutos após o acesso inicial. Para um RCE sem autenticação em plataforma SIEM, esse intervalo pode ser ainda mais curto.
Análise Técnica: O Sidecar PostgreSQL Sem Autenticação
O Splunk Enterprise integra um serviço sidecar de PostgreSQL para funções de armazenamento e recuperação de dados internos. Este serviço expõe endpoints de API interna que realizam operações de ficheiro no sistema de ficheiros do servidor. O problema central é desconcertantemente simples: esses endpoints não implementam qualquer controlo de autenticação a nível de aplicação.
Conforme descrito pelo watchTowr Labs, qualquer utilizador que consiga aceder ao serviço pela rede pode executar as seguintes operações sem credenciais: criar um ficheiro vazio em qualquer localização do sistema de ficheiros do servidor Splunk, ou limpar o conteúdo de qualquer ficheiro existente. O laboratório resumiu o achado com rigor técnico: “Tem tudo o que adoramos: sem requisitos de autenticação, uma primitiva quase completa.”
A Splunk confirmou no aviso SVD-2026-0603: “A vulnerabilidade existe porque o endpoint do serviço sidecar PostgreSQL carece de controlos de autenticação, permitindo que qualquer utilizador acessível pela rede invoque operações de ficheiro sem credenciais.” A empresa adicionou: “Nas versões do Splunk Enterprise abaixo de 10.2.4 e 10.0.7, um utilizador não autenticado pode criar ou truncar ficheiros arbitrários através de um endpoint do serviço sidecar PostgreSQL.”
Como a Primitiva de Escrita de Ficheiro Escala para RCE
A primitiva de criação e truncagem de ficheiros, isolada, já constitui uma ameaça grave de destruição de dados e interrupção de serviço. Mas investigadores da NetSPI demonstraram a cadeia completa até execução remota de código. O mecanismo envolve a função lo_export do PostgreSQL, que permite exportar dados de tabelas para ficheiros no sistema de ficheiros, e o comando COPY FROM PROGRAM, que executa comandos do sistema operativo com os privilégios do processo PostgreSQL.
A NetSPI sintetizou o impacto: “A falha origina-se num endpoint de serviço sidecar PostgreSQL que carece completamente de controlos de autenticação (CWE-306), permitindo que qualquer atacante acessível pela rede invoque operações arbitrárias de criação ou truncagem de ficheiros sem credenciais. Investigadores demonstraram que esta primitiva de escrita de ficheiro pode ser encadeada em execução remota de código abusando da função lo_export do PostgreSQL para escrever e executar scripts maliciosos no servidor Splunk.”
Os Endpoints Vulneráveis e o Workaround Técnico
O watchTowr Labs identificou os endpoints específicos usados na cadeia de exploração demonstrada:
POST /v1/postgres/recovery/backup
POST /v1/postgres/recovery/restoreA Orca Security sublinhou o risco para ambientes cloud e empresariais: “Devido ao potencial de comprometimento total da infraestrutura em ambientes empresariais e cloud, é necessário aplicar o patch imediatamente.” A empresa confirmou que a Splunk Cloud Platform em múltiplas versões é igualmente afetada, embora a gestão dos patches em instâncias cloud seja da responsabilidade da própria Splunk.
Versões Afetadas e Patches Disponíveis
A falha afeta um conjunto alargado de versões do Splunk Enterprise, Splunk Cloud Platform e da aplicação Splunk Secure Gateway. A tabela abaixo consolida todas as ramificações confirmadas como vulneráveis e as versões corrigidas correspondentes, com base no aviso oficial SVD-2026-0603 e nas análises independentes publicadas pela Orca Security:
| Produto | Versões Afetadas | Versão Corrigida |
|---|---|---|
| Splunk Enterprise 10.2 | 10.2.0 a 10.2.3 | 10.2.4 |
| Splunk Enterprise 10.0 | 10.0.0 a 10.0.6 | 10.0.7 |
| Splunk Enterprise 10.4 | Não afetado | 10.4.0 (base segura) |
| Splunk Enterprise 9.4 | 9.4.0 a 9.4.11 | 9.4.12 |
| Splunk Enterprise 9.3 | 9.3.0 a 9.3.12 | 9.3.13 |
| Splunk Cloud Platform 10.4.2604 | Abaixo de .3 | 10.4.2604.3 |
| Splunk Cloud Platform 10.3.2512 | Abaixo de .11 | 10.3.2512.11 |
| Splunk Cloud Platform 10.2.2510 | Abaixo de .14 | 10.2.2510.14 |
| Splunk Secure Gateway 3.10 | Abaixo de 3.10.6 | 3.10.6 |
| Splunk Secure Gateway 3.9 | Abaixo de 3.9.20 | 3.9.20 |
| Splunk Secure Gateway 3.8 | Abaixo de 3.8.67 | 3.8.67 |
A Splunk confirmou que não existem mitigações ou workarounds para a falha além de desativar o serviço sidecar PostgreSQL ou aplicar o patch. Para as versões do Splunk Cloud Platform, a Splunk aplica os patches diretamente sem intervenção do cliente, mas os clientes devem confirmar com a empresa se as suas instâncias específicas já foram atualizadas. A Picus Security confirmou que “o aviso não lista quaisquer mitigações ou workarounds, pelo que a aplicação do patch é a única defesa permanente.”
A Resposta da CISA: Prazo de 72 Horas para Agências Federais
A rapidez da CISA foi notável. A agência adicionou o CVE-2026-20253 ao catálogo KEV no mesmo dia em que a Splunk confirmou a exploração ativa, a 18 de junho, e definiu o prazo de remediação para 21 de junho de 2026. Setenta e duas horas para corrigir uma vulnerabilidade crítica numa plataforma SIEM de missão crítica é um prazo extremamente curto para a maioria das organizações com ambientes de produção complexos e processos de gestão de mudanças.
O catálogo KEV da CISA é vinculativo para agências do Poder Executivo Civil Federal (FCEB) dos EUA. Para organizações privadas, incluindo empresas europeias e portuguesas que operam infraestruturas críticas, o KEV funciona como um sinal de alerta de alta prioridade. A presença de um CVE no KEV indica exploração ativa confirmada, o que eleva o risco de qualquer instância não corrigida para um nível de urgência imediata. No contexto português, os requisitos da Diretiva NIS2, transposta para a legislação nacional em 2024, impõem obrigações de gestão de vulnerabilidades a operadores de serviços essenciais. Uma falha CVSS 9.8 com exploração ativa confirmada enquadra-se claramente nas categorias de incidente que devem ser comunicadas ao CNCS (Centro Nacional de Cibersegurança).
Para contexto adicional sobre como a CISA comunica alertas de vulnerabilidades críticas em infraestrutura empresarial, o caso do Oracle WebLogic e os 1.592 servidores expostos identificados pela CISA ilustra o padrão de resposta da agência a falhas de severidade máxima.
Outras Vulnerabilidades Divulgadas no Mesmo Dia
O CVE-2026-20253 não foi a única falha divulgada pela Splunk a 10 de junho. O pacote de junho de 2026 incluiu pelo menos três vulnerabilidades adicionais de severidade elevada que, em combinação, criam superfícies de ataque complementares:
- SVD-2026-0602 (SSRF): Falha de Server-Side Request Forgery no Splunk Enterprise, permitindo a um atacante com acesso autenticado forçar o servidor a realizar requisições HTTP para destinos internos. Em redes segmentadas, o SSRF pode ser usado para enumerar hosts internos inacessíveis diretamente.
- XSS Persistente no Splunk Secure Gateway: Vulnerabilidade de Cross-Site Scripting armazenado que pode ser explorada para roubo de tokens de sessão de administradores Splunk. Se combinada com o RCE do CVE-2026-20253, permite a um atacante com acesso limitado escalar para controlo total.
- SVD-2026-0610 (dependências de terceiros): Correção de múltiplas dependências de terceiros com CVEs conhecidos no Splunk Enterprise versões 10.4.0, 10.2.4, 10.0.7 e 9.4.12, classificada como Crítica pela Splunk.
A divulgação simultânea de múltiplas vulnerabilidades cria um dilema operacional para as equipas de segurança: enquanto o foco recai sobre a falha CVSS 9.8, a combinação de SSRF e XSS com o RCE pode criar cadeias de ataque ainda mais complexas. Um atacante que explore o SSRF para mapear a rede interna pode usar o RCE pré-autenticado para movimento lateral sem qualquer credencial prévia.
Mitigação Temporária: Como Desativar o Sidecar PostgreSQL
Para organizações que não conseguem aplicar o patch imediatamente, a Splunk disponibilizou uma mitigação temporária no aviso SVD-2026-0603. O procedimento envolve desativar o serviço sidecar PostgreSQL através de uma configuração no ficheiro server.conf. Este passo elimina o vetor de ataque sem atualizar a versão do Splunk Enterprise:
# Adicionar ao ficheiro $SPLUNK_HOME/etc/system/local/server.conf
[postgres]
disabled = true
# Reiniciar o Splunk Enterprise após guardar o ficheiro
$SPLUNK_HOME/bin/splunk restartA Splunk também referencia a documentação de “Sidecar Configuration Settings” e “Postgresql Configuration” para contexto adicional. A mitigação temporária tem custos funcionais claros: desativar o sidecar PostgreSQL afeta funcionalidades de recuperação de dados e backups integrados no Splunk Enterprise que dependem desse serviço. As organizações devem avaliar o impacto operacional antes de aplicar este workaround em ambientes de produção, e tratar esta medida como solução transitória enquanto o patch é preparado, testado e aprovado para implementação em produção.
Uma medida de proteção adicional, independentemente do patch ou workaround, é implementar regras de firewall que restrinjam o acesso ao serviço sidecar PostgreSQL exclusivamente a endereços IP de administração autorizados. Esta segmentação não elimina a vulnerabilidade, mas reduz drasticamente a superfície de ataque para ambientes que não expõem o Splunk diretamente à internet ou a segmentos de rede não confiáveis.
Splunk em Mira: Padrão de CVEs Críticos em 2026
O CVE-2026-20253 não surgiu num vácuo. Em março de 2026, a Splunk divulgou o CVE-2026-20166, uma vulnerabilidade de controlo de acesso impróprio que afeta o Splunk Enterprise e o Splunk Cloud Platform (SVD-2026-0305). Essa falha permite a utilizadores com privilégios baixos aceder a informação de outros utilizadores, com potencial para divulgação de dados sensíveis.
O padrão de duas vulnerabilidades de alta severidade em três meses sugere que a superfície de ataque do Splunk Enterprise permanece sob escrutínio intenso por parte da comunidade de investigação de segurança. Plataformas SIEM são alvos de alto valor por uma razão estrutural: comprometer o Splunk não significa apenas obter acesso ao servidor, mas obter visibilidade completa sobre todos os dados de segurança que a plataforma indexa, incluindo logs de autenticação, registos de acesso a bases de dados, alertas de firewall e eventos de endpoint de toda a infraestrutura monitorizada.
A Cisco concluiu a aquisição da Splunk em março de 2024, num negócio avaliado em 28 mil milhões de dólares, a maior aquisição da história da empresa. O Splunk tornou-se a espinha dorsal da estratégia de segurança da Cisco, integrado na plataforma Cisco Security Cloud. Esta integração amplifica o impacto de qualquer vulnerabilidade crítica: comprometer um servidor Splunk numa organização que usa a integração Cisco Security Cloud pode ter ramificações que ultrapassam em muito o servidor individual, potencialmente afetando a visibilidade de segurança em toda a infraestrutura cloud.
Comparação com Vulnerabilidades Críticas Recentes em Plataformas Empresariais
Para contextualizar a gravidade do CVE-2026-20253, a tabela abaixo compara-o com vulnerabilidades críticas recentes em plataformas de observabilidade, segurança e infraestrutura empresarial que geraram atenção significativa em 2026:
| CVE | Produto | CVSS | Tipo de Ataque | Autenticação Req. | CISA KEV | Exploração Ativa |
|---|---|---|---|---|---|---|
| CVE-2026-20253 | Splunk Enterprise / Cloud | 9.8 | RCE via ficheiro arbitrário | Não | Sim (Jun 2026) | Confirmada |
| CVE-2026-21962 | Oracle WebLogic | 10.0 | RCE remoto | Não | N/D | 140K ataques em 12 dias |
| CVE-2026-50751 | Check Point VPN | 9.3 | Execução de código | Baixa | N/D | Confirmada (Qilin) |
| CVE-2026-22813 | Cloudflare (interno) | 9.4 | RCE em pipeline Markdown | Não | N/D | Não pública |
| CVE-2026-20253 | Splunk Secure Gateway | 9.8 | XSS armazenado (XSS) | Baixa | N/D | Não confirmada |
O CVE-2026-20253 destaca-se pela combinação de CVSS 9.8, exploração ativa confirmada e entrada no catálogo KEV, a tríade mais perigosa do ponto de vista operacional. O Oracle WebLogic CVE-2026-21962 atingiu CVSS 10.0 com 140 mil ataques em 12 dias, mas o seu ecossistema de implementação é diferente do Splunk. Para administradores de plataformas SIEM, o CVE-2026-20253 é o incidente mais urgente do primeiro semestre de 2026.
O contexto mais amplo é pertinente. Conforme documentado no relatório DBIR 2026, 31% das fugas de dados tiveram origem em vulnerabilidades não corrigidas. O CVE-2026-20253 é precisamente o tipo de falha que alimenta essa estatística: alta severidade, exploração rápida após divulgação, e um prazo de remediação que muitas organizações não conseguem cumprir por restrições operacionais. A análise do ransomware sem encriptação que representa 44% das falhas em 2026 demonstra também que os atacantes modernos exploram vulnerabilidades para exfiltrar dados antes de qualquer encriptação.
Impacto Operacional: O Que Acontece Numa Organização Comprometida
A exploração bem-sucedida do CVE-2026-20253 tem implicações em múltiplas camadas simultâneas. A Ionix catalogou as consequências primárias: “destruição de dados, interrupção do serviço, ou facilitação de comprometimento adicional como escalada de privilégios ou execução remota de código através da sobrescrita de ficheiros sensíveis.” Mas as consequências secundárias são igualmente graves:
- Destruição de logs de segurança: Um atacante pode truncar ficheiros de log, eliminando evidências de atividade maliciosa anterior e “limpando” o rastro dentro do próprio sistema concebido para detetar ataques. A organização perde visibilidade histórica exatamente quando mais precisa dela.
- Implantação de backdoors persistentes: A criação de ficheiros arbitrários permite depositar scripts maliciosos em localizações que o processo Splunk executa automaticamente, garantindo persistência mesmo após reinicializações.
- Exfiltração de dados indexados: Com RCE, o atacante tem acesso completo aos dados indexados pelo Splunk, que incluem dados de toda a infraestrutura monitorizada, potencialmente meses ou anos de logs sensíveis.
- Comprometimento de credenciais armazenadas: As credenciais armazenadas no Splunk para conectores de dados (Active Directory, bases de dados, APIs cloud) tornam-se imediatamente acessíveis para movimento lateral.
- Cegueira de segurança: Uma organização cujo SIEM está comprometido perde a capacidade de detetar e responder a outros incidentes em simultâneo, criando uma janela de oportunidade para ataques adicionais.
O cenário mais crítico combina os últimos dois pontos: um atacante que comprometa o Splunk pode simultaneamente eliminar evidências da intrusão e usar as credenciais armazenadas para progredir para outros sistemas, enquanto a organização permanece cega porque o seu instrumento de deteção está comprometido. Este padrão foi documentado em múltiplos ataques de alto perfil contra infraestrutura crítica nos últimos anos.
5 Previsões para os Próximos 90 Dias
Com base na cronologia de eventos, na natureza técnica da vulnerabilidade e nos padrões históricos de exploração de falhas similares, os próximos 90 dias deverão trazer os seguintes desenvolvimentos:
- Exploração em massa antes do final de julho de 2026. Com um PoC público disponível no GitHub desde 15 de junho, grupos de ransomware e atores de estado-nação irão incorporar o CVE-2026-20253 nos seus arsenais. Plataformas de threat intelligence deverão registar campanhas de scanning ativo de instâncias Splunk vulneráveis em escala global, com explorações confirmadas em ambientes empresariais antes do final de julho.
- Setores financeiro e de saúde como alvos primários. As organizações que mais dependem do Splunk como SIEM principal incluem bancos, seguradoras e hospitais, todos com dados de alto valor e restrições operacionais que dificultam atualizações emergenciais. Estes setores serão os alvos preferenciais das primeiras campanhas de exploração ativa em larga escala, pelo que as equipas de segurança nessas indústrias devem tratar o patch como prioridade máxima.
- A Splunk introduzirá autenticação obrigatória no sidecar PostgreSQL nas versões futuras. A falha CWE-306 num endpoint de recuperação de dados é uma omissão arquitetural que a Cisco Splunk não pode repetir. A versão 10.4 já não é afetada por este CVE, o que sugere que a mudança de design foi introduzida nessa ramificação. A empresa deverá formalizar a autenticação do sidecar como requisito explícito na documentação de segurança e estendê-la retroativamente às versões de suporte longo prazo.
- Mais CVEs Splunk entrarão no catálogo KEV antes do final de 2026. O escrutínio intensificado sobre a plataforma após a divulgação pública de uma falha CVSS 9.8 gera invariavelmente novas investigações. Investigadores que analisaram o CVE-2026-20253 examinarão serviços adjacentes do Splunk Enterprise com a mesma metodologia, aumentando a probabilidade de novas divulgações de severidade elevada antes do final do ano.
- Aceleração de migrações para Splunk Cloud Platform gerida. A ironia é que o Splunk Cloud Platform também é afetado pelo CVE-2026-20253 em múltiplas versões. Mas o modelo gerido permite à Splunk aplicar patches sem intervenção dos clientes, com janelas de manutenção controladas. Organizações que operam Splunk Enterprise on-premises e que enfrentaram dificuldades para cumprir o prazo de 21 de junho irão acelerar avaliações de migração para o modelo cloud, onde o ciclo de remediação é estruturalmente mais rápido.
Cobertura Relacionada
Para aprofundar o contexto de vulnerabilidades críticas em infraestrutura empresarial e gestão de risco em 2026:
- Oracle WebLogic: CISA Alerta, 1.592 Servidores Expostos [2026]
- DBIR 2026: 31% das Fugas de Dados por Vulnerabilidades Não Corrigidas
- Relatório Unit 42 2026: Ciberataques Roubam Dados em 72 Minutos
- Ransomware Sem Encriptação: 44% das Falhas em 2026
- Decreto-Lei 125/2025: Portugal Protege Hackers Éticos com 8 Regras
Fontes primárias: Aviso Oficial Splunk SVD-2026-0603, watchTowr Labs (análise técnica completa), NetSPI (cadeia de exploração até RCE), Orca Security (impacto cloud), The Hacker News (cobertura noticiosa).
Perguntas Frequentes
O CVE-2026-20253 afeta o Splunk Cloud Platform?
Sim. O Splunk Cloud Platform é afetado em múltiplas versões: 10.4.2604 (abaixo de .3), 10.3.2512 (abaixo de .11), 10.2.2510 (abaixo de .14), 10.1.2507 (abaixo de .22) e 9.3.2411 (abaixo de .132). Em instâncias cloud geridas pela Splunk, os patches são aplicados pela própria empresa sem intervenção do cliente. No entanto, os clientes devem confirmar com a Splunk se as suas instâncias específicas já receberam a atualização, uma vez que o prazo de rollout pode variar por região e configuração.
Qual a diferença entre o CVE-2026-20253 e as outras vulnerabilidades divulgadas em 10 de junho?
O CVE-2026-20253 (SVD-2026-0603) é a única falha com CVSS 9.8 e sem requisito de autenticação no pacote de junho. As outras vulnerabilidades do mesmo conjunto incluem um SSRF (SVD-2026-0602) e um XSS persistente no Splunk Secure Gateway, ambos de severidade elevada mas que requerem algum nível de acesso autenticado ou interação do utilizador para exploração completa. O CVE-2026-20253 é o mais crítico porque não tem qualquer pré-requisito de exploração além de acesso de rede ao serviço.
É possível determinar se uma instância já foi comprometida antes do patch?
A dificuldade é precisamente que um atacante pode truncar ou eliminar os ficheiros de log do servidor Splunk, apagando evidências. A abordagem mais fiável é verificar os logs de acesso ao serviço PostgreSQL sidecar antes da aplicação do patch, procurando pedidos não autorizados aos endpoints /v1/postgres/recovery/backup ou /v1/postgres/recovery/restore. Se esses logs foram truncados ou apresentam lacunas temporais, há indicação de possível comprometimento. Em ambos os casos, uma análise forense independente é recomendável antes de restaurar operações normais.
Como posso verificar a versão atual do Splunk Enterprise instalada?
A versão pode ser verificada de duas formas: através da interface web em Configurações (Settings) > Sobre o Splunk (About Splunk), ou via linha de comandos com $SPLUNK_HOME/bin/splunk version. Para confirmar se a versão está corrigida, verifique se é igual ou superior a 10.2.4 (ramo 10.2), 10.0.7 (ramo 10.0), 9.4.12 (ramo 9.4) ou 9.3.13 (ramo 9.3). As organizações em versões 10.4 não são afetadas por este CVE específico.
O workaround de desativar o sidecar PostgreSQL tem impacto nas pesquisas do Splunk?
O workaround afeta especificamente funcionalidades que dependem do serviço sidecar PostgreSQL, incluindo certas operações de backup e recuperação de dados integradas no Splunk Enterprise. As pesquisas normais de log (SPL queries), dashboards e alertas não são afetados porque dependem do motor de indexação principal do Splunk, não do sidecar PostgreSQL. No entanto, qualquer funcionalidade que use explicitamente o backend PostgreSQL do Splunk ficará indisponível até à ativação do serviço ou aplicação do patch.
O CVE-2026-20253 é classificado como CWE-306. O que isso significa na prática?
O CWE-306, “Missing Authentication for Critical Function”, identifica situações em que um componente de software expõe funcionalidades críticas sem verificar a identidade do solicitante. No caso do CVE-2026-20253, o componente é o endpoint de recuperação do sidecar PostgreSQL e a funcionalidade crítica é a manipulação arbitrária de ficheiros no servidor. A gravidade é amplificada pelo contexto: o Splunk Enterprise é uma plataforma de missão crítica de segurança, e a ausência de autenticação num endpoint de gestão de dados compromete a integridade de toda a cadeia de confiança da plataforma. A ironia técnica é que o PostgreSQL em si tem um sistema robusto de autenticação, que os endpoints do sidecar ignoram completamente.
Que medidas devo tomar imediatamente se não consigo aplicar o patch hoje?
Três ações imediatas por ordem de prioridade: primeiro, implementar regras de firewall que restrinjam o acesso ao serviço sidecar PostgreSQL exclusivamente a endereços IP de administração autorizados; segundo, desativar o sidecar PostgreSQL via server.conf conforme descrito no aviso SVD-2026-0603; terceiro, monitorizar os logs de acesso para tentativas de acesso aos endpoints /v1/postgres/recovery/ como indicador de atividade de exploração. A aplicação do patch deve ser tratada como a única solução permanente e preparada para implementação com a maior urgência possível.
Publicado a 20 de junho de 2026. As informações sobre versões afetadas baseiam-se no aviso oficial SVD-2026-0603 da Splunk e em análises independentes da NetSPI, watchTowr Labs, Orca Security e Picus Security. Consulte sempre o aviso oficial para informações mais recentes.
