Inside 2026's Wave of Developer Supply-Chain Attacks
TeamPCP poisoned a Checkmarx Jenkins plugin using credentials from an earlier breach, while Datadog found 87% of organizations run known-exploitable vulnerabilities. A look at the attacks, the data, and the defenses that work.
In May 2026, attackers didn't break into developers' machines. They got the developers to install them. A cybercrime group calling itself TeamPCP poisoned a Checkmarx Jenkins plugin, defaced a GitHub repository with the taunt "Checkmarx fails to rotate secrets again," and used credentials lifted from an earlier breach to pull it off. It's a near-perfect illustration of where software risk now lives: not in the code you write, but in the code, containers, and CI plugins you trust by default.
That single incident sits on top of a much larger, quieter problem. Datadog's State of DevSecOps 2026 found that 87% of organizations are running at least one known, exploitable vulnerability in a deployed service. Most teams aren't being targeted by a clever group like TeamPCP — they're quietly exposed by dependencies that drifted out of date and pipelines nobody hardened. This piece walks through both: the attack that made headlines, the data that should worry you more, and the concrete steps that actually move the needle.
The TeamPCP campaign: a breach that kept breaching
The most detailed public account comes from The Hacker News, which documented how TeamPCP compromised Checkmarx's developer-facing supply chain — and did it more than once.
The Jenkins angle is the headline. A malicious version of the Checkmarx Jenkins AST plugin (version 2.0.13-829.vc72453fa_1c16, published 17 December 2025) was pushed out carrying credential-stealing code engineered to "harvest a wide range of developer secrets." Checkmarx later shipped a clean build, 2.0.13-848.v76e89de8a_053, but a poisoned CI plugin is about the worst place to hide malware: Jenkins runs with broad access to source, build secrets, and deploy credentials, and it runs that code on every build.
This wasn't TeamPCP's first pass. An earlier April 2026 campaign hit Checkmarx's KICS Docker image, two VS Code extensions, and a GitHub Actions workflow — three different distribution channels, each one a trusted artifact developers pull without a second look. According to Checkmarx's own statement, the attackers got in using credentials harvested in a prior supply chain attack back in March 2026.
That detail is the whole lesson. As SOCRadar noted, the rapid re-compromise "points to one of two possibilities: either the initial remediation was incomplete... or the group retained a foothold that wasn't identified during the March response." A stolen credential that's never rotated isn't a one-time loss — it's a key the attacker keeps using until you change the lock. The repo defacement message wasn't just trash talk; it named the actual failure.
Why developer tooling is the target
Attackers go where the leverage is, and developer tooling is pure leverage:
- One compromise, many victims. A poisoned plugin, image, or extension executes on every machine and pipeline that installs it. The blast radius is the install base.
- Trusted by default. Nobody code-reviews a Jenkins plugin update or a VS Code extension. We treat the marketplace as the trust boundary, and the marketplace is exactly what got compromised.
- Privileged by design. CI/CD systems and IDEs hold the secrets — deploy keys, cloud credentials, signing keys. Owning the tool means owning the keys.
- Credentials compound. As the Checkmarx timeline shows, one stolen secret finances the next intrusion. Supply chain attacks chain together.
The boring data that should worry you more
TeamPCP is a sophisticated, motivated adversary. Most organizations don't need one to be at risk — they're exposed by neglect, not by attackers. The Datadog numbers are the uncomfortable mirror:
| Finding | Figure |
|---|---|
| Orgs with ≥1 known exploitable vuln in a deployed service | 87% |
| Services depending on libraries no longer actively maintained | 42% |
| Median age of a software dependency | 278 days out of date |
| Year-over-year change in that median | 63 days worse |
| Exploitable-vuln rate on end-of-life language versions | 50% (vs 31% on supported) |
| Orgs adopting new library versions within 24h of release | 50% |
| Orgs pinning all public GitHub Actions to commit hashes | 4% |
Two of these deserve to be read together. The median dependency is 278 days out of date — and that gap got 63 days worse over the year, so teams are falling behind faster than they're catching up. At the same time, 50% of organizations pull brand-new library versions within 24 hours of release. That's not a contradiction; it's the worst of both worlds. Teams are simultaneously too slow on security patches for the libraries they already have and too fast to adopt unvetted new releases — which is precisely the window a malicious package author exploits.
There's a sharper insight buried in the report, too: only 18% of vulnerabilities labeled "critical" stayed critical once runtime context was applied. The severity score on a CVE is computed in a vacuum. Whether a vulnerable function is actually reachable in your running service, exposed to untrusted input, or sitting dead in a code path you never call — that's what determines real risk. Chasing CVSS scores instead of reachable, exploitable issues is how teams stay busy and stay exposed at the same time. Help Net Security's writeup of the 2026 DevOps Threats Report makes the same point from the pipeline side: the gap is rarely a missing tool, it's unmanaged trust.
What actually moves the needle
The good news is that the defenses are well understood and mostly unglamorous. None of this is novel research — it's hygiene that the 87% haven't finished doing.
1. Pin third-party CI actions to immutable hashes
The "4% pin to commit hashes" stat is the single most actionable line in the Datadog report. A version tag like @v4 is a moving pointer — whoever controls the action's repo can change what v4 resolves to after you've approved it. A full commit SHA can't be silently re-pointed.
# Fragile: the tag can be repointed to malicious code after you trust it
- uses: actions/checkout@v4
# Resilient: a commit SHA is immutable; add the version in a comment for humans
- uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3 # v4.2.1
Pinning to SHAs across your workflows closes the exact gap TeamPCP's GitHub Actions vector relied on, and it costs you one Dependabot rule to keep the SHAs current.
2. Treat secrets as perishable
The Checkmarx re-compromise happened because credentials from March were still valid in May. The defenses are short-lived, automatically rotated credentials; OIDC-based federation instead of long-lived static tokens in CI; and the assumption that any breach means every reachable secret is burned and must be rotated, not just the ones you can prove were touched.
3. Know what you ship — and what runs
You can't patch a 278-day-old dependency you don't know you have. A generated software bill of materials (SBOM) for every build, plus runtime context on which vulnerable code is actually reachable, turns an unmanageable CVE backlog into a short list of things that can really hurt you. Prioritize the reachable 18%, not the theoretical 100%.
4. Put a gate between "new release" and "in production"
If half of all teams adopt new versions within a day, the fix isn't to freeze — it's to insert a short, automated quarantine: a cooldown window, install-script and behavioral scanning, and provenance checks (is this build signed and attested?) before a new version is allowed into the build. Malicious packages are usually caught within days; a brief delay defuses most of them.
5. Reduce the trusted surface in IDEs and CI
TeamPCP's VS Code extensions are a reminder that the editor is part of the supply chain. Limit which marketplace extensions are allowed, review the permissions they request, and run CI build steps with the least privilege the job needs — not the broad, ambient credentials most pipelines hand out by default.
6. Make build provenance verifiable
The deepest defense is being able to answer one simple question for every artifact you ship: where did this come from, and can I prove it? Signed builds and provenance attestations — a tamper-evident record of how and where an artifact was produced — let your pipeline reject anything that didn't come from your own trusted build system. Frameworks like SLSA exist precisely to formalize this. If TeamPCP's poisoned Jenkins plugin had to present valid provenance from Checkmarx's official build pipeline to be accepted, a repo-defacing attacker pushing a hand-modified version would fail the check before it ever ran. Provenance turns "we trust the marketplace" into "we verify the source" — which is the entire difference between being in the 87% and being out of it.
What to watch
- More attacks on the "trusted middle." Plugins, base images, IDE extensions, and CI actions are the soft layer between your code and your runtime. Expect adversaries to keep mining it, because the leverage is unbeatable.
- Credential rotation as the difference between an incident and a saga. The Checkmarx timeline is a case study in how not rotating turns one breach into three. The orgs that rotate aggressively will have shorter stories to tell.
- Reachability-based prioritization going mainstream. With only 18% of "critical" CVEs critical in context, the tools and teams that can tell reachable from theoretical will spend their limited time on the issues that actually matter.
- The 278-day number next year. It got 63 days worse this cycle. Whether that trend reverses is the clearest single signal of whether the industry is actually closing its security debt or just talking about it.
The uncomfortable summary: the headline-grabbing TeamPCP campaign and the boring 87% statistic are the same story told at two volumes. Both come down to trusting artifacts you didn't verify and credentials you didn't rotate. The fixes have existed for years. The work is finishing them.
