Alerta de segurança Splunk vulnerabilidade crítica CVE-2026-20253 que poderia permitir execução remota de código

Splunk publicou adesivos críticos para uma falha em Splunk Enterprise que, segundo a empresa e os pesquisadores que analisaram o problema, permite realizar operações de arquivo sem autenticação e potencialmente escalar até execução remota de código. Identificada como CVE-2026-20253 e com pontuação CVSS de 9.8, a vulnerabilidade localiza-se no serviço "PostgreSQL sidecar" que algumas instalações on-premises usam junto com Splunk Enterprise e que carece de controles de autenticação em certos endpoints.

O risco é alto por duas razões: primeiro, qualquer usuário com acesso de rede a esse serviço pode invocar funções de cópia/recuperação de bases de dados sem credenciais; segundo, a sequência de operações permitidas (volcar um dump, repor e invocar funções da base de dados) oferece uma primitiva de escrita arbitrária no sistema de arquivos, que por sua vez pode se converter em execução de código se um programa que Splunk executa regularmente. Splunk indica que as versões afetadas são 10. 0. 0 a 10. 0. 6(corrida em 10.0.7) e 10.2.0 a 10.2.3(corregido em 10.2.4); Splunk Enterprise 10.4 não está afetada e Splunk Cloud também não usa esses sidecars, pelo que não se vê impactada.

Os detalhes técnicos publicados por pesquisadores mostram como, ao usar os endpoints de backup/restore do sidecar, um atacante pode dropear um volcado controlado por ele no host alvo e provocar que a instância local de PostgreSQL execute sentenças definidas nesse dump. Entre essas sentenças pode-se incluir a criação de funções que chamem a utilidades como lo_export para extrair BLOBs e escrever arquivos em rotas do sistema, por exemplo, descrevendo scripts Python que Splunk carrega automaticamente, tornando uma escrita arbitrária em execução remota de código.

Embora até agora não haja evidência pública de exploração massiva em ambientes produtivos, a publicação do método torna esta vulnerabilidade atraente para atores oportunistas. Por isso as organizações devem agir rapidamente: o tempo entre a disponibilidade de um exploit funcional e as tentativas de abuso pode ser muito curto.

A primeira e mais importante medida é aplicar os adesivos oficiais: atualizar para 10. 0. 7 ou 10.2.4(ou outra versão mais recente que já inclua a correção). Splunk mantém avisos de segurança e notas de versão onde explicar a mitigação e os builds afetados; é recomendável seguir o guia do fornecedor e baixar as fixes de fontes oficiais. Você pode consultar o repositório de avisos de Splunk e a entrada do CVE em bases públicas como a NVD para confirmar detalhes técnicos e seguimento do CVE: Splunk Security Notices e NVD - CVE-2026-20253.

Se por alguma razão não for possível atualizar imediatamente, existem atenuações compensatórias que reduzem a superfície de ataque: bloquear o acesso de rede ao serviço PostgreSQL sidecar mediante regras de firewall e segmentação, limitar a exposição dos endpoints de backup/restore a redes internas de gestão e aplicar listas de controle de acesso para que só hosts conhecidos e confiáveis possam se conectar. Além disso, impedir que instâncias Splunk possam abrir conexões salientes a bases de dados controladas por terceiros evita uma parte do vetor usado pelos pesquisadores.

Em paralelo ao adesivo ou isolar, é imprescindível buscar sinais de comprometimento. É conveniente inspecionar integridade e mudanças em rotas críticas como /opt/splunk (especialmente arquivos e scripts em etc/apps/*/bin), rever logs internos e de auditoria em busca de chamadas aos endpoints de recuperação ou de atividades de dump/restore, e monitorar processos e conexões de PostgreSQL que apontem para bases de dados externas. Se forem identificadas alterações não autorizadas, as máquinas afectadas devem ser isoladas e tratadas de acordo com procedimentos de resposta a incidentes, incluindo a restauração de cópias limpas e a rotação de credenciais associadas.

Finalmente, este incidente lembra duas lições operacionais: a primeira, nunca expor serviços de administração ou sidecars sem controles de acesso robustos; a segunda, complementar o adesivo com controles de detecção e segmentação de rede que impeçam que uma primitiva de arquivo ou base de dados se torne execução remota de código. Manter o inventário actualizado de componentes e uma política de revisão de alterações nos arquivos executáveis reduz a capacidade de um atacante persistir silenciosamente após uma intrusão.

A recomendação-chave é clara: Actualizar Agora, bloquear o acesso aos sidecars se não puder ser corrigido imediatamente, e realizar uma busca proativa de indicadores de abuso nos ambientes afetados. Para detalhes técnicos adicionais e seguimento do estado do adesivo, consulte as páginas oficiais indicadas e as publicações dos pesquisadores que analisaram a falha.