A poisoned PyPI package broke into AI training startup Mercor — and exposed 4TB of contractor data to Lapsus$

On March 31, 2026, Mercor — a $10 billion startup that provides AI data labeling, annotation, and contractor management services to OpenAI, Anthropic, Meta, and Google — confirmed a breach that security researchers are calling one of the most consequential supply chain attacks against the AI industry to date. Approximately 4TB of data was exfiltrated: 939GB of platform source code, 211GB of user database records, and roughly 3TB of storage bucket contents including contractor passport scans, Social Security numbers, identity verification documents, and video recordings of technical interviews. The group claiming responsibility is Lapsus$, which has listed the stolen data for auction on its dark web marketplace. Five class-action lawsuits have already been filed against Mercor by affected contractors.

The attack chain: three hops from scanner to production

What makes this breach technically distinctive is the attack path. This was not a direct intrusion into Mercor's systems. It was a three-stage supply chain attack that moved through the open-source tooling ecosystem before reaching any production environment.

Hop 1 — March 19: Trivy is compromised. Trivy is a widely used open-source vulnerability scanner, maintained by Aqua Security and integrated into CI/CD pipelines across thousands of organizations. The attacker group, operating under the name TeamPCP, gained write access to Trivy's release artifacts. The exact initial vector into Trivy has not been publicly disclosed, but the result was that TeamPCP had the ability to influence what Trivy executed during its scanning runs.

Hop 2: CI/CD credential extraction from LiteLLM. LiteLLM — a popular open-source Python library that provides a unified API gateway for calling different large language model providers — used Trivy as part of its automated CI/CD pipeline to scan containers and dependencies for known vulnerabilities. Critically, LiteLLM's CI/CD configuration did not pin Trivy to a specific version hash. It pulled Trivy without version locking, which meant that when the compromised Trivy ran inside LiteLLM's build environment, it had access to the pipeline's secrets: PyPI publish credentials, repository tokens, and environment variables. TeamPCP extracted those credentials through the compromised scanner during a routine build run.

Hop 3 — March 27: Malicious LiteLLM versions on PyPI. Armed with LiteLLM's PyPI publishing credentials, TeamPCP pushed two malicious releases: litellm==1.82.7 and litellm==1.82.8. The packages were functionally identical to the legitimate releases in their surface behavior — they passed basic import tests and could route LLM API calls normally. The injected payload executed on import or on first use, establishing outbound connectivity and exfiltrating environment variables, API keys, and filesystem paths accessible to the running process. Any organization pulling these versions into a production environment — via pip install litellm without version pinning, or via dependency update automation — ran attacker-controlled code.

Mercor was one of those organizations. Given that LiteLLM is used throughout the AI development ecosystem as infrastructure for building applications that call GPT-4, Claude, Gemini, and other models, the exposure window was broad. Mercor's platform, which manages contractor workflows, stores contractor identity documents, and handles proprietary training data for major AI labs, was a high-value target within that window.

What was stolen

The data exfiltrated from Mercor breaks down into three categories, each with distinct risk profiles:

• 939GB of platform source code. This includes Mercor's contractor management system, evaluation tooling, and the interfaces through which contractors interact with AI training tasks. For Mercor's clients — OpenAI, Anthropic, Meta, Google — the exposure of this code potentially reveals how their training pipelines are structured at the contractor interface layer, what types of tasks are routed through Mercor, and what quality control mechanisms are in place.
• 211GB of user database records. This includes contractor profiles, account metadata, payment records, and internal correspondence. The exact schema has not been confirmed, but given Mercor's compliance requirements for contractor onboarding, the database almost certainly includes personally identifiable information for tens of thousands of contractors.
• ~3TB of storage bucket contents. This is the most sensitive category for individual contractors. Storage buckets contained video recordings of technical interviews used for identity verification and competency screening, government-issued ID scans including passports and national ID cards, Social Security numbers collected during US contractor onboarding, and identity verification documents submitted to satisfy KYC requirements. The combination of biometric video, government ID, and SSN represents a complete identity package for the affected contractors — sufficient for identity theft, synthetic identity fraud, and targeted social engineering.

Why AI training supply chains are a uniquely sensitive target

A breach of a standard SaaS contractor management platform would be serious primarily for the personal data exposure. Mercor's breach is categorically different because of what contractors working through Mercor actually handle.

AI contractors at the level of Mercor's client base are not doing generic data entry. They are performing tasks that touch the most proprietary and competitively sensitive aspects of AI development: evaluating model outputs on capability benchmarks that have not been publicly released, annotating edge cases that reveal where a model currently fails, rating responses according to criteria that encode a company's RLHF training methodology, and testing safety filters in ways that expose what the model can and cannot do. The instructions, rubrics, and task specifications that contractors receive are the intellectual core of how these labs train and align their models.

