SURIQ
The credential theft in the FBI's latest supply-chain alert did not happen on a package registry. It happened on your servers. When a developer or a build runner pulled a trojanized update of a trusted tool, the malicious code ran where that tool always runs, inside your pipeline, next to your cloud tokens, your SSH keys, and your Kubernetes secrets. The registry was only the delivery route. The theft was local, on machines you operate. That distinction decides whether your defenses had a chance, because almost every control the industry reaches for here guards the front door and ignores the room where the valuables sit.
The bureau's warning landed on July 2, 2026 as FLASH alert FLASH-20260702-01, naming a group it tracks as TeamPCP, an actor linked to the loose criminal collective known as The Com. The alert ties the group to a run of software supply-chain compromises that the bureau says reached more than 1,000 organizations. In one case from March 2026, a poisoned build of the container scanner Trivy ran inside roughly 10,000 continuous-integration workflows and harvested more than 500,000 credentials, including cloud tokens. The FBI's guidance is blunt: treat anything the campaign touched as permanently compromised.
What TeamPCP poisoned, and how it got in
The group did not find a clever new bug. It took over the accounts that publish trusted software, then shipped tainted updates through the normal channels teams already trust. The FBI says TeamPCP seized control of publishing accounts in part by re-registering expired recovery email domains, the address a registry uses to reset a maintainer's password. Own the recovery domain, own the account, and the next release you push looks exactly like every release before it.
Four named tools carried the poison: Trivy, the Aqua Security container vulnerability scanner; KICS, a static scanner for infrastructure-as-code; LiteLLM, a library that routes requests across AI model APIs; and the Telnyx Python SDK, a voice and messaging client. Inside victim environments the tainted code deployed a set of purpose-built stealers. The FBI names CanisterWorm, a worm that spreads across npm and PyPI while grabbing cloud tokens and API keys, and SANDCLOCK, which lifts Kubernetes ServiceAccount tokens, AWS keys, build-time environment variables, and crypto wallets. A self-replicating strain the bureau calls Mini Shai-Hulud, and a variant named Miasma that also poisons configuration files, round out the kit. The alert lists associated indicators and CVEs for defenders to hunt against.
| Poisoned tool | Its job in your pipeline | Why the poison had reach |
|---|---|---|
| Trivy | Container vulnerability scanner | Invited into nearly every build; reads images, files, and registries |
| KICS | Infrastructure-as-code scanner | Parses cloud and Kubernetes config with wide read access |
| LiteLLM | Routes requests to AI model APIs | Sits directly on AI provider keys and tokens |
| Telnyx Python SDK | Voice and messaging API client | Ships inside apps that hold live account credentials |
The worst thing to poison is a security tool
Look at that list again. Two of the four are scanners you install precisely to make your pipeline safer. That is not a coincidence, it is the point. A container scanner or an infrastructure-as-code scanner is granted the broadest read access you have and is invited into every build by design. You point it at your images, your Terraform, your Kubernetes manifests, and you run it early, before anything else, on trusted runners. Poisoning an ordinary application dependency lands the attacker in one app. Poisoning the tool whose job is to inspect everything lands them everywhere your builds reach, with credentials handed over willingly. The scanner meant to find your exposure becomes the thing that collects it.
This is the piece the "audit your dependencies" advice keeps missing. Security tooling is dependency too, and it sits higher in the trust chain than the code it checks. We saw the same inversion when Mastra's npm packages passed inspection and then turned hostile a day later, and when simply opening a project folder was enough to run npm malware. The tool you trust most is the one worth stealing.
Pinning and package-age rules stop the next version, not this one
The standard hardening list is real and you should run it: pin your build-time dependencies and your GitHub Actions to a specific commit hash, enforce a minimum package age so a brand-new release cannot enter a build the minute it drops, and audit the recovery email domains on your publishing accounts. We covered the commit-pinning gap in detail when a free GitHub account could push code as a trusted maintainer. Every one of these controls is prevention. Every one of them guards the entrance against the next tainted release.
None of them helps once the trojanized update has already executed on your runner. The FBI's "treat credentials as permanently compromised" line is the tell. It is an admission that by the time you read the alert, the tokens are gone, and no amount of registry hygiene reaches back to un-steal them. The only defense that operates in that window is watching the host itself: a build job that suddenly reads ~/.aws/credentials, queries the cloud metadata service, or opens an outbound connection to a domain it has never contacted before. That is a behavior, and behaviors are visible on the machine even when the package looked clean going in. Prevention is table stakes. Detection on the runner is the backstop, and it is the one most pipelines never built.
Why the ransomware tie-in shrinks your rotation window
Stolen credentials used to sit. A lone stealer crew would bank a haul and work through it slowly, which gave a slow responder some slack. That math changed with this campaign. TeamPCP has partnered with Vect, a ransomware-as-a-service operation that emerged in late 2025, feeding harvested access straight into a pipeline built for volume. Sophos X-Ops director Rafe Pilling called it a "meaningful shift," describing threat groups that operate like businesses and combine specialist capabilities into an assembly line. Theft is one crew's product, extortion is another's, and the credential is the handoff between them.
For a defender, that collapses the time between "a token leaked" and "ransomware is in the environment" from a someday into an operational deadline. It is the same access-broker-to-ransomware handoff we traced with the Mistic backdoor quietly selling network access. When a credential feeds a factory instead of a hoarder, you rotate on the assumption it is already in a queue, not on the assumption you have a week.
Rotate every secret the tool could see, and assume it already leaked
If any of the four named tools ran in your builds, the first move is rotation, scoped to what those jobs could reach: cloud access keys, SSH keys, Kubernetes ServiceAccount tokens, and any secret exposed as a build-time environment variable. Do not wait to confirm theft. As the passwords that survived a malware takedown showed, a stolen credential stays valid until you invalidate it, and confidence that "we probably were not hit" is not invalidation.
After rotation, tighten the parts that let a single poisoned release travel so far: give continuous-integration jobs the least privilege they can run on, move secrets into a manager that issues short-lived credentials instead of long-lived keys pasted into pipeline config, and require phishing-resistant multi-factor authentication on the accounts that publish packages. Then close the loop the prevention list skips. If you run your own build hosts, you hold an advantage a hosted build service will not give you: the box that stored the loot is a box you can watch. Put runtime monitoring on those hosts and alert on the behavior, a build reading credential files it has no reason to touch or reaching an unfamiliar domain, so the next poisoned tool trips a wire on the way out instead of being discovered in a federal alert weeks later.