Plugin Jenkins AST da Checkmarx teve versão modificada publicada no Jenkins Marketplace

Incidente ligado ao TeamPCP envolve acesso não autorizado ao repositório do plugin, publicação alterada no ecossistema Jenkins e suspeita de credenciais herdadas de ataque anterior à cadeia de software.

Componente	Plugin Checkmarx Jenkins AST distribuído pelo Jenkins Marketplace e mantido em repositório no GitHub.
Vetor	Publicação de uma versão modificada após acesso não autorizado ao repositório do plugin, com suspeita de uso de credenciais obtidas em ataque anterior à cadeia de software.
Impacto	Ambientes Jenkins que instalaram ou atualizaram o plugin afetado ficam expostos a código não confiável em um ponto de execução usado por pipelines de desenvolvimento e segurança de aplicações.
Prioridade	Validar a versão instalada, evitar versões posteriores a 2.0.13-829.vc72453fa_1c16 publicadas antes da correção e atualizar para 2.0.13-848.v76e89de8a_053 quando a origem for confirmada.
Versões	A versão 2.0.13-829.vc72453fa_1c16, publicada em 17 de dezembro de 2025 ou anteriormente, foi indicada como referência segura; a versão 2.0.13-848.v76e89de8a_053 foi publicada depois no GitHub e no Jenkins Marketplace para endereçar o incidente.
Artefatos	Repositório renomeado para Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now, além de menção a compromissos anteriores envolvendo imagem Docker do KICS, extensões do VS Code, fluxo do GitHub Actions e pacote npm do Bitwarden CLI.

Resumo técnico

A Checkmarx confirmou que uma versão modificada do plugin Checkmarx Jenkins AST foi publicada no Jenkins Marketplace, transformando um componente de integração de segurança de aplicações em um possível vetor de cadeia de suprimentos. O plugin é usado em ambientes Jenkins para integrar verificações AST aos fluxos de build e entrega, o que o coloca em uma posição sensível: ele roda dentro de um servidor de automação que costuma ter acesso a código-fonte, tokens de integração, variáveis de ambiente, artefatos de build e credenciais de serviços internos. Quando um plugin nesse ponto de execução é alterado fora do fluxo legítimo de manutenção, o risco não se limita ao host Jenkins; ele alcança os projetos que dependem desses pipelines, os segredos disponíveis durante a execução e os sistemas externos chamados pelo processo de CI/CD.

A orientação técnica vinculada ao incidente é verificar se o ambiente está usando a versão 2.0.13-829.vc72453fa_1c16, publicada em 17 de dezembro de 2025 ou anteriormente, ou migrar para a versão 2.0.13-848.v76e89de8a_053, disponibilizada depois no GitHub e no Jenkins Marketplace para tratar as preocupações associadas ao caso. A avaliação apresentada para o incidente indica que o código malicioso teria sido publicado após obtenção de credenciais em um ataque anterior à cadeia de software ocorrido em março de 2026. Esse detalhe muda a prioridade defensiva: a resposta não deve se limitar à substituição do plugin, porque credenciais reutilizadas, tokens não rotacionados e permissões amplas em repositórios podem permitir nova publicação indevida mesmo após a remoção de uma versão comprometida.

Fluxo técnico

O fluxo provável começa com o acesso não autorizado ao repositório do plugin no GitHub. O repositório associado ao Checkmarx Jenkins AST foi renomeado para Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now e recebeu uma descrição afirmando falha na rotação de segredos. Esse tipo de alteração indica controle suficiente para modificar metadados do projeto e, potencialmente, alterar conteúdo versionado, artefatos ou etapas de publicação. Em uma cadeia Jenkins, a etapa crítica é a transição entre código no repositório, empacotamento do plugin e distribuição pelo Jenkins Marketplace. Se credenciais de publicação, chaves de automação ou tokens de mantenedor forem comprometidos, um atacante pode inserir uma versão adulterada em um canal que administradores tratam como confiável.

