TeamPCP Supply Chain Attack: FBI Warns on Dev Tools

The FBI has issued a July 2, 2026 FLASH alert warning that the TeamPCP cybercriminal group is targeting trusted developer and security tooling rather than only end-user machines. The alert says the group has used software supply chain compromises to reach victim environments and steal sensitive material such as cloud access tokens, SSH keys, and Kubernetes secrets.^[1]

The warning matters because the affected tooling sits inside build systems, security checks, and cloud deployment workflows. FBI reporting names modified tools including Trivy, KICS, LiteLLM, and the Telnyx Python SDK, all of which can appear in normal CI/CD jobs or developer workstations.^[1] A poisoned update in that position can run with the same trust as the legitimate scanner, SDK, or automation step.

TeamPCP is not a brand-new name for defenders following open-source package incidents. Unit 42 previously described the actor, also tracked as PCPcat, ShellForce, and DeadCatx3, as moving through a series of supply chain operations against security and developer infrastructure.^[2] The FBI alert now gives that activity a current law-enforcement frame and adds a practical list of malware families and indicators defenders can fold into incident response.

According to the FBI, TeamPCP’s toolset includes CanisterWorm for harvesting cloud and authentication material, SANDCLOCK for extracting AWS credentials, Kubernetes service account tokens, local environment variables, and cryptocurrency wallet data, plus Mini Shai-Hulud and Miasma variants tied to npm/PyPI self-propagation and configuration poisoning.^[1] HowToFix.guide previously covered related Mini Shai-Hulud npm/PyPI activity and the Miasma worm campaign against AI coding workflows; the TeamPCP alert ties those patterns to a broader campaign against the software delivery chain.

What CI/CD and cloud teams should check now

Security teams should treat this as a credential exposure problem, not simply as a malware cleanup ticket. Start by identifying whether build runners, developer laptops, GitHub Actions, container jobs, or IaC/security scans used the named tools during the relevant exposure windows. Then review where those jobs could read secrets: repository variables, cloud role credentials, Kubernetes service account tokens, SSH deploy keys, package registry tokens, LLM provider keys, and environment files.

If a runner or developer system may have pulled a compromised package or action, rotating only one visible token is too narrow. Prioritize secrets that can create persistence or downstream compromise: cloud access keys, GitHub personal access tokens, npm/PyPI publishing credentials, Kubernetes tokens, container registry credentials, SSH keys, and any API keys exposed to LiteLLM or deployment automation. The FBI specifically recommends temporary credentials over static secrets, regular rotation, automated scans for exposed secrets, and removal of credentials from code and configuration files.^[1]

The second check is artifact integrity. Teams should verify hashes and signatures before publishing or deploying artifacts, keep trusted artifact repositories access-controlled, and monitor for unauthorized changes.^[1] This is especially important for security tools, because a scanner or IaC checker often runs with access to exactly the cloud, source-code, and deployment context that attackers want.

The third check is pipeline behavior. Look for unusual workflow triggers, unexpected artifact uploads, privilege changes, new outbound connections from build jobs, or changes to release tags and automation scripts. Unit 42’s earlier research highlighted how the actor abused trusted tooling and CI/CD paths to collect cloud tokens, SSH keys, and Kubernetes secrets, while also recommending audits of CI/CD pipelines, GitHub PATs, cloud provider credentials, Kubernetes service account tokens, and container-based SSH keys.^[2]

Developer-focused supply chain attacks have accelerated across several campaigns this year, including the recent PolinRider package attack. The TeamPCP warning is another reminder that “trusted update” does not always mean “safe update.” For teams that run automatic updates in build systems, the practical response is to pin critical tooling, restrict workflow permissions, isolate third-party integrations, and keep enough logs to reconstruct what a build runner actually executed.

References

1. Federal Bureau of Investigation, “Cyber Criminal Group TeamPCP,” FLASH-20260702-01, July 2, 2026. https://www.ic3.gov/CSA/2026/260702.pdf
2. Unit 42, “Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure,” March 31, 2026. https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/
3. Security Affairs, “FBI: TeamPCP Compromised Dev Tools to Steal Cloud Credentials,” July 4, 2026. https://securityaffairs.com/194741/cyber-crime/fbi-teampcp-compromised-dev-tools-to-steal-cloud-credentials.html