Mercor's source code — which includes the interfaces and tooling through which these tasks are delivered — could expose those methodologies even if the individual task data itself was not in the exfiltrated set. For an adversary building a competing model, or for a state actor attempting to understand the safety boundaries and training techniques of frontier AI systems, this represents access to information that cannot be reconstructed from public research.

Downstream response

The response from Mercor's clients has been measured but significant. Meta indefinitely paused all data work routed through Mercor on April 2, two days after the breach was confirmed, citing uncertainty about the integrity of the contractor environment and the potential exposure of task specifications. OpenAI and Anthropic both issued statements confirming they are auditing their exposure — specifically reviewing whether any proprietary training data, annotation rubrics, or evaluation frameworks were accessible to contractors through Mercor's now-compromised platform at the time of the breach.

Neither OpenAI nor Anthropic has confirmed whether proprietary training materials were within the exfiltrated data. The 939GB source code dump is the most likely vector for indirect exposure: if Mercor's platform source code includes embedded task templates, evaluation criteria, or model output samples used for training contractor quality, those would now be in Lapsus$'s possession.

Lapsus$ has listed the full 4TB dataset for auction on its dark web market, with what sources describe as a seven-figure asking price. The group has a documented history of following through on data sales — most notably with data stolen from Nvidia, Samsung, and Microsoft in 2022 — which gives the auction listing credibility beyond a typical extortion threat.

Five class-action lawsuits have been filed in US federal court by affected contractors, alleging negligent data security practices, failure to implement adequate supply chain controls, and inadequate notification following the breach. The lawsuits name Mercor specifically; none have yet named the AI companies whose contractor programs were hosted on the platform.

What developers should do

If your codebase uses LiteLLM, the immediate steps are specific:

• Check your installed version. Run pip show litellm or inspect your requirements.txt, pyproject.toml, or lockfile. If you have litellm==1.82.7 or litellm==1.82.8 anywhere in your dependency graph — including transitive dependencies — treat the environment as compromised. Rotate all secrets accessible to that process: API keys, database credentials, cloud provider tokens, and any environment variables.
• Audit your PyPI dependency pinning strategy. Any dependency pulled with a version range (litellm>=1.82) or no version constraint at all (litellm) was vulnerable to this class of attack. Pin to exact versions and use a lockfile (Poetry's poetry.lock or pip's pip-compile generated requirements.txt) that includes hashes. The hash-pinning flag --require-hashes in pip makes it impossible to install a package whose content doesn't match the recorded hash, even if an attacker replaces a version on PyPI.
• Review your CI/CD tool version pinning. The LiteLLM breach originated because Trivy was not pinned to a specific version in LiteLLM's build pipeline. Every tool in your CI/CD pipeline — scanners, linters, build tools, test runners — should be pinned to a specific version and ideally to a content hash. GitHub Actions allows pinning actions to a full commit SHA rather than a tag, which prevents tag-mutable attacks. For container-based tools like Trivy, pin to the image digest (aquasec/trivy@sha256:...), not the tag (aquasec/trivy:latest).
• Audit what secrets are accessible in your build environment. PyPI publish credentials should never be available as environment variables in the same pipeline step that runs dependency scanning or testing. Use separate pipeline jobs with distinct credential scopes, and apply least-privilege principles to what secrets each step can access.

The pattern: supply chain attacks against developer tooling

The LiteLLM attack is the latest in a sequence of supply chain attacks that have progressively targeted deeper layers of the developer tooling stack:

• SolarWinds (December 2020): Nation-state actors (APT29/Cozy Bear) compromised SolarWinds' build system, injecting a backdoor into the Orion platform distributed to ~18,000 organizations including US federal agencies. The attack vector was the build pipeline itself.
• Codecov (April 2021): Attackers modified Codecov's bash uploader script hosted on its own infrastructure. Any CI/CD pipeline that ran the script — a common pattern for code coverage reporting — uploaded environment variables, including secrets, to attacker-controlled servers.
• xz Utils (March 2024): A sophisticated multi-year social engineering campaign resulted in a backdoor being merged into the xz compression library, targeting SSH server authentication on Linux systems. The attacker spent two years building trust as a legitimate contributor before inserting the malicious code.
• LiteLLM via Trivy (March 2026): A vulnerability scanner used without version pinning became the entry point for credential theft, which then enabled a malicious package to be published to PyPI under a trusted library's name.

The through-line is consistent: attackers are not breaking through hardened application defenses. They are exploiting the trust relationships between tools that developers rely on to build, test, and deploy software. As AI development tooling becomes more interconnected — with libraries like LiteLLM serving as critical infrastructure for routing calls to frontier models — the blast radius of a single compromised dependency grows proportionally. The Mercor breach is not an outlier. It is an illustration of what the next several years of supply chain attacks against the AI industry will look like.