A atribuição operacional recai sobre o TeamPCP, grupo associado desde março de 2026 a uma sequência de compromissos em cadeia de software. Antes deste episódio, a atividade foi ligada à imagem Docker do KICS, a duas extensões do VS Code e a um fluxo do GitHub Actions usado para empurrar malware de roubo de credenciais. Esse encadeamento também resultou no comprometimento breve do pacote npm do Bitwarden CLI, com distribuição de um stealer capaz de coletar diferentes tipos de segredos de desenvolvedores. Para o caso específico do plugin Jenkins AST, não foram informados hashes, nomes de arquivos alterados, comandos executados, endereços de infraestrutura ou detalhes públicos do payload inserido. A ausência desses artefatos exige uma resposta baseada em escopo, versão, origem do pacote, histórico de instalação e exposição de credenciais acessíveis pelo Jenkins.

Superfície afetada

A superfície afetada inclui servidores Jenkins que instalaram o Checkmarx Jenkins AST por meio do Jenkins Marketplace ou por artefatos derivados do repositório comprometido. O risco aumenta quando o Jenkins executa builds com segredos injetados em variáveis de ambiente, credenciais armazenadas no Jenkins Credentials Provider, tokens de acesso a GitHub, GitLab, registries de contêineres, repositórios de pacotes, scanners de segurança, cofres de segredos e plataformas de nuvem. Mesmo quando o plugin não possui permissões administrativas explícitas, ele opera no mesmo ambiente de automação onde tarefas de build e análise podem acessar arquivos de trabalho, logs, parâmetros de execução e conexões de rede liberadas para o pipeline.

Também entram no escopo contas de mantenedor, chaves de assinatura, tokens de publicação e credenciais usadas para sincronizar releases entre GitHub e Jenkins Marketplace. O histórico do TeamPCP sugere preferência por pontos de confiança já aceitos por desenvolvedores: imagens de contêiner, extensões de IDE, fluxos de automação e pacotes de ecossistemas populares. Em organizações que integram scanners AST a gates de segurança, a execução do plugin pode ocorrer em múltiplos projetos e ramos, o que amplia a necessidade de mapear jobs acionados durante a janela de exposição e não apenas servidores que ainda estejam com a versão modificada instalada.

• Instalações do Checkmarx Jenkins AST em controladores Jenkins e agentes que executam pipelines com acesso a código-fonte ou segredos de build.
• Pipelines que consumiram versões do plugin posteriores a 2.0.13-829.vc72453fa_1c16 antes da disponibilização de 2.0.13-848.v76e89de8a_053.
• Credenciais de CI/CD, tokens de repositório, chaves de publicação, variáveis protegidas e segredos usados por jobs que executaram durante a janela de risco.
• Ambientes que já haviam consumido artefatos relacionados à campanha, como imagem Docker do KICS, extensões do VS Code, fluxo do GitHub Actions ou pacote npm do Bitwarden CLI.

Hunting e telemetria

A investigação deve começar pelo inventário de plugins Jenkins. Administradores precisam extrair a versão instalada do Checkmarx Jenkins AST, identificar quando ela foi baixada, qual repositório de atualização foi usado e quais jobs foram executados depois da instalação ou atualização. Em Jenkins, a telemetria útil costuma estar distribuída entre logs do controlador, logs de agentes, histórico de builds, console output dos jobs, registros de instalação de plugins, metadados em $JENKINS_HOME/plugins, configurações exportadas por configuration-as-code e trilhas de auditoria de autenticação. A análise deve correlacionar a atualização do plugin com mudanças em credenciais, falhas incomuns de build, novas conexões externas e execuções fora do padrão em projetos que usam AST.

Para repositórios e identidades, o hunting deve revisar eventos de renomeação, alteração de descrição, publicação de release, criação ou uso de tokens, mudanças em permissões de mantenedor e execuções de GitHub Actions próximas ao período do incidente. Como a hipótese técnica envolve credenciais obtidas anteriormente, logs de identidade são tão importantes quanto logs de endpoint: autenticações de locais não usuais, uso de tokens antigos, criação de chaves de deploy e chamadas de API para publicação de artefatos podem indicar persistência operacional. Como não há IoCs públicos suficientes no material divulgado, a detecção deve ser comportamental e baseada em desvio: versão inesperada, artefato instalado fora de janela aprovada, conexão de pipeline para destinos não reconhecidos e acesso a segredos sem correspondência com o job esperado.

• Listar a versão do Checkmarx Jenkins AST em todos os controladores Jenkins e comparar com 2.0.13-829.vc72453fa_1c16 e 2.0.13-848.v76e89de8a_053.
• Revisar logs de instalação e atualização de plugins, incluindo data, usuário administrativo, origem do update center e alterações em $JENKINS_HOME/plugins.
• Correlacionar builds executados após a atualização suspeita com acesso a credenciais, variáveis sensíveis, publicações em registries e chamadas de rede externas.
• Auditar eventos do GitHub relacionados ao repositório do plugin, incluindo renomeação, alteração de descrição, releases, tokens de automação e permissões de mantenedores.
• Procurar uso anômalo de segredos de CI/CD em GitHub, registries de contêineres, npm, sistemas de nuvem e ferramentas de segurança integradas ao Jenkins.

Mitigação

A resposta deve priorizar contenção de cadeia de suprimentos. O primeiro passo é congelar atualizações automáticas do plugin em ambientes críticos, inventariar as versões instaladas e remover qualquer artefato cuja origem ou versão não possa ser validada. Instalações ainda baseadas em versão posterior à referência 2.0.13-829.vc72453fa_1c16 devem ser analisadas antes de simples substituição, porque a troca do plugin pode apagar evidências locais relevantes. Depois da coleta mínima de logs, metadados e cópias dos artefatos instalados, a atualização para 2.0.13-848.v76e89de8a_053 deve ser feita a partir de canal verificado, seguida de reinicialização controlada do Jenkins e reexecução de jobs de validação em ambiente segregado.

A mitigação completa exige rotação de credenciais expostas ao Jenkins e revisão das permissões de publicação ligadas ao ecossistema afetado. Tokens de repositório, credenciais de registries, chaves de deploy, segredos de nuvem e credenciais de scanners devem ser tratados como potencialmente acessíveis se estiveram disponíveis a jobs executados durante a janela de risco. Também é necessário revisar lockfiles, caches de agentes, workspaces persistentes, artefatos de build e imagens de contêiner geradas no período, pois um comprometimento em CI/CD pode contaminar saídas mesmo depois que o componente inicial é corrigido. Para reduzir reincidência, equipes devem aplicar menor privilégio a plugins, limitar egress de agentes, exigir aprovação para instalação de plugins, monitorar alterações em update centers e manter auditoria de publicação para repositórios e marketplaces.

• Coletar evidências antes da troca: versão instalada, arquivo do plugin, logs do controlador, histórico de builds e registros de atualização.
• Atualizar para 2.0.13-848.v76e89de8a_053 a partir de GitHub ou Jenkins Marketplace verificados, ou retornar temporariamente à versão 2.0.13-829.vc72453fa_1c16 quando a correção ainda não puder ser aplicada.
• Rotacionar segredos acessíveis por jobs que executaram com o plugin suspeito, incluindo tokens Git, credenciais de registries, chaves de nuvem e segredos de ferramentas AST.
• Invalidar caches e workspaces persistentes em agentes Jenkins, principalmente quando builds manipularam código-fonte, pacotes, imagens Docker ou artefatos de publicação.
• Revisar permissões de mantenedores, tokens de automação e fluxos de release para impedir nova publicação por credenciais reaproveitadas ou não revogadas.