Quando um plugin de Jenkins se torna porta traseira o caso Checkmarx expõe credenciais e a segurança da cadeia de abastecimento

Durante o fim de semana Checkmarx confirmou que uma versão maliciosa do seu plugin Jenkins para Application Security Testing (AST) foi publicada no Marketplace de Jenkins, no que se soma a uma cadeia de incidentes que já inclui vazamentos e artefatos troceados no GitHub, Docker e marketplaces de extensões. A atoria conhecida como TeamPCP aproveitou credenciais obtidas em uma lacuna prévia —vinculada ao incidente contra Trivy — para inserir código com capacidade de roubo de credenciais em várias ferramentas de desenvolvimento, incluindo uma versão do plugin de Checkmarx subida fora do seu canal oficial. A nota oficial da empresa pode ser consultada com os detalhes e recomendações iniciais no seu comunicado público: Checkmarx security update.

Jenkins é um pilar em muitos pipelines CI/CD e qualquer componente que se integre em seu fluxo de trabalho tem acesso, em maior ou menor medida, a segredos, artefatos de build e credenciais de implantação. Um plugin backdooreado não só pode exfiltrar tokens e credenciais armazenadas no ambiente do build, mas também atuar como vetor para movimentos laterais e persistência dentro da infraestrutura de desenvolvimento. A versão suspeita publicada foi identificada como 2026.5.09 e, segundo Checkmarx, não seguiu o procedimento normal de releases (sem git tag ou release oficial), enquanto a empresa recomenda manter, no possível, a versão segura 2.0.13-829.vc72453fa_1c16 ou uma anterior até que a remediação completa seja confirmada. O plugin oficial no repositório de Jenkins pode ser revisto aqui: Checkmarx AST plugin.

Além do impacto pontual, este incidente sublinha dois pontos críticos: a fragilidade das credenciais persistentes em repositórios e a necessidade de validar cada artefato que entra na pipeline. Quando uma credencial é filtrada em um elo da cadeia de abastecimento, o atacante pode pivotar múltiplos vetores (repos, images, extensões) e manter acesso por longos períodos se não forem quebrados e revogados segredos. A mensagem deixada pelos atacantes — acusando a falta de rotação de segredos — é um lembrete cru: as rotações periódicas e a gestão com políticas de caducidade são controle básico, mas frequentemente negligenciado.

Se você administra Jenkins ou integra o plugin comprometido, assume que qualquer segredo que passou pelos jobs pode estar comprometido. As ações imediatas devem incluir identificar e pôr em quarentena instâncias que tenham instalado a versão 2026.5.09, rotar todos os segredos e credenciais expostas, revogar tokens e chaves associadas a repositórios e sistemas de CI/CD, e procurar evidências de exfiltração ou persistência. Checkmarx publicou indicadores de compromisso (IoCs) e artefatos maliciosos que as equipes de resposta podem usar para investigar; revisa seu portal de segurança e comunicações oficiais para obter essas amostras e assinaturas.

Na parte operacional, convém rever os pipelines em busca de acessos incomuns, comandos ou downloads externos executados por jobs, e auditar logs do GitHub, Docker Registry e sistemas de empacotamento. Revocar e voltar a emitir credenciais com mais restrições (cope limitado, caducidade curta), substituir credenciais persistentes por mecanismos de identidade federada temporária (por exemplo OIDC onde for aplicável) e reforçar a segregação de ambientes são medidas imediatas para reduzir o blast radius. Além disso, a verificação de integridade de artefatos (firmas, checksums, reprodutível builds) e a preferência por artefatos assinados na pipeline dificultam a aceitação automática de pacotes não autorizados.

A médio e longo prazo, as organizações devem elevar sua higiene de segurança na cadeia de fornecimento: implementação sistemática de políticas para tokens de máquina em repositórios, bloqueio de credenciais nas histórias, revisão de permissões em contas de serviço, e auditorias regulares a terceiros e canais de publicação de plugins e pacotes. É também o momento de questionar processos de desenvolvimento que permitem publicar artefatos críticos sem revisões de segurança independentes ou sem controles de assinatura e rastreabilidade. Para seguir o rastro técnico do compromisso por parte de pesquisadores independentes, pode-se consultar a evidência pública compartilhada por analistas e responsáveis pela divulgação, incluindo o fio documentado pelo pesquisador que identificou a atividade no GitHub: Adnan Khan em X.

Finalmente, embora o Checkmarx garanta que os seus repositórios não contêm dados de clientes e que o ambiente de desenvolvimento está separado do ambiente de produção, as organizações devem agir como se tivessem sido afetadas se instalaram o plugin comprometido e realizar uma resposta completa: detecção, contenção, erradicação e aprendizagem. A cadeia de suprimentos software é agora um objetivo preferencial; reduzir a exposição exige tanto mudanças técnicas como disciplina operacional contínua.