Checkmarx Jenkins AST Plugin Supply Chain Compromise: What TeamPCP’s Latest Attack Means for DevSecOps Teams

Cybersecurity news and practical guidance for developers, IT admins, and DevSecOps teams. A modified Checkmarx Jenkins AST plugin was published to the Jenkins Marketplace, adding another chapter to TeamPCP’s ongoing supply chain campaign. For teams that depend on Jenkins in CI/CD pipelines, this is not just another threat bulletin. It is a reminder that plugin trust, repository integrity, and secret rotation discipline all matter as much as code quality and build reliability.

Checkmarx confirmed that a modified version of its Jenkins AST plugin was published to the Jenkins Marketplace. The company warned users to ensure they are using version 2.0.13-829.vc72453fa_1c16 or an earlier version published on December 17, 2025. Since then, Checkmarx has released 2.0.13-848.v76e89de8a_053 on both GitHub and the Jenkins Marketplace, while noting it is still in the process of publishing a new version of the plugin.

The company has not disclosed how the malicious plugin version was published. But the incident fits an established pattern: TeamPCP has repeatedly targeted software supply chains to push credential-stealing malware into trusted developer tooling.

For most organizations, Jenkins is one of the most privileged systems in the software delivery stack. It often has access to source repositories, build credentials, deployment tokens, signing keys, cloud access keys, and secrets used by security tools. A compromised plugin can become a direct path to those assets.

This is why supply chain attacks are so dangerous: they do not always break into your environment through a loud intrusion. Instead, they slip into a trusted update, a dependency, or a plugin that your team assumes is safe. Once installed, malicious code can harvest secrets, tamper with builds, or quietly create persistence.

TeamPCP’s latest move is especially concerning because it follows earlier compromise activity against Checkmarx-related assets. According to the source reporting, the group was previously tied to a compromise of the KICS Docker image, two VS Code extensions, and a GitHub Actions workflow used to push credential-stealing malware. The same broader campaign also briefly impacted the Bitwarden CLI npm package.

That sequence matters. It suggests a persistent adversary that is not just testing one route but systematically exploiting the trust developers place in the tools they use every day.

Based on Checkmarx’s guidance, teams should treat the maliciously modified plugin publication as a risk indicator for any environment using versions newer than the one explicitly identified as safe in the company’s statement. The safest immediate interpretation is:

• Verify the exact plugin version installed in every Jenkins instance.
• Compare the installed plugin hash or package source against the official Checkmarx release channels.
• Assume any unverified build of the plugin could be unsafe until confirmed by the vendor.

Because plugin distribution happened through a trusted marketplace, normal “approved source” assumptions may not be enough. You need provenance checks, integrity checks, and version pinning.

If your organization uses the Checkmarx Jenkins AST plugin, act as though this is a time-sensitive security advisory. The following steps are practical, fast, and suitable for both developers and IT administrators.

1. Identify all Jenkins instances using the plugin

Search for Jenkins controllers and agents that have the Checkmarx Jenkins AST plugin installed. Include on-premises, cloud-hosted, ephemeral, and disaster recovery environments. Many teams have a primary Jenkins instance plus legacy or test instances that are easy to forget.

2. Record the exact version and installation source

Document the plugin version, installation date, and whether it was installed from the Jenkins Marketplace, a mirrored repository, or a manual artifact. If you have artifact logging or configuration management records, pull them now.

3. Compare against known-good releases

Check whether your environment is on the version Checkmarx identified as safe in its statement, and then confirm whether your environment has already moved to the newly released 2.0.13-848.v76e89de8a_053 or another officially verified release. Use only authoritative vendor and marketplace sources for confirmation.

4. Remove or disable anything unverified

If you cannot verify the provenance of the currently installed plugin, disable it first and remove it if necessary. Do not keep a potentially compromised plugin active just because it is embedded in a pipeline. A temporary outage is usually preferable to a credential theft incident.

5. Rotate secrets used by Jenkins

Because TeamPCP’s broader activity has focused on credential theft, assume any secrets reachable by Jenkins may be exposed if the malicious plugin executed. Rotate:

• API tokens
• Cloud credentials
• Service accounts
• Signing keys
• Vault or secrets-manager access tokens
• Git credentials and deploy keys

Prioritize secrets with broad access or long-lived validity.

6. Review audit logs and build history

Look for unusual plugin activity, unexpected outbound connections, new jobs, altered pipeline steps, or suspicious authentication attempts. Review recent build logs for environment variable leakage, failed credential access, or unexpected downloads.

7. Watch for downstream compromise

If the plugin was active, the blast radius may extend beyond Jenkins itself. Search for suspicious use of tokens in GitHub, GitLab, cloud consoles, artifact repositories, and package registries. A stolen token often becomes a second-stage compromise.

Not every supply chain incident is obvious immediately. In many cases, defenders discover problems only after credentials start being used elsewhere. Watch for these warning signs:

• Unexpected logins from unfamiliar IP ranges
• Newly created access keys or OAuth apps
• Pipeline changes you did not approve
• Build agents reaching out to unusual domains
• Secrets appearing in logs or error messages
• Package publishes or repository changes that do not match normal release patterns

If any of these occur around the time the plugin was installed or updated, escalate quickly and treat it as a potential incident.

TeamPCP’s activity reflects a broad and increasingly common attack model: compromise the development stack where trust is high, access is centralized, and secrets are plentiful. The source reporting notes that the group appears to have reused access or found new entry points after the earlier Checkmarx response. That implies one of two possibilities: either the initial remediation did not fully remove the attacker’s access, or the group maintained a foothold that was not identified during the earlier incident response.

For defenders, the lesson is simple. If an attacker gets into a software vendor’s publishing pipeline, the consequences may show up everywhere customers consume the software. That includes build servers, IDE extensions, container images, package registries, and automation workflows.

This also makes supply chain defense a practical consumer security issue for technology teams: the same trust that keeps development moving fast can be used against you when update channels are abused.

Use the checklist below if your team thinks it may have been exposed:

1. Containment: Disable the plugin and pause sensitive pipeline jobs.
2. Verification: Confirm installed versions across all Jenkins instances.
3. Preservation: Save logs, plugin manifests, and job configurations for analysis.
4. Credential review: Identify every secret accessible from Jenkins and prioritize rotation.
5. Access review: Revoke unused tokens, temporary credentials, and stale service accounts.
6. Endpoint review: Check build agents and controllers for signs of malware or persistence.
7. Outbound traffic review: Investigate DNS, proxy, and firewall logs for suspicious connections.
8. Communication: Notify teams that rely on Jenkins for deployments, releases, or signing operations.
9. Recovery: Reinstall from trusted sources and restore only after validation.
10. Post-incident hardening: Tighten plugin approval, secret scoping, and change-control processes.

Supply chain attacks work because software teams often optimize for speed and convenience. The answer is not to stop using plugins, but to reduce the amount of trust each plugin receives.

• Pin plugin versions and review updates before rollout.
• Restrict who can install or approve plugins.
• Use least-privilege service accounts for builds and integrations.
• Store secrets in a dedicated secrets manager rather than inline pipeline variables when possible.
• Separate build, test, and release permissions so one compromise does not expose everything.
• Audit plugin inventory regularly and remove anything unused.
• Alert on unusual outbound network behavior from Jenkins controllers and agents.
• Require code review for pipeline changes that touch credentials or deployment logic.

These controls will not eliminate every risk, but they make it much harder for a malicious plugin to turn a single foothold into a full environment compromise.

If you manage multiple Jenkins deployments, verification must be systematic. Start by inventorying every instance and comparing the plugin list to approved baselines. Then confirm the source of each plugin package. If your team uses internal mirrors, verify whether the mirrored artifact was synchronized before or after the compromise window.

When in doubt, treat the plugin as untrusted until you can confirm the package, checksum, and release path from a reliable vendor source. If you operate in a regulated environment, preserve evidence of your validation process for audit purposes.

For more guidance on adjacent attack patterns, see our analysis of enterprise playbooks for voice and video-based business email compromise in Deepfakes at Scale: Building Enterprise Playbooks for Voice and Video‑Based Business Email Compromise, and our review of hardening against leaked listings in Directories, Data Brokers and Discovery: Hardening Against Class‑Action Risks From Leaked Listings. If you are looking at broader operational prioritization, When Market Signals Mask Cyber Risk: Using Financial Red Flags to Prioritise Security Audits is also relevant.

The Checkmarx Jenkins AST plugin incident is another reminder that the software supply chain is now a frontline security concern. For DevSecOps teams, the response should be immediate: verify plugin versions, remove anything untrusted, rotate secrets, and inspect Jenkins for signs of misuse. For the broader industry, TeamPCP’s repeated targeting of developer tooling shows that trusted update channels can no longer be assumed safe by default.

If your workflows depend on Jenkins, treat this as more than a vendor issue. It is a reminder to build every pipeline as if it may one day become the target.