A hacker group called TeamPCP compromised LiteLLM, the open-source AI gateway used by an estimated 95 million monthly downloads to route requests across 100+ LLM providers, on March 27, 2026. The attack exploited a previously poisoned vulnerability scanner to steal a PyPI publishing token, then pushed two malicious package versions that were live for approximately 40 minutes. In that window, according to analysis by Okoone, the packages were downloaded nearly 47,000 times. The downstream consequences included a 4-terabyte data breach at Mercor, Meta’s suspension of its contract with the $10 billion AI data startup, and a class-action lawsuit filed on April 1.
The LiteLLM breach is not an isolated incident. It sits at the center of a supply chain attack campaign that has hit Trivy, Checkmarx, TanStack, and GitHub itself across a 50-day span from late March through mid-May 2026. The pattern is consistent: compromise a trusted developer tool, harvest credentials from CI/CD pipelines, use those credentials to poison the next tool downstream. According to BoostSecurity’s timeline, multiple threat actors are now using the same playbook, including DPRK-attributed group PolinRider and at least one unattributed actor behind the Laravel supply chain compromise.
The Attack Chain: From Trivy to LiteLLM
The LiteLLM compromise did not begin with LiteLLM. According to Forcepoint X-Labs’ technical analysis, TeamPCP first compromised Trivy, a widely deployed open-source vulnerability scanner maintained by Aqua Security. The attackers spoofed legitimate maintainer identities and made impersonated commits to the Trivy repository, triggering an automated release pipeline that distributed backdoored binaries through GitHub Releases, Docker Hub, and Amazon ECR.
LiteLLM’s own CI/CD pipeline used Trivy as a security scanning step. Because TeamPCP had already poisoned Trivy, the compromised scanner ran inside LiteLLM’s build environment and scraped the CI/CD runner’s memory, as eSecurity Planet reported. The malware extracted LiteLLM’s PYPI_PUBLISH token directly from runner memory, giving the attackers the ability to publish malicious LiteLLM packages to PyPI without ever touching the official source code repository.
This distinction matters. The LiteLLM GitHub repository was never compromised. The source code remained clean. The attack bypassed source-level integrity entirely by operating at the distribution layer.
Two Injection Techniques, Two Malicious Versions
TeamPCP published two malicious versions of LiteLLM, each using a different injection method, according to Forcepoint’s analysis.
Version 1.82.7 used direct source injection. A Base64-encoded payload was embedded into proxy_server.py, the file that runs when LiteLLM’s proxy service starts. Any application importing or starting the LiteLLM proxy would execute the malware.
Version 1.82.8 used a stealthier technique. The attackers placed a malicious .pth file named litelllm_init.pth inside Python’s site-packages directory. Because .pth files execute automatically during Python interpreter startup, as eSecurity Planet noted, the payload ran on every subsequent Python process on the affected host, even if LiteLLM was never explicitly imported by the application. A simple pip install litellm==1.82.8 activated the credential stealer across all Python processes on that machine.
What the Malware Stole
Forcepoint’s analysis of the decoded payloads revealed a three-stage credential theft operation.
Stage one was data collection. The malware scanned environment variables and configuration files for API keys from OpenAI, Anthropic, and Azure AI services, cloud credentials for AWS, Google Cloud, and Microsoft Azure, and local files including ~/.kube/config and ~/.aws/credentials.
Stage two was encryption and exfiltration. The payload generated a 32-byte AES session key, encrypted collected data using AES-256-CBC with PBKDF2 key derivation, saved everything to a compressed archive (tpcp.tar.gz), and transmitted it to an attacker-controlled domain at hxxps://models.litellm.cloud/.
Stage three was persistence. The malware installed a polling-based remote code execution backdoor (Sysmon.py) that contacted a secondary command-and-control endpoint at hxxps://checkmarx.zone/raw every 50 minutes for additional payloads. The endpoint name itself was a deception: Checkmarx is a legitimate application security company that TeamPCP had separately compromised.
The Mercor Breach: 4 Terabytes, Three AI Labs Exposed
Mercor, a $10 billion AI data startup that provides vetted training data to Meta, OpenAI, and Anthropic, was among the thousands of organizations that installed the compromised LiteLLM packages. According to TechJuice, extortion group Lapsus$ subsequently claimed responsibility for the Mercor breach and began publishing stolen data on its leak site.
The published samples included Slack communications, internal ticketing data, and two videos showing conversations between Mercor’s AI systems and contractors. Lapsus$ claimed to possess four terabytes of data in total, including platform source code and database records.
Meta suspended all contracts with Mercor pending investigation, according to TechJuice. The company has not confirmed whether its own user data or AI training methodologies were exposed. Meta’s AI infrastructure spending is projected between $115 billion and $135 billion for 2026, making its training pipeline one of its most sensitive assets. OpenAI said it is investigating the incident but has not paused its projects with Mercor. Anthropic has not commented publicly.
A class-action lawsuit filed on April 1 alleges Mercor failed to maintain adequate cybersecurity protections, leaving more than 40,000 people exposed to identity theft and fraud, per TechJuice’s reporting.
TeamPCP: The Group Behind the Campaign
TeamPCP emerged in late 2025, according to Indian Express, initially exploiting cloud misconfigurations and a vulnerability in Next.js to deploy credential-stealing botnets. The group’s attacks appear to be financially motivated, combining ransomware deployment with data extortion campaigns.
The group’s operational model is cyclical. According to Indian Express, TeamPCP gains access to networks where open-source developer tools are being maintained, plants malware in those tools to compromise other developers’ machines, then uses stolen credentials to publish malicious versions of additional developer tools. The compromised network grows as the cycle repeats. The group has automated much of this process using a self-spreading worm called “Mini Shai-Hulud.”
Google’s Threat Intelligence Group identified TeamPCP (also tracked as UNC6780) as responsible for tampering with GitHub repositories associated with Trivy, Checkmarx, LiteLLM, and BerriAI, according to Okoone’s analysis. TeamPCP transitioned to a ransomware-as-a-service model in April 2026 by establishing partnerships with cybercriminal platforms BreachForums and DragonForce, according to Indian Express.
The group’s most recent known target is GitHub itself. Indian Express reported that TeamPCP is believed to be behind a breach that compromised at least 3,800 internal GitHub repositories. On BreachForums, the group posted: “We are here today to advertise GitHub’s source code and internal orgs for sale.”
The Broader Pattern: 50 Days, Multiple Actors, One Playbook
The LiteLLM attack is one node in a broader supply chain offensive that BoostSecurity documented across April and May 2026. The timeline includes:
April 30: Malicious PyTorch Lightning packages published to PyPI with full credential theft on import.
May 9: A trojanized Checkmarx Jenkins plugin published to the Jenkins Marketplace using credentials stolen from the March Checkmarx breach.
May 11: 84 malicious versions across 42 TanStack npm packages published via TanStack’s own legitimate CI in approximately six minutes, chaining a pull_request_target exploitation with Actions cache poisoning and OIDC token extraction from process memory.
According to BoostSecurity, the payloads across these campaigns now include blockchain-based command-and-control infrastructure that resists takedown, wipers triggered on GitHub token revocation, password vault targeting (including Bitwarden credential extraction), and credential harvesting across 17 CI/CD platforms.
“It is no longer one actor, nor one way of doing things,” BoostSecurity wrote. “Attackers have figured out just how vulnerable this area is. TeamPCP developed Shai-hulud, then open sourced it, and now there are copy cats.”
Why Provenance Alone Does Not Solve This
The TanStack incident, documented in the same BoostSecurity timeline, is particularly instructive. The malicious packages were built and signed through TanStack’s own legitimate CI pipeline, carrying valid SLSA Build Level 3 provenance attestations. Every automated compliance check said the packages were trustworthy. They were not.
As Okoone’s analysis observed: “Provenance proves where code came from. You can authenticate a malicious build as easily as a clean one if an attacker controls the build environment.”
This has direct implications for AI infrastructure. LiteLLM sits at the routing layer between applications and LLM providers. Compromising it gives attackers access to every API key, every cloud credential, and every model call flowing through the proxy. According to SiliconANGLE, trusted intermediary tools like LiteLLM represent an underexamined attack surface, because they combine high privilege (access to all downstream credentials) with high trust (widely adopted, frequently auto-updated).
The Infrastructure Dependency Problem
The core architectural issue is concentration risk. LiteLLM’s 95 million monthly downloads mean it is embedded in production AI gateways, internal developer tooling, vector pipelines, agent frameworks, and routing layers across thousands of AI-native products, according to Okoone. A single compromised version propagates through all of them simultaneously.
The Mercor breach illustrates how this concentration amplifies downstream risk. Mercor’s position as a shared data supplier for Meta, OpenAI, and Anthropic means that a single point of compromise at one vendor cascaded into exposure across three of the largest AI labs. When competing AI companies rely on the same third-party infrastructure, a single attack surface becomes an industry-wide vulnerability.
This is happening against a backdrop of rapid AI infrastructure scaling. Alphabet announced an $80 billion equity raise on June 1 to fund AI compute expansion. Meta projects $115 to $135 billion in AI infrastructure spending for 2026. The companies building the most capital-intensive AI infrastructure in history are simultaneously dependent on open-source libraries maintained by small teams with minimal security budgets.
What Comes After 40 Minutes
The LiteLLM packages were live for 40 minutes. The Mercor investigation, Meta’s contract suspension, and the class-action lawsuit are still ongoing months later. BerriAI, the company behind LiteLLM, has launched an enterprise-supported tier and tightened release controls. LiteLLM has shifted to Vanta compliance processes, according to reporting from multiple outlets.
The broader industry response is still forming. BoostSecurity recommends organizations get visibility into everything installed across developer endpoints, source code management, and CI/CD pipelines, harden CI/CD pipelines beyond default configurations, and assume developer tokens are already or will soon be compromised.
“This is happening to companies like Checkmarx, Aqua, Microsoft, OpenAI, and GitHub themselves,” BoostSecurity noted. “These companies know security. This problem is just too hard for now.”
For teams running AI agents in production, the LiteLLM breach surfaces a specific question: how many libraries in your agent’s dependency tree have the same level of access to your API keys and cloud credentials as LiteLLM does? The answer, for most production agent deployments, is more than anyone has audited.