The tool your organization trusts to find vulnerabilities just spent eight days delivering them.
On March 19, 2026, threat group TeamPCP compromised Aqua Security's Trivy, one of the most widely deployed open-source vulnerability scanners in the world. Within eight days, the attack cascaded across five package ecosystems, infected 500,000 machines, exfiltrated 300 GB of compressed credentials, and spawned a self-propagating npm worm with command-and-control infrastructure that no court order can take down.
The root cause? An incomplete password reset from two months earlier.
The Cascade: Trivy to Everything
The attack began when TeamPCP exploited residual access from an incomplete credential rotation following a February security incident. Aqua Security had rotated credentials, but not all of them. That gap was all TeamPCP needed.
The timeline tells the story:
- March 19: Trivy GitHub Actions compromised. 75 of 76 trivy-action tags force-pushed to malicious commits. The attack script, internally named "kamikaze.sh," scraped CI/CD runner memory for secrets using pattern matching against GitHub's secret masking format.
- March 20-22: Stolen credentials fueled CanisterWorm, a self-propagating npm worm that infected 66+ unique packages and 141 malicious artifacts within hours.
- March 21: Checkmarx KICS, another security scanning tool, fell next.
- March 23: LiteLLM, the AI proxy routing layer present in 36% of all cloud environments with 95 million monthly PyPI downloads, was trojanized.
- March 27: Telnyx SDK compromised using WAV file steganography.
The sophistication escalated at each stage. The LiteLLM payload used a .pth file that auto-executes whenever Python starts, with double Base64 encoding and AES-256-CBC encryption. The Telnyx attack hid its payload inside audio files named hangup.wav and ringtone.wav.
Here's what made this particularly dangerous: Trivy continued functioning normally throughout the attack. The malicious code ran legitimate vulnerability scans alongside its credential harvesting. No build failures. No scan errors. No visible indication that anything was wrong. This is the same pattern we saw with cloud-native feature weaponization: attackers aren't breaking your tools. They're using them exactly as designed.
The Blockchain C2 Problem
CanisterWorm didn't phone home to a traditional server. It used an Internet Computer Protocol (ICP) canister for command and control. This isn't the first time attackers have used decentralized infrastructure; GlassWorm used Solana-based C2 for its own npm worm months earlier. But ICP canisters take the concept further.
This matters because traditional law enforcement playbooks don't apply. When malware uses a conventional domain, authorities can seize it. When it uses a hosting provider, they can issue a takedown. ICP canisters run on a decentralized network with no single entity that can comply with a court order.
The canister exposes three methods: get_latest_link, http_request, and update_link. The controller can swap the payload URL at any time, as Aikido Security researcher Charlie Eriksen noted, pushing new binaries to all infected hosts without touching the implant itself.
Currently, the C2 returns a rickroll YouTube video. That's not funny; it's a dormant weapon. The infrastructure is in place, the implants are deployed, and the controller can activate them whenever they choose.
IP-based blocking of the *.icp0.io gateway causes collateral damage across every legitimate canister on the network. This isn't a bug in the attack; it's a feature. Future campaigns will copy this approach precisely because it's resistant to the takedown mechanisms that security teams and law enforcement have spent decades building.
The Root Cause Nobody's Talking About
Most coverage of TeamPCP focuses on the technical sophistication: the WAV steganography, the blockchain C2, the five-ecosystem cascade. That's the wrong lesson.
The entire attack traces back to one operational failure: Aqua Security's February credential rotation was "not fully comprehensive." Residual tokens from the earlier incident remained valid. TeamPCP used them to restart the attack a month later.
This is not an exotic failure mode. It is the most common one. Every security team that has ever rotated credentials knows the challenge: you think you've changed everything, but one service account, one API token, one deploy key slips through. The difference here is that the asset was a vulnerability scanner with privileged access to thousands of CI/CD pipelines.
And that's the fundamental tension nobody is addressing: your vulnerability scanner has the broadest access of any tool in your CI/CD pipeline. It needs to read your source code, your container images, your dependency manifests, your configuration files. In many environments, it has access to secrets that the developers themselves don't see. That access exists so the scanner can protect you. It's also exactly what makes it the highest-value target.
Dan Lorenc, CEO of Chainguard, called GitHub Actions' design "plain irresponsible today," noting it ignores a decade of supply chain security work from other ecosystems. He's right. But the problem extends beyond GitHub Actions. The uncomfortable truth about CI/CD trust models is that the entire model of granting security tools unconstrained access to sensitive environments needs rethinking.
The Downstream Blast Radius
Supply chain attack coverage usually stops at "credentials were stolen." The TeamPCP campaign shows what happens next.
The LiteLLM compromise cascaded into Mercor, a $10 billion AI hiring startup. Attackers exfiltrated 4 TB of data, including 3 TB of video interviews containing facial biometrics and KYC documents for over 30,000 contractors. That biometric data cannot be reset. You can rotate a password, revoke a token, reissue a certificate. You cannot change someone's face. This is the invisible attack surface of third-party data sharing taken to its logical extreme: when your vendor's vendor gets compromised, the blast radius hits people who never signed up for the risk.
Mandiant CTO Charles Carmakal warned there will "likely be many other software packages, supply-chain attacks, and a variety of other compromises" as a result. The SANS Institute estimates 1,000+ SaaS environments are confirmed impacted, with a final count potentially reaching 5,000 to 10,000.
And here's an underreported detail: during the same week TeamPCP was spreading CanisterWorm through npm, a separate North Korean threat group (UNC1069) compromised the Axios npm package, hitting 600,000 installs in three hours. Two unrelated threat actors independently targeted npm's supply chain in the same week. I wrote about npm's structural trust problem when Axios was hijacked and the pattern keeps repeating: npm's trust architecture treats every publisher as trustworthy until proven otherwise, and attackers keep proving otherwise.
What Organizations Should Actually Do
Most guidance after the Trivy incident amounts to "pin your GitHub Actions to commit SHAs." That's table stakes. The harder questions remain.
Treat security tools as crown jewels, not trusted infrastructure. Your vulnerability scanner has more access than most of your engineers. Its credentials should be ephemeral, scoped to individual workflow steps, and rotated on every run. If your scanner's service account has standing access to production secrets, you've built the exact attack surface TeamPCP exploited.
Verify your security tools independently. This is the recursive trust problem made concrete: who validates the validator? Trivy ran legitimate scans alongside its malicious payload. The builds passed. The reports looked normal. If your only validation is "the scan completed successfully," you would not have caught this. Consider running multiple scanners from different vendors: not for redundancy in detection, but for integrity verification.
Assume credential rotations are incomplete. After any security incident, validate the rotation programmatically. Enumerate every token, every key, every service account. Test that the old credentials fail. Aqua Security's team thought they'd rotated everything in February. A single surviving token enabled the largest supply chain attack of 2026.
Monitor for blockchain-based C2. ICP canister traffic to *.icp0.io and *.ic0.app domains should be flagged in your network monitoring. This is no longer theoretical; it's documented tradecraft. Your threat intelligence feeds should be updating to include decentralized infrastructure indicators.
The TeamPCP campaign isn't just another supply chain attack. It's a structural demonstration that the tools we trust to secure our software have become the most valuable attack surface in the ecosystem. The scanner had the keys to everything. Attackers used them.
