TeamPCP Supply Chain Attack: How a Stolen GitHub Token Backdoored Trivy and LiteLLM, and Got Its Operators Arrested

In February 2026, someone found a misconfigured GitHub Actions workflow in Trivy. Trivy is the open-source vulnerability scanner that Aqua Security ships. It sits inside thousands of CI/CD pipelines worldwide. Someone pulled a service-account token out of that workflow. Nothing dramatic happened for weeks. Then, on March 19, a backdoored Trivy release went out across every distribution channel at once. By then the stolen token had already done its job five times over.

The TeamPCP supply chain attack is a real-world case study in transitive trust: what happens when attackers compromise a security tool's own build pipeline, then ride that trust into every project that runs the tool. Trivy scans other projects' code for vulnerabilities. Plenty of teams run Trivy inside their own pipelines without a second thought. That trust is exactly what got exploited. Two Australian men, aged 21 and 23, were arrested on August 26, 2026, after a joint AFP, FBI, and Western Australia Police Force investigation. This piece covers both halves of the story: how the attack actually worked, and how operational security failures led investigators to a real name.

Who is TeamPCP

TeamPCP didn't start as a supply chain crew. In late 2025, it was an opportunistic cloud exploitation operation. It ran automated scanners across the internet, looking for anything left exposed: Docker APIs, Kubernetes control planes, Ray dashboards, unauthenticated Redis instances. Flare's honeypots caught this activity firsthand. They fingerprinted 185 separate Docker compromises in a single campaign. Compromised hosts became scanner and proxy nodes, which went looking for the next batch of exposed infrastructure. It was standard botnet self-propagation, just at internet scale.

The revenue model was equally standard: XMRig cryptocurrency mining, renting out the proxy network, and selling or extorting stolen data. In December 2025, the group ran a React2Shell campaign against Next.js applications. Its own control-server dashboard reportedly logged close to 59,000 compromised servers in under 48 hours. None of it was subtle. TeamPCP ran public Telegram channels, posted under an X account, and gave interviews. In one, published by Forbes, the group described itself as "a loose-knit group of teenagers and young adults who couldn't find paying work." That appetite for an audience is worth remembering. It's largely what got them caught.

The attack chain: one token, five ecosystems

In early 2026, TeamPCP shifted from opportunistic cloud exploitation to targeting the software supply chain directly, going after the tools and libraries that other companies build on top of and trust by default. Here's the sequence, reconstructed from Flare's investigation:

1. February 2026: TeamPCP finds a misconfigured GitHub Actions workflow in Aqua Security's Trivy and extracts a service-account token from it.
2. Aqua Security rotates its credentials after some point of awareness, but the rotation is incomplete. TeamPCP retains working access.
3. March 19, 2026: a malicious Trivy release goes out across every distribution channel simultaneously, carrying credential-stealing malware.
4. The poisoned Trivy release starts running inside CI/CD pipelines globally, including LiteLLM's own build pipeline.
5. LiteLLM's pipeline runs Trivy as part of its normal build process. Doing so hands the poisoned scanner access to LiteLLM's PyPI publishing token.
6. March 24, 2026: two backdoored LiteLLM releases go out on PyPI, reaching a package with roughly 95 million downloads a month.
7. Total elapsed time from the original token theft to five poisoned software ecosystems: five days.

That distinction matters more than it sounds like it should. Nobody phished a LiteLLM maintainer. Nobody found a bug in LiteLLM's own code. LiteLLM's pipeline did what thousands of other pipelines do: it ran a well-known, trusted security scanner as part of its build. The compromise moved through a trust relationship, not a code vulnerability. That's why static composition analysis alone wouldn't have caught it. A poisoned but validly signed release of a tool you already trust looks just like a legitimate one, right up until it starts exfiltrating your secrets.

The scale reported by law enforcement is significant even by supply chain attack standards. The Australian Federal Police's official release says TeamPCP's malicious code potentially compromised more than 1,000 organizations worldwide. It enabled the theft of over 500,000 credentials. At least 300GB of data was exfiltrated. Global remediation costs are estimated in the hundreds of millions of dollars. Krebs on Security reported a higher number for the LiteLLM compromise alone: more than 2,500 organizations and at least 3,800 GitHub repositories affected across the wider campaign. Named victims in press reporting included the European Commission, Mistral AI, OpenAI, and GitHub itself.

Why this got past standard defenses

Three separate gaps let this chain run for as long as it did:

• Incomplete credential rotation. Aqua Security rotated credentials after the initial compromise was suspected, but not all of them. Rotation as a one-time event, rather than a verified inventory exercise, left a working token in TeamPCP's hands.
• No egress monitoring on security tooling itself. A vulnerability scanner making outbound network calls during a CI run doesn't typically trip any alarms, because scanners are expected to fetch vulnerability databases and signatures. That's exactly the cover a credential-stealing payload needs.
• Trust that doesn't decay with distance. Teams that pin Trivy to a tag rather than a commit SHA inherit whatever gets published to that tag automatically, with no re-review. A supply chain security posture that stops at your own first-party code, and treats every dependency's build pipeline as implicitly safe, has a blind spot exactly this shape.

Known indicators of compromise

