The Mercor Breach: How a Poisoned Security Scanner Cascaded Through AI Infrastructure
Written by the Rafter Team
On March 24, 2026, two malicious versions of the litellm Python package appeared on PyPI. They were live for approximately 40 minutes. Within a week, one of Silicon Valley's fastest-growing AI startups had confirmed a major data breach, Meta had frozen its contracts, and five class-action lawsuits had been filed.
The attack wasn't a single compromise — it was a cascade. A threat group first poisoned a security scanner, then used it to steal publishing credentials, then used those credentials to distribute malware through one of the most widely-installed AI libraries in the Python ecosystem. Each step unlocked the next, and automated CI/CD pipelines carried the attack forward without any human in the loop.
The Attack Chain
Stage 1: Trivy (March 19)
The attack began with Trivy, Aqua Security's open-source vulnerability scanner. Trivy is one of the most widely-used security tools in CI/CD pipelines — it scans container images, filesystems, and code repositories for known vulnerabilities.
The threat actor, tracked as TeamPCP (also designated UNC6780 by Google Threat Intelligence), compromised the trivy-action GitHub Action by rewriting 76 of 77 version tags in the repository. Each tag was redirected to a malicious commit. Any CI/CD pipeline that referenced Trivy by tag — which is standard practice — would silently pull the compromised version.
This was assigned CVE-2026-33634 (CVSS 9.4), and CISA added it to the Known Exploited Vulnerabilities catalog.
The irony is hard to miss: a vulnerability scanner — a tool organizations run specifically to improve their security posture — became the initial entry point for the attack.
Stage 2: LiteLLM's CI/CD (March 24, 10:39 UTC)
LiteLLM is an open-source proxy that routes requests to multiple LLM providers (OpenAI, Anthropic, Google, Cohere, and others) through a unified API. According to Wiz, it's present in 36% of cloud environments they monitor, with roughly 95 million monthly downloads.
LiteLLM's build pipeline ran the compromised Trivy action as part of its standard security scanning. The malicious code is believed to have exfiltrated LiteLLM's PYPI_PUBLISH token from the GitHub Actions runner environment.
Stage 3: Poisoned Packages (March 24, 10:52 UTC)
Thirteen minutes after obtaining the credentials, TeamPCP published litellm v1.82.7 and v1.82.8 to PyPI. The payload was a sophisticated three-stage credential harvester:
- Orchestrator — collects and encrypts stolen data, exfiltrates it via POST requests to
models.litellm.cloud(not a legitimate BerriAI domain) - Credential sweeper — harvests SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes secrets, cryptocurrency wallets,
.envfiles, and database credentials. Capable of lateral movement by deploying privileged pods across Kubernetes nodes. - Persistent backdoor — installs a systemd service (
sysmon.service) that polls an attacker-controlled endpoint for additional payloads
The malicious code was embedded in proxy_server.py (v1.82.7) and additionally in a litellm_init.pth file (v1.82.8).
By 11:48 UTC, a security researcher had flagged the compromise. By ~13:30 UTC, PyPI had quarantined the package. The malicious versions were the latest release for approximately 40 minutes, though full containment took closer to three hours.
The Mercor Breach
Mercor is an AI recruiting and training data startup that reached a $10 billion valuation after a $350 million Series C led by Felicis Ventures in October 2025. It recruits domain experts — medicine, law, literature — and provides training data for AI companies including Meta, OpenAI, and Anthropic.
Mercor's automated CI/CD pipeline pulled one of the poisoned LiteLLM versions during the exposure window. The credential harvester exfiltrated access credentials, and the attackers used them to access Mercor's internal systems.
On March 30, the extortion group LAPSUS$ posted on Telegram claiming to have Mercor's database. On March 31, Mercor publicly confirmed the breach.
What was exposed
LAPSUS$ claimed approximately 4 terabytes of stolen data:
- 939 GB of platform source code
- 211 GB of user data — full names, email addresses, work history, and Social Security numbers for U.S. contractors
- ~3 TB of video interview recordings and identity verification documents
- Internal Slack communications, ticketing system data, and TailScale VPN configurations
- API keys and secrets for AI providers
More than 40,000 current and former contractors and customers were potentially affected. Mercor has not independently verified the full scope of LAPSUS$'s claims, and a third-party forensics investigation is underway.
The fallout
- Meta indefinitely paused all contracts with Mercor, including work tied to Meta's AI training programs
- Five class-action lawsuits were filed in the first week of April, with one naming BerriAI (LiteLLM's parent company) as a co-defendant
- Mercor's spokesperson stated the company "moved promptly" to contain the incident and characterized Mercor as "one of thousands of companies" affected by the LiteLLM compromise
Why AI Infrastructure Is a Different Kind of Target
The structural issue isn't that LiteLLM had a vulnerability. It's what LiteLLM is — and what it concentrates.
AI gateway libraries aggregate API keys for every LLM provider an organization uses into a single dependency. Compromise that one dependency and you potentially get concurrent access to OpenAI, Anthropic, Google, and every other provider the organization has configured. The credential harvester in the poisoned LiteLLM versions was purpose-built for exactly this: it didn't just grab generic cloud credentials, it targeted the specific secrets that AI infrastructure concentrates.
This makes AI proxy layers unusually high-value targets compared to typical libraries:
- Credential concentration: one package holds keys to every AI service
- Data exposure: prompts, completions, and training data all flow through the proxy
- Broad deployment: LiteLLM's presence in 36% of monitored cloud environments means the potential blast radius of any compromise is enormous
- Automated consumption: AI infrastructure is typically deployed via automated pipelines that pull the latest version without human review
What Would Have Prevented It
Pin dependencies with cryptographic hashes
Organizations using poetry.lock or uv.lock with pinned hashes were completely unaffected. Their build systems refused to install the poisoned versions because the hashes didn't match what was recorded in the lockfile. Unpinned pip install litellm or loose version-range specifiers inherited the entire attack chain.
Pin GitHub Actions by commit SHA
The Trivy compromise worked because Git tags are mutable — TeamPCP rewrote them to point to malicious commits. Commit SHAs are immutable. Referencing aquasecurity/trivy-action@<commit-sha> instead of aquasecurity/trivy-action@v0.69 would have prevented the initial compromise from propagating into downstream CI/CD pipelines.
Scope CI/CD secrets
LiteLLM's PYPI_PUBLISH token was accessible to the GitHub Actions runner that executed the Trivy step. Limiting which workflow steps can access publishing credentials — and using short-lived, scoped tokens where possible — reduces the blast radius of any individual step compromise.
Run dependency scans in CI
Catching compromised packages before they reach production is the last line of defense. Rafter's Code Analysis Engine checks for known supply chain compromises and flags poisoned dependencies in your project before they merge.
BerriAI's Response
BerriAI, LiteLLM's parent company, took several steps after the incident:
- Paused all releases pending a supply chain review
- Released clean v1.83.0 via a rebuilt CI/CD pipeline with isolated build environments, reduced secret scope, and independent artifact verification
- Published a detailed security update and held a public security townhall
It's worth noting that within two weeks of the supply chain incident, three additional CVEs were disclosed in LiteLLM's own code: a critical JWT authentication bypass (CVE-2026-35030, CVSS 9.1), a privilege escalation via the config endpoint (CVE-2026-35029, CVSS 8.7), and a remote code execution vulnerability via bytecode rewriting (CVE-2026-40217, CVSS 8.8). These were unrelated to the supply chain attack but suggest the project needs a broader security audit beyond CI/CD hardening.
The Week That Broke Trust
The Mercor breach didn't happen in isolation. In the same week:
- The axios npm supply chain attack (March 31) — a North Korean group social-engineered a maintainer and backdoored over 100 million weekly downloads for three hours. Full analysis →
- The Claude Code source code leak (March 31) — a Bun-generated source map slipped past the npm packaging config and exposed ~513,000 lines of Anthropic's source code, including anti-distillation defenses. Full analysis →
Three different attack vectors (CI/CD compromise, social engineering, build misconfiguration), two different ecosystems (PyPI, npm), and one common thread: automated pipelines that pull dependencies without cryptographic verification are a structural vulnerability. AI tooling makes the consequences worse because it concentrates access and credentials in ways that traditional software doesn't.
Further Reading
- The Axios npm Attack: How a Social Engineering Campaign Compromised 100 Million Weekly Downloads
- Claude Code's Source Code Leaked on npm: What Happened and What It Means
- Transitive Dependency Risks: The Hidden Attack Surface in Your Software
- AI Agent Supply Chain Security: Malicious Plugins and Model Backdoors