What Happened
On May 9, 2026, TeamPCP published a compromised version of the Checkmarx Jenkins AST plugin to the official Jenkins Marketplace. This malicious plugin contained info-stealing malware, exploiting credentials stolen from an earlier breach. TeamPCP didn't hack in—they used keys taken from a previous victim.
This incident is a credential reuse attack, turning one organization's security lapse into a supply-chain compromise affecting every Jenkins user who downloaded the malicious plugin.
Timeline
Before May 9, 2026: TeamPCP compromised an unknown target and exfiltrated credentials with access to Checkmarx's Jenkins plugin publishing account.
May 9, 2026: Malicious plugin version published to Jenkins Marketplace using stolen credentials.
Post-publication: An unknown number of Jenkins instances downloaded and installed the compromised plugin. Each installation executed the info-stealer in the context of the Jenkins service account—typically a highly privileged account with access to source code, deployment credentials, cloud provider keys, and internal network resources.
The specific detection timeline and remediation details are not publicly available.
Which Controls Failed or Were Missing
Credential Rotation: The stolen credentials remained valid long enough for TeamPCP to use them in a secondary attack. This suggests either no rotation policy or a rotation interval measured in months rather than days.
Multi-Factor Authentication on Publishing Accounts: If MFA was required for plugin publication, stolen credentials alone wouldn't have granted access. The unauthorized publication suggests either no MFA requirement or a bypassable implementation.
Code Signing and Verification: The malicious plugin was published without triggering integrity checks. Either the Jenkins Marketplace didn't verify plugin signatures against known-good baselines, or TeamPCP's access allowed them to sign malicious code as legitimate.
Anomaly Detection: A dormant or predictable publishing account suddenly publishing a new version should trigger a review. No automated alerting appears to have prevented publication.
Least Privilege for Service Accounts: The info-stealer's value depends on what the Jenkins service account could access. Organizations running Jenkins with overprivileged service accounts increased their exposure.
What the Relevant Standard Requires
NIST 800-53 Rev 5, IA-5(1): Organizations must enforce password-based authentication requirements, including "a minimum password lifetime of 24 hours and a maximum password lifetime of 60 days." For high-value accounts like plugin publishers, this means mandatory credential rotation at least every 60 days. Many organizations implementing zero-trust architectures rotate credentials daily or use short-lived tokens.
NIST 800-53 Rev 5, IA-2(1) and IA-2(2): Multi-factor authentication is required for network access to privileged accounts and non-privileged accounts. A plugin publishing account with the ability to distribute code to thousands of organizations qualifies as privileged. The control specifically requires MFA "using something you know, something you have, and something you are."
NIST 800-53 Rev 5, CM-3: Configuration change control requires documented approval and verification before implementing changes. Publishing a new plugin version is a configuration change. Organizations should require code review, approval workflow, and integrity verification before publication—not just credential-based authentication.
ISO/IEC 27001:2022, A.8.3: Media handling controls require organizations to protect media containing information during transport. Credentials are information. When credentials are compromised, the organization must treat them as potentially exposed media and invalidate them immediately. The gap: most organizations don't discover credential exposure until attackers use them.
PCI DSS v4.0.1, Requirement 8.3.2: "Interactive login to the CDE is secured with MFA." While plugin publication isn't technically "interactive login," the principle applies: any authentication to a system that can affect cardholder data environments should require MFA. If your Jenkins instance deploys payment applications, the plugin publishing account is in scope.
Lessons and Action Items for Your Team
Implement Token-Based Authentication with 24-Hour Expiration: Replace long-lived credentials for CI/CD publishing accounts with short-lived tokens. GitHub, GitLab, and most modern registries support token-based authentication with configurable expiration. Set tokens to expire every 24 hours and automate renewal through your secrets management system.
Require Hardware MFA for All Publishing Accounts: Software-based MFA (authenticator apps) is better than nothing, but hardware tokens (YubiKey, Titan) resist phishing and malware. Your plugin publishing account, container registry credentials, and package manager tokens should all require hardware MFA.
Monitor Plugin/Package Integrity with Baseline Hashing: Before you install or update any plugin, verify its hash against the publisher's official signature. Automate this check in your Jenkins configuration-as-code. If the hash doesn't match, block installation and alert your security team. Tools like Sigstore and in-toto provide frameworks for software supply chain verification.
Scope Jenkins Service Accounts to Minimum Required Access: Your Jenkins service account doesn't need admin rights to your cloud provider, read access to every repository, or credentials to production databases. Create separate service accounts for each pipeline with access scoped to exactly what that pipeline deploys. If an info-stealer compromises Jenkins, it should capture credentials for dev environments, not production.
Enable Audit Logging on All Publishing Platforms: Every plugin publication, package upload, or container push should generate an audit log entry with timestamp, source IP, and authentication method. Forward these logs to your SIEM and create alerts for publications outside business hours or from unexpected geographic locations. The goal: detect compromise within minutes, not months.
Treat Credential Exposure as an Active Breach: When you discover exposed credentials—in public GitHub repos, in logs, in memory dumps—assume they're already compromised. Rotate them immediately, review access logs for unauthorized use, and scan for indicators of compromise in systems those credentials could access. The window between exposure and exploitation is shrinking.
Test Your Supply-Chain Verification: Run a tabletop exercise where you simulate a compromised plugin. Can your team detect it? How long until someone notices? What's the rollback procedure? Document the gaps and fix them before you face a real incident.
TeamPCP succeeded because they exploited the gap between credential compromise and detection. Your action items should close that gap: shorter credential lifetimes, stronger authentication, automated verification, and faster detection. Supply-chain attacks work by chaining together small security gaps. Break the chain.