Public reporting on this campaign is narrower than a full incident response writeup; neither Flare nor the AFP has published the malicious payload source, a complete IOC list, or CVE identifiers for the GitHub Actions misconfiguration. The indicators below are the ones that are publicly confirmed. Treat this as a starting point for hunting, not an exhaustive list.

Detection and response

If your CI/CD pipeline ran Trivy between February and March 19, 2026, or LiteLLM between March 19 and 24, 2026, treat every credential those pipelines touched as compromised. Start here:

# Check outbound DNS/connection logs for the known C2 domain
grep -ri "masscan.cloud" /var/log/**/*.log 2>/dev/null

# Check CI runner egress logs for connections to masscan.cloud (adjust for your log backend)
# e.g. in a Kubernetes cluster running CI runners:
kubectl logs -n ci --since=720h -l app=ci-runner 2>/dev/null | grep -i "masscan.cloud"

# Pin Trivy in GitHub Actions to a commit SHA instead of a mutable tag or version range
# Bad:  uses: aquasecurity/trivy-action@master
# Good: uses: aquasecurity/trivy-action@<full-40-char-commit-sha>

# Audit which GitHub Actions secrets a workflow can reach
gh api repos/:owner/:repo/actions/secrets --jq '.secrets[].name'

# Check installed Trivy and LiteLLM versions against the compromised release windows
pip show litellm 2>/dev/null | grep -i version
trivy --version

1. Rotate every credential your build pipeline had access to during the affected windows: GitHub Actions tokens, PyPI/npm publishing tokens, cloud provider credentials, and any secrets a Trivy scan step could read.
2. Treat rotation as an inventory exercise, not a checkbox. Aqua Security's initial rotation missed tokens; confirm every credential is actually invalidated, not just the ones you remember configuring.
3. Pin GitHub Actions and other CI dependencies to a full commit SHA rather than a tag, branch, or version range, so a compromised upstream release can't silently execute in your pipeline.
4. Add egress monitoring specifically for security tooling. A scanner or linter making an unexpected outbound connection during a build is a stronger signal than most teams currently treat it as.
5. Check whether your own build pipeline's dependencies (like Trivy) had access to secrets they didn't strictly need, and scope tokens narrower going forward: short-lived, single-purpose, least-privilege.

Timeline

How OSINT unmasked TeamPCP

TeamPCP's technical operation was disciplined. Its operational security wasn't. Flare's Emerging Threats Team traced a single recurring alias, DeadCatX3, across a wide net of platforms using OSINT Industries, and the trail held together because the same handles, the same cat avatar, and the same infrastructure references kept showing up in places that were never meant to be connected to each other.

• The DeadCatX3 handle led to a HackerOne profile registered under a real name.
• A Hugging Face account under the same handle listed the masscan[.]cloud domain, directly tying it to the campaign's own C2 infrastructure.
• Leaked credential and stealer-log data connected that identity to a personal Gmail address.
• That Gmail address was tied to a TikTok account posting under the same real name.
• The TikTok account led to a Steam profile with a distinctive avatar, a cartoon cat, that had been VAC-banned years earlier.
• The same avatar had been reused as the profile picture on TeamPCP's own Telegram channel, closing the loop between the pseudonymous persona and the personal accounts.

Krebs on Security ran an independent investigation after the arrest and found a parallel trail. Investigators traced email addresses across forums to Perth-area IP addresses and passive DNS records. Those accounts led to family-owned network storage devices. From there, breach databases and people-search services confirmed identity. Krebs named the suspects as Ruben Ian Thomson, 21, of Cottesloe, and Michael Gaebler, 23, who used the handle @pcpcasper. Thomson allegedly used other aliases beyond DeadCatX3, including EllisD25, BulkDMT, Express, and Persy_PCP. He reportedly told investigators he earned around $20,000 total from TeamPCP activity, and that he stopped participating by March 2026.

The arrest

On August 26, 2026, Australian Federal Police, the FBI, and Western Australia Police Force arrested two men in Cottesloe and Mandurah, Western Australia. They appeared in Perth Magistrates Court the following day on a combined 14 charges, including possessing and supplying data with intent to commit a computer offence, unauthorized modification of data to facilitate a serious offence, and, for the 21-year-old suspect, an additional charge of dealing with more than $100,000 in proceeds of crime. Maximum penalties for the charges range from three to twenty years' imprisonment each. AFP Commander Graeme Marshall said in the agency's official release that "cybercrime knows no borders and is a growing threat globally," underscoring the multi-agency, cross-border cooperation the investigation required. The investigation began in April 2026, after cybersecurity firms passed information to the AFP and FBI. The next court date is scheduled for September 18, 2026.

The lasting lesson

TeamPCP's technical playbook wasn't novel. Stolen tokens, incomplete rotation, and blind trust in a dependency's build pipeline are old problems with a new name attached. What made this campaign notable is the speed of the cascade, five ecosystems in five days from one misconfigured workflow, and the fact that the same public bravado that maximized the group's notoriety is what handed investigators the thread to pull. Supply chain security that stops at your own repository, without accounting for what your dependencies' build pipelines can reach, has a blind spot exactly this shape. TeamPCP found it once. They won't be the last group to look.