On March 27, 2026, two malicious versions of LiteLLM (1.82.7 and 1.82.8) were published to PyPI. LiteLLM is an open-source Python library for connecting applications to AI services. It has 97 million monthly downloads and is present in an estimated 36% of cloud environments. The attack, attributed to a group called TeamPCP, targeted the library’s CI/CD pipeline directly and used it to harvest credentials from downstream users. One of those downstream users was Mercor.
Mercor is a $10 billion AI startup that acts as a primary training data contractor for OpenAI, Anthropic, and Meta. When multiple major AI labs share a data vendor, a single breach at that vendor becomes a simultaneous exposure event across the industry. Lapsus$ claims to have taken roughly four terabytes of data from Mercor, including source code, database records, Slack communications, and internal ticketing data. Unconfirmed reports suggest the haul includes proprietary training datasets and details about customers’ secretive AI projects. Meta has indefinitely paused all work with Mercor pending investigation.
The structural risk this exposes is new in character, even if supply chain attacks are not. The AI industry has treated training data as a core competitive moat — “highly secret as a core ingredient in the recipe to generate valuable AI models,” in the words of one security researcher. That moat depends on the data staying within the lab. When training data and pipeline specifications are outsourced to a shared contractor, all of the competitive secrecy built around them is only as strong as the contractor’s security posture. The comparison to the 2023 Cl0p MOVEit exploit is apt: a widely-deployed middleware library becomes a single point of failure across an entire industry’s supply chain.
Any team running AI infrastructure should understand how the LiteLLM attack worked. The malicious versions were published directly to PyPI, not via a compromised repository or dependency confusion attack. Teams that pin dependency versions in production are not necessarily protected if the malicious version was published before the pin was set and the package cache was not audited. The recommended response is to audit LiteLLM versions in any environment that touched 1.82.7 or 1.82.8, rotate any credentials stored in those environments, and check whether your CI/CD pipeline has write access to PyPI packages, since that is the vector the attackers exploited.
AI teams face a vendor security question that has not been asked systematically before: which of your third-party data and labelling contractors also work with your competitors, and what is their security posture? The shared-vendor model that makes specialised data work economical also creates a concentration risk. This breach is probably not the last time that risk materialises.