In six weeks, a single supply chain threat group has successfully compromised assets in every major developer distribution channel: GitHub Actions, PyPI, npm, Docker Hub, and the VS Code Marketplace. The sequence is not a coincidence or a lucky streak. It is a systematic proof-of-concept demonstrating that the developer distribution stack, as currently constructed and secured, does not have meaningful defence-in-depth.
The security industry’s response has been to treat each incident as a separate operational problem — rotate the credentials, pull the malicious version, notify affected users, patch and move on. That response is correct tactically and completely inadequate strategically. What TeamPCP has demonstrated is not a series of isolated vulnerabilities. It is a map.
What the Campaign Actually Demonstrates
Start with the pattern. March 2026: Trivy GitHub Action tags hijacked. Seventy-five tags redirected to a credential stealer deployed in CI/CD pipelines running security scans. Late March: LiteLLM on PyPI backdoored via compromised publisher credentials. April 22: @bitwarden/cli on npm poisoned for ninety minutes via compromised Checkmarx CI/CD credentials that held npm publish rights. Same day: five Checkmarx KICS Docker Hub tags overwritten; two VS Code extensions backdoored.
Each attack used the same mechanism: compromise the credential that authorises publishing to a distribution channel, then publish poisoned versions to packages with established trust. The variation is only in which channel — Actions, PyPI, npm, Docker Hub, VS Code Marketplace — and which publisher credential provided the key.
This is not a set of separate vulnerabilities. It is a credential harvesting and exploitation operation that is methodically working through every channel through which developer tooling reaches developer machines and CI/CD pipelines. The question TeamPCP is asking — and answering — is: which channels can we reach, and what does compromised publisher access give us? The answer so far is: all of them, and everything.
The Wrong Layer
The security industry has spent the last four years building tooling to detect supply chain compromise at the dependency inspection layer. Software Composition Analysis scans your dependencies for known vulnerabilities. SBOM generation documents what you have. Dependency review GitHub Actions flag new dependencies added in pull requests. All of this tooling operates on what enters a codebase — the point at which a developer or a CI pipeline resolves and downloads a package.
TeamPCP is attacking before that point. By the time your SCA tool scans the package, the package was already compromised upstream. By the time your dependency review fires, the version you’re installing was already poisoned in the registry. The tooling that the industry has invested in building catches the wrong thing. It catches old vulnerabilities in legitimately-published packages. It does not catch a legitimate package that was poisoned six hours ago by an attacker with the publisher’s credentials.
The deeper problem is that the distribution channels themselves were not built with a security threat model that included the publisher-credential attack surface. npm, PyPI, Docker Hub, and the VS Code Marketplace all operate on a trust model where possession of the publisher credential is equivalent to being the legitimate publisher. There is no secondary verification, no signing requirement that cannot be trivially satisfied by the attacker holding the credentials, and no automated anomaly detection that would flag a new version of a package being published from an IP address that has never published before.
The Perimeter That Matters
Security operations has spent a decade arguing about where the perimeter is. The network perimeter collapsed with cloud adoption. The endpoint perimeter is contested by endpoint telemetry gaps. The identity perimeter is the current consensus answer.
For development infrastructure, the relevant perimeter is the CI/CD pipeline and the package registry. These are the systems that decide what software gets built, signed, and distributed to production. They are also the systems that most enterprise security programmes have the least coverage over — no EDR agents on build servers, no DLP on package registry uploads, no anomaly detection on publisher credential usage.
A credential that can publish to npm with 78,000 weekly downloads is not just a developer tool. It is a deployment mechanism with access to developer machines, CI/CD environments, and all the secrets those environments hold, across every organisation that uses the package. The blast radius of a publisher credential compromise scales with the package’s download count. TeamPCP did not target Bitwarden CLI because the CLI itself was interesting. They targeted it because its CI/CD pipeline held the npm publish credential, and the npm publish credential gave them access to 78,000 downstream install environments.
What Actually Changes the Outcome
Rotating credentials after compromise, pulling poisoned versions, and notifying affected users is necessary. It does not change the next attack. What changes the outcome is treating the CI/CD pipeline and the distribution channel credentials as part of the security perimeter — with the same controls applied to network perimeters or identity infrastructure.
That means publisher credentials that are short-lived and scoped to specific packages, not long-lived tokens held in CI/CD environment variables. It means anomaly detection on the usage of those credentials — a publish from a new IP or a new geographic location should trigger verification. It means package signing with independent key material, not the publisher credential, so that compromise of one does not automatically validate a poisoned version. It means monitoring for unexpected outbound connections from build environments, which is where credential exfiltration shows up before the poisoned package reaches downstream users.
None of this is new capability. All of it exists. The problem is that the developer distribution stack is not currently treated as security infrastructure requiring these controls — it is treated as a developer productivity surface where friction is the primary concern.
TeamPCP’s campaign will continue. The channels that have not yet been compromised are a to-do list, not an indication that the problem is bounded. The choice the industry faces is whether to address the distribution channel as a security perimeter before the map is complete, or after.