Faced with a server holding credentials stolen from more than half a million users, Google's threat team did not begin by contacting each victim. It went first to providers such as Amazon Web Services and Microsoft, asking them to revoke access before TeamPCP could use it. The team sent hundreds of notification emails to providers and then to victims, according to reporting published by Ars Technica.
That order of operations is the useful part of an otherwise cinematic story. A Mandiant analyst had entered TeamPCP's inner circle in March 2026 and gained access to the server where the group kept usernames, passwords, and access tokens. The analyst was one of roughly 12 people in a core chat called CanisterWorm. That position gave Google a rare view of the stolen material while some of it could still be disabled, WIRED reported.
Supply-chain incident plans often put discovery first and notification next. TeamPCP exposes the missing clock between those two steps: every credential remains useful until someone with authority kills it. Google could not unwind every compromised machine at once. It could make a large batch of the stolen access stop working because providers could act on the undercover analyst's evidence.
A breach chain that fed itself
TeamPCP, which Google tracks as UNC6780, used stolen credentials as fuel for the next compromise. From February through May, the group targeted PyPI, npm, and Docker Hub. Google says its entry routes varied, but one was abuse of the pull_request_target trigger in GitHub Actions to reach repository secrets and write permissions. Compromised packages then installed credential stealers, including malware Google calls SANDCLOCK, according to Google Threat Intelligence Group's July analysis.
The cycle crossed several kinds of developer infrastructure. The reported victims included the Trivy security scanner, LiteLLM, Checkmarx infrastructure, the TanStack web library, and Mistral AI. Stolen developer access helped the group place malicious code into more tools, creating fresh opportunities to steal more access. Ars reported that the campaign tainted hundreds of open-source programs and ultimately reached more than 1,000 companies.
A poisoned package delivered malware and acquired publishing rights or other network access that could produce the next poisoned package. Google's own incident work found TeamPCP trying to move from compromised AI software into wider corporate networks. The group sought money through direct sale of stolen data and partnerships with ransomware and extortion crews, Google said.
This attack shape changes what counts as containment. Removing one malicious release deals with a visible branch. Rotating only that package maintainer's npm token may still leave cloud and repository credentials stolen from downstream developers alive. Google's account of the campaign shows why defenders have to invalidate the reusable trust that lets the branch grow back.
Why providers were the first call
The owners of the stolen credentials were spread across a large victim set. Providers sat at fewer control points. Google's team could give AWS or Microsoft a set of exposed credentials and ask the company that recognized them to revoke them. Larsen told WIRED that direct outreach to every affected company would have taken too long. Many providers and victims responded immediately to the team's emails.
That approach has limits. A service cannot revoke a secret it did not issue, and a local password may require action by the organization that owns the account. Yet cloud tokens, repository credentials, and app authorizations usually have an authority that can terminate them. GitHub's expanded revocation API is one example of an issuer giving responders a direct route to do that.
GitHub has been building around the same idea. In June, it added a self-service tool that lets an enterprise revoke all credentials for a user at once. Its credential-revocation API also expanded in March to cover OAuth and GitHub App tokens. Personal access tokens were already covered. GitHub says the API lets responders invalidate leaked credentials regardless of where they find them, reducing the period in which an attacker can use them, according to its July supply-chain security update.
A useful incident metric follows from those changes: time from verified exposure to invalidation. Counting notifications says how much mail the response team sent. Measuring invalidation shows how long an attacker retained access. TeamPCP's cache made the difference concrete because Google could see both the stolen material and, through the group's chat, the operation trying to exploit it.
Reduce what a stolen credential can do
The cleaner fix is to keep reusable publishing secrets out of CI in the first place. GitHub calls trusted publishing the top step for disrupting these attacks because it replaces long-lived repository credentials with workload identity. Its July update says npm trusted publishing added CircleCI support in April. A stolen build log or environment dump then has less chance of yielding a token that can publish from an attacker's machine.
GitHub also introduced staged publishing for npm in May. With that option enabled, possession of the publishing credential is insufficient: a release waits for separate approval and two-factor authentication in the npm CLI or website. The control separates automation's ability to prepare a release from a person's authority to let it reach the registry, GitHub explained.
Other changes target the speed of propagation. GitHub says npm 12 disables install-time scripts by default, while still allowing maintainers to approve scripts a package needs. Dependabot version updates now wait three days before proposing an ordinary new release, giving detection signals time to appear. Security updates are exempt from that delay. Neither measure proves a package is clean, but both remove some of the automatic execution and instant adoption that a worm needs.
Teams still need to know where a compromised component or action ran. Google's guidance recommends an automated software bill of materials and a separate action bill of materials that records third-party pipeline tools and connects them to the container images they build. Those inventories do not revoke anything by themselves. They tell responders which builds, credentials, and deployed artifacts belong in the revocation and rebuild scope.
The same chat exposed an AI-assisted zero-day
The inside view also connected TeamPCP to a previously anonymized Google case study. According to WIRED, the CanisterWorm chat revealed that someone in the circle was using an AI tool to develop a zero-day exploit for widely used login software. Google obtained the code, tested it, found that it worked after a few changes, and warned the developer, who patched the flaw.
Google's May technical account described a Python exploit for a two-factor authentication bypass in a popular open-source web administration tool. It still required valid user credentials. Google attributed AI involvement with high confidence from features including unusually instructional docstrings, a made-up CVSS score, and textbook-style code structure. It said Gemini was not used. At the time, Google did not name TeamPCP or explain how it had obtained the exploit.
The case matters here because the stolen-credential problem and the zero-day were complementary. Valid credentials were a prerequisite for the bypass. Revoking them could remove one condition the exploit needed, while the vendor patch removed the logic flaw itself. Intelligence from the chat gave defenders a chance to work on both sides before a planned mass exploitation attempt.
An undercover analyst is not a repeatable control
TeamPCP eventually tightened its circle after a dispute with another criminal group, ShinyHunters, and expelled several members, including Google's analyst. Larsen then used more ordinary investigative links, including breached forum records and an account allegedly used to back up stolen data, before Google passed identifying information to the FBI. Two Australian men were later arrested and charged. The allegations have not been tested at trial, and neither man responded to WIRED's requests for comment.
Most maintainers will never have an investigator inside the chat where their stolen token is being traded. They can still use the part of this operation that scales: short-lived workload identity, separate approval for releases, an inventory of every action that touches a production build, and a tested route for bulk revocation. GitHub's new controls provide pieces of that route, but several are opt-in or tied to particular products.
The next evidence to watch is operational. Registries and cloud platforms need to show that they can accept high-volume, well-supported revocation reports without making researchers locate each victim first. Maintainers should track how quickly trusted publishing and staged releases replace reusable tokens in real projects. TeamPCP accumulated a vast credential store. The more revealing number in the next campaign will be how many of those credentials still work when defenders find it.