Mercor is a $10 billion AI recruiting startup. It contracts domain experts (scientists, doctors, lawyers) for OpenAI, Anthropic, and Meta to train their models. On March 31, 2026, the company confirmed it was "one of thousands of companies" hit by a supply chain attack that started with a compromised vulnerability scanner, spread through a poisoned Python package, and ended with an extortion crew claiming to have stolen 4 terabytes of everything.
Meta indefinitely suspended all work with Mercor. Mandiant's CTO told reporters at RSA Conference that over 1,000 SaaS environments were actively dealing with the cascading fallout. His estimate for where it ends: "another 500, another 1,000, maybe another 10,000."
This isn't one breach. It's a chain reaction.
The Kill Chain
The full attack chain has four distinct stages, each building on the last. It started in late February and is still unfolding as of early April.
Stage 1: Trivy Gets Compromised
Trivy is an open-source vulnerability scanner maintained by Aqua Security. It's the kind of tool that sits in CI/CD pipelines across thousands of organizations, scanning container images and dependencies for known vulnerabilities. The irony of a vulnerability scanner being the entry point is not lost on anyone.
A threat group called TeamPCP compromised Trivy in late February 2026. A month later, they injected credential-stealing malware into the scanner. Any organization running the compromised version had their secrets, API keys, and cloud credentials silently exfiltrated.
Stage 2: LiteLLM on PyPI
With stolen credentials in hand, TeamPCP moved laterally. In March, they published malicious versions of LiteLLM to PyPI.
LiteLLM is an open-source AI gateway that abstracts calls to different LLM providers (OpenAI, Anthropic, Cohere, etc.) behind a single interface. It gets millions of downloads per day. If your team uses LiteLLM to route LLM requests, or if any dependency in your stack pulls it in, you may have been exposed.
The malicious code was identified and removed within hours, but "within hours" in PyPI is the same story we saw with the Axios npm attack. In that case, Socket's automated scanner flagged the trojanized package in six minutes. Six minutes was still enough time for thousands of installs.
LiteLLM's compromise was part of a broader spray. TeamPCP also hit KICS (a static analysis tool from Checkmarx) and published malicious versions of Telnyx to PyPI. Same credential-stealing payload. Same playbook.
Stage 3: Credentials Get Used
Google-owned Wiz published findings showing that stolen credentials from the supply chain compromises were "quickly validated and used to explore victim environments and exfiltrate additional data." This isn't speculative. Cloud, code, and runtime evidence confirmed active post-compromise activity.
The credentials stolen through Trivy and LiteLLM gave attackers access to cloud environments, source code repositories, internal APIs, and databases. From there, it was a matter of deciding which targets were worth the effort.
Stage 4: Lapsus$ and the Extortion
Lapsus$ showed up next. The extortion crew, now collaborating with TeamPCP according to Palo Alto Networks' Unit 42, claimed to have stolen 4TB from Mercor. The alleged haul: 939 GB of source code, Slack data, ticketing data, and videos of conversations between Mercor's AI systems and contractors.
Researcher Dominic Alvieri shared the claims on social media. Mercor's spokesperson confirmed the incident but declined to say whether customer or contractor data had been accessed. The company's public statement stuck to the script: "thorough investigation," "leading third-party forensics experts," "devote the resources necessary."
Meanwhile, Lapsus$ offered to sell the data to the highest bidder.
The Cisco Connection
Mercor wasn't the only high-profile name caught in the blast radius. Reports surfaced that TeamPCP also breached Cisco's internal development environment through credentials stolen via the Trivy attack.
Separately, ShinyHunters claimed to have stolen over 3 million Salesforce records from Cisco, along with AWS buckets and GitHub repositories. Cisco confirmed it was "aware of the Trivy supply-chain issue that is affecting the industry" but twice declined to answer whether any of its systems had been accessed by attackers.
The timeline here matters. Trivy was compromised in February. LiteLLM and other packages were poisoned in March. By early April, we're seeing the downstream consequences hit Fortune 500 companies and billion-dollar startups simultaneously. The blast radius is still expanding.
Why This One Is Different
We've written about supply chain attacks before. The Axios compromise was surgical: one package, one trojanized dependency, one payload. Bad, but contained.
This is something else. TeamPCP didn't compromise a single package. They compromised a vulnerability scanner, which gave them credentials to compromise other packages, which gave them access to downstream environments, which they handed off to extortion crews with established playbooks for monetizing stolen data.
It's a supply chain cascade. Each stage amplified the next.
And the choice of initial target was clever. Trivy sits in security tooling. The organizations most likely to be running it are the ones that care about security, which means they're also likely to have valuable assets worth stealing. You compromise the lock, not the door.
The collaboration between TeamPCP (the initial access crew) and groups like Lapsus$ and ransomware gangs CipherForce and Vect (the monetization crews) is also worth noting. Unit 42 confirmed the partnerships. This is organized crime with a division of labor: one team breaks in, another team extracts value.
What To Check
If your organization uses any of these tools, don't assume you're clean just because you updated.
Trivy: Check which version ran in your CI/CD pipeline between February and March 2026. If you pulled a compromised version, assume your secrets were exfiltrated. Rotate every credential that was accessible to your CI/CD environment.
# Check your Trivy version history
trivy --version
# Check container image for Trivy version
docker history your-ci-image | grep trivy
LiteLLM: If you installed or updated LiteLLM from PyPI in March 2026, check your pip install logs. The malicious versions were removed, but if they ran in your environment, credential theft may have already occurred.
# Check installed version
pip show litellm
# Check install history
pip install --log /tmp/pip.log litellm 2>/dev/null; cat /tmp/pip.log
Telnyx and KICS: Same story. Check versions installed during March 2026.
Cloud credentials: If any of the above were compromised in your environment, rotate all cloud provider credentials, API keys, and service account tokens that were accessible from the affected systems. Check CloudTrail (AWS), Cloud Audit Logs (GCP), or Activity Logs (Azure) for unusual access patterns.
Source code: Review recent commits to your repositories for anything unexpected. Check for new deploy keys, webhooks, or CI/CD configuration changes you didn't authorize.
The Pattern
This is the third major package registry attack in 2026, and it's April. Axios on npm in March. LiteLLM on PyPI in March. Each one larger than the last.
The common thread isn't the specific packages. It's the trust model. Package registries assume that the person publishing a package is authorized to do so, and that the code in the package is what it claims to be. Neither assumption holds up against a motivated attacker with stolen credentials.
We covered open-source AI tools and self-hosting recently, and one of the points was that open source gives you control. That's true, but only if you're actually verifying what you're running. Pulling packages from public registries without version pinning, checksum verification, and dependency auditing is not self-hosting. It's just outsourcing your trust to strangers.
At AWZ Digital, every dependency in our client projects goes through version pinning and automated security scanning before it hits any environment that matters. It's not because we predicted this specific attack. It's because the pattern has been obvious since the SolarWinds breach, and the tooling to do it properly has been available for years. The teams getting burned are the ones that skipped the boring parts.
If your dependency management process wouldn't have caught a poisoned Trivy update in your CI/CD pipeline, that's the thing to fix this week. Not next quarter. Talk to us if you want help setting up a process that actually works.
