On March 31, 2026, AI talent startup Mercor confirmed it had been hit by a cascading supply-chain cyberattack tied to the compromise of LiteLLM, an open-source AI gateway library downloaded roughly 95 million times per month. According to a post-mortem published by security firm Halborn, attackers exfiltrated approximately 4 TB of internal data – including Slack archives, source code, ticketing logs, contractor passport scans, Social Security numbers, and interview recordings – turning what looked like a routine dependency update into one of the most consequential AI supply-chain incidents of 2026.
The Mercor breach is not just another startup security story. The company sits at a structural chokepoint of the modern AI economy: it recruits, vets, and pays the human experts who train frontier models for OpenAI, Anthropic, Meta, and Google – a position investors have priced aggressively, taking Mercor from a $2 billion valuation on a $100 million Series B in February 2025 to a $10 billion valuation on a $350 million Series C that October, according to TechCrunch and CNBC. The same LiteLLM compromise that hit Mercor also rippled into “thousands of companies,” according to the disclosure Mercor gave TechCrunch, and the attacker – variously identified as TeamPCP with subsequent claims by the Lapsus$ extortion group – used a single tainted dependency to reach data that touches almost every major AI lab on Earth.
This news analysis breaks down what happened, who is exposed, why LiteLLM became the single point of failure for an entire ecosystem, and what the incident means for AI infrastructure procurement, open-source dependency hygiene, and venture-funded “move fast” startups handling personally identifiable information for the most valuable companies in technology.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Happened: Mercor Confirms LiteLLM-Linked Breach on March 31, 2026
Mercor publicly acknowledged the incident on Tuesday, March 31, 2026, telling TechCrunch it was “one of thousands of companies” affected by a recent compromise of the LiteLLM open-source project. The same day, The Record reported that an extortion crew identified as TeamPCP appeared to be behind the original LiteLLM intrusion, while the better-known Lapsus$ group claimed on its leak site that it had obtained Mercor’s data.
The compromise of LiteLLM itself surfaced roughly a week earlier in March, after security researchers spotted malicious code in a package associated with the project. By the time the bad version was identified and pulled, it had already propagated into the build pipelines, CI runners, and runtime containers of any organization whose dependency resolver picked up the tainted release. Mercor was among the casualties.
The Halborn write-up describes a multi-stage chain in which the attacker first compromised Trivy, an open-source vulnerability scanner widely used in DevSecOps pipelines, and then used that foothold to insert malicious code into a LiteLLM package. The poisoned package was removed within hours, but “within hours” is a long time when a library is downloading at roughly 95 million pulls per month. Some independent analyses tracking the attribution to a CVE-2026-33634 identifier remain unconfirmed by primary reporting and should be treated as preliminary.
Who Is Mercor and Why This Breach Matters
Mercor is a Y Combinator-backed AI talent marketplace that connects domain experts – physicians, lawyers, software engineers, mathematicians, linguists – with the labs training frontier models. In practical terms, when a leading AI lab needs to fine-tune a model on graduate-level chemistry problems, an evaluator marketplace like Mercor sources, screens, and pays the chemists. By October 2025, Mercor told CNBC it had more than 30,000 contractors on its platform and was paying them upward of $1.5 million per day – a scale of financial and identity data that made the LiteLLM-linked breach far more consequential than a typical vendor incident. Mercor’s customer set, according to multiple reports and the Halborn analysis, includes OpenAI, Anthropic, Meta, and Google.
That positioning is what makes the breach uniquely sensitive. The data Mercor handles is not just a typical SaaS dataset. It includes:
- Identity documents – passport scans, government IDs, and biometric onboarding artifacts for contractors located worldwide.
- Social Security numbers and US tax forms for US-based contractors paid as 1099 vendors.
- Interview videos, including audio of expert assessments that frequently reveal which lab a contractor is being routed to.
- Internal Slack data and ticketing logs that name lab contacts and procurement timelines.
- Source code and infrastructure-as-code repositories for Mercor’s internal evaluation tooling.
- Contractor PII at scale – reportedly more than 40,000 contractors, with one analysis citing a 211 GB user database within the 4 TB total.
This is not a credit-card breach where the blast radius is bounded by issuer chargebacks. It is a deeply personal data set tied to a workforce that signs NDAs precisely because their identities, employers, and rates would compromise the AI labs they serve. The mapping of who works on which model, who is paid how much, and which lab is staffing up on which capability is, in effect, a competitive-intelligence document for the entire frontier-AI industry.
Inside LiteLLM: The 95 Million-Download Library at the Heart of the Attack
LiteLLM is a Python library and proxy maintained by BerriAI that gives developers a unified, OpenAI-compatible interface to more than 100 LLM providers – OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex, Cohere, Mistral, local Ollama, and many more. For engineering teams that want to swap providers without rewriting application code, LiteLLM is effectively the universal adapter of the LLM ecosystem.
That ubiquity is exactly what made it a high-value target. Industry reporting cited in the Strikegraph analysis puts LiteLLM downloads at roughly 95 million per month, with daily pulls in the millions. The library is embedded in production AI gateways, internal developer tooling, vector pipelines, agent frameworks, and the routing layers of many AI-native SaaS products. A maintainer commit, a release tag, or a transitive dependency that flips malicious does not just hit one company – it hits the long tail of every product built on top of LiteLLM, simultaneously.
The maintainers responded to the incident with several visible compliance and process changes, including the widely reported decision to move security/compliance tooling from examine to Vanta, formalize signed releases, and tighten contributor vetting. The library remains the dominant open-source LLM gateway, but the breach has accelerated a discussion that had been brewing for at least a year: should mission-critical AI infrastructure depend on a single fast-moving open-source project run by a small team?
Attack Chain: Trivy to LiteLLM to Mercor to 4 TB Out the Door
The cleanest reconstruction of the attack chain comes from the Halborn post-mortem and the dependency-analysis discussion on Hacker News. The intrusion can be summarized in four stages.
Stage 1 – Initial compromise of Trivy
Attackers first compromised Trivy, the popular open-source container and dependency scanner. Trivy is bundled into CI/CD pipelines specifically to detect vulnerable packages, which makes its compromise particularly cynical: a tool teams trust to surface supply-chain risk became the vector for the supply-chain attack itself.
Stage 2 – Malicious code injected into LiteLLM
Using the Trivy foothold and access to the LiteLLM build environment, attackers shipped a poisoned LiteLLM package. Any organization with an unpinned LiteLLM dependency – `litellm` without a hash, or with a loose constraint such as `>=` – could resolve to the malicious version on the next build. Teams that pinned via `poetry.lock`, `uv.lock`, or `requirements.txt` with hashes were largely spared, a critical lesson echoed in the post-incident commentary.
Stage 3 – Credential exfiltration from downstream environments
Once running inside thousands of build and runtime environments, the malicious payload exfiltrated API keys, cloud credentials, and OAuth tokens. Because LiteLLM is by design a gateway that sees provider API keys (OpenAI keys, Anthropic keys, AWS credentials), the value of the harvested credentials was disproportionately high.
Stage 4 – Lateral movement into Mercor
With harvested credentials, the attackers pivoted into Mercor’s internal stack – Slack, source code repos, ticketing, internal databases, and an interview-video store – and exfiltrated an estimated 4 TB of data. That figure remains a reported estimate rather than an audited number, but it aligns with the breadth of artifacts that subsequently appeared on the Lapsus$ leak site.
The Numbers: Mercor LiteLLM Breach by the Data
| Metric | Value | Source / Notes |
|---|---|---|
| Date Mercor confirmed breach | March 31, 2026 | TechCrunch, The Record |
| LiteLLM monthly downloads | ~95,000,000 | Strikegraph analysis |
| Data reportedly exfiltrated | ~4 TB | Halborn post-mortem (reported estimate) |
| Contractors potentially exposed | 40,000+ | Independent analysis |
| User database snapshot | ~211 GB | Halborn write-up |
| Affected organizations (broad LiteLLM) | “Thousands” | Mercor statement to TechCrunch |
| Top customers exposed via Mercor | OpenAI, Anthropic, Meta, Google | Halborn, Strikegraph |
| Threat actors named | TeamPCP, Lapsus$ | The Record |
| Initial dependency compromised upstream | Trivy | Halborn analysis |
| Reported CVE identifier (unconfirmed) | CVE-2026-33634 | Secondary analysis |
| Compliance vendor switch by LiteLLM | examine to Vanta | Hacker News thread |
Expert Reaction: What Security Leaders Are Saying
The Mercor disclosure landed in a security community that has spent two years bracing for exactly this kind of attack. Reactions clustered around three themes: the inevitability of LLM supply-chain compromise, the under-investment in dependency hygiene at AI-native startups, and the asymmetric blast radius that any popular open-source AI library now creates.
Halborn security analyst Steven Walbroehl framed the incident as the predictable consequence of “speed-over-safety” in AI tooling, writing in the firm’s post-mortem that “the Mercor hack illustrates how a single compromised upstream dependency can cascade across an entire industry vertical in days, not weeks.” Walbroehl emphasized that the attacker did not need to breach OpenAI, Anthropic, or Meta directly – they needed to breach a small library used by the companies serving those labs.
Strikegraph CEO Justin Beals argued in a public analysis that the breach “exposed Silicon Valley’s fragile AI supply chain,” pointing out that the venture-funded AI tooling layer has not absorbed lessons from the SolarWinds, Codecov, or 3CX supply-chain incidents. “The same teams that ship a new agent framework every two weeks have not staffed appsec at parity,” Beals wrote.
On Hacker News, security engineer Tavis Ormandy noted in a widely upvoted comment that teams using strict lockfiles “essentially dodged the entire attack,” and that the industry’s tolerance for floating dependencies in production AI workloads is now harder to defend. OWASP’s Steve Wilson, co-author of the OWASP Top 10 for LLM Applications, told reporters in follow-up coverage that LLM03 (Supply Chain Vulnerabilities) “moved from theoretical to operational” with the LiteLLM compromise. Sonatype CTO Brian Fox, whose firm publishes the annual State of the Software Supply Chain report, has long argued that malicious package activity is rising faster than developer tooling can keep up – a thesis the Mercor incident makes painfully concrete.
Why This Hit AI Labs Without Touching Their Networks
One of the most uncomfortable aspects of the Mercor breach for OpenAI, Anthropic, Meta, and Google is that none of their own networks needed to be compromised for sensitive information about their training pipelines to spill into the open. The attacker exploited the modern AI labor model: labs do not directly employ tens of thousands of subject-matter experts. They contract with intermediaries like Mercor, Scale AI, Invisible, Surge, and Turing to supply, vet, and pay those experts. The intermediaries necessarily hold:
- Which evaluators worked on which model versions and with which rubrics.
- Pay scales for different evaluator types, by region, by skill, by lab.
- Internal communications between lab program managers and the vendor.
- Snippets of model behavior captured in red-teaming or evaluation transcripts.
- Roadmap-adjacent data – when a lab ramps a particular evaluator pool, it telegraphs what capability is being trained next.
The Lapsus$ leak claims contain references to this kind of meta-information. Even if no model weights leaked – and there is no public evidence they did – the strategic intelligence in a Mercor data dump is substantial. Competitive-intelligence teams across the industry are reportedly mining the leak for staffing signals, in much the same way Wall Street mines satellite parking-lot imagery for retail sales forecasts.
Historical Context: The Mercor Hack in the 2024–2026 Supply-Chain Wave
The Mercor incident did not happen in a vacuum. It is the latest in a multi-year cadence of high-profile open-source supply-chain attacks that have accelerated since the SolarWinds breach in 2020. Each successive incident has shortened the window between dependency compromise and downstream impact.
| Incident | Year | Vector | Downstream Reach | Key Lesson |
|---|---|---|---|---|
| SolarWinds Orion | 2020 | Build-system compromise | 18,000+ orgs, 9 US agencies | Signed builds are not enough |
| Codecov Bash Uploader | 2021 | CI script tampering | 23,000+ Codecov customers | CI scripts are a privileged path |
| xz-utils backdoor | 2024 | Long-term maintainer infiltration | Narrowly avoided distro-wide impact | Solo maintainers are a risk surface |
| 3CX desktop app | 2023 | Trojanized binary update | 600,000+ companies | Vendor updates need attestation |
| PyTorch dependency confusion | 2022 | Malicious “torchtriton” package | ~2,300 daily downloads compromised | Index priority matters |
| LiteLLM / Mercor | 2026 | Trivy to LiteLLM to downstream | “Thousands” of orgs; ~4 TB at Mercor | AI gateways are critical infra |
The pattern is consistent. The chokepoints keep moving from operating systems (early-2000s patch worms) to OS-level package managers (2010s npm and PyPI), to CI/CD systems (Codecov era), to identity and SaaS (Okta, MOVEit), and now to AI-specific middleware. LiteLLM is to the LLM stack what log4j was to Java logging in 2021 – a piece of plumbing so common it is no longer treated as a third-party dependency at all.
Mercor’s Customer Exposure: OpenAI, Anthropic, Meta, Google
None of Mercor’s lab customers have publicly confirmed that their model training data or weights were touched. What they have to assess privately is whether evaluator metadata, NDAs, rubrics, or program management correspondence in Mercor’s environment qualifies as a notifiable disclosure under their own customer contracts and the proliferating set of US state breach-notification laws.
Lab-side concerns reportedly include:
- Evaluation rubric leakage. If detailed scoring rubrics for capability evaluations are in the leak, public-benchmark contamination risk goes up because future training data may inadvertently memorize them.
- Red-team prompt exposure. Excerpts of jailbreak prompts or safety probes used by labs would give threat actors a free starter kit.
- Headcount/program signals. A 40% ramp in physics PhD evaluators in one quarter is a strong public signal about a lab’s near-term roadmap.
- NDA/contractor identity disclosure. Many lab contractors signed strict NDAs; doxing them is a downstream HR and legal liability for the labs as much as for Mercor.
The Information has previously reported that Mercor’s annualized revenue run-rate crossed nine figures in 2025 on the back of fast-growing lab contracts – TechCrunch put the run-rate above $75 million as early as February 2025, and SiliconAngle later tracked annualized revenue climbing from roughly $100 million in March 2025 to more than $450 million by September 2025. The growth has only accelerated since: Sacra estimated Mercor’s annualized gross revenue reached $2.0 billion by June 2026, up from $760 million at the end of 2025, while ValueAddVC separately pegged the run-rate at roughly $2 billion after it doubled in just four months. Whether labs respond by diversifying away from Mercor, by demanding stronger contractual security guarantees, or by absorbing more evaluation in-house will shape competitive dynamics in the human-evaluation segment for the rest of 2026.
Market Impact: Pricing in the AI Supply-Chain Risk
Mercor is privately held, so there is no listed-equity reaction to point to. But the broader market effects of the breach are visible across at least four segments:
- AI evaluator marketplaces. Competitors including Scale AI, Invisible, Surge, and Turing have seen renewed interest from labs reassessing single-vendor concentration. Procurement teams are reportedly accelerating second-source contracts.
- AI gateway software. Demand for self-hosted, vetted, or commercially supported alternatives to LiteLLM – including paid offerings from BerriAI itself, plus Cloudflare AI Gateway, Portkey, and Helicone – has spiked.
- Application security tooling. SBOM, SCA, and runtime-attestation vendors (Snyk, Sonatype, Aqua, Chainguard, Endor Labs) have leaned heavily into Mercor-themed messaging about pinning, signing, and provenance.
- Cyber insurance. Underwriters are reportedly tightening exclusions for “AI dependency” exposures in renewal cycles starting Q2 2026, with some markets adding explicit questions about LLM gateway architecture on application forms.
The broader read-through is that AI infrastructure is graduating from “interesting third-party software” to systemically important plumbing, and the financial ecosystem around it – insurance, audit, procurement, regulator scrutiny – is catching up faster than the open-source maintainers can absorb the demands.
Regulatory Response and Notification Obligations
A privacy law firm public notice posted on April 9, 2026 flagged that, at the time of writing, Mercor had not filed notifications with state attorneys general – a statement intended to attract potential class action plaintiffs rather than a confirmed regulatory finding. Mercor’s data set spans US-based contractors (subject to state-level breach-notification laws and IRS reporting), EU contractors (GDPR Article 33 notifications within 72 hours), and contractors in jurisdictions including India, Brazil, and the UK that have their own data-protection regimes.
Practical regulatory pressure points that are likely to surface in coming weeks include:
- State AG notifications. California, New York, Texas, and Illinois have aggressive breach-notification statutes that are triggered by the presence of SSNs alongside names.
- FTC scrutiny. The FTC’s Section 5 authority has been used in recent years to penalize companies that failed to maintain “reasonable security” – open-dependency hygiene is now squarely in that category.
- GDPR data-subject rights. Affected EU contractors can demand DSARs that force Mercor to disclose precisely what categories of personal data were exfiltrated.
- SEC disclosure. While Mercor itself is private, lab customers that are public (Microsoft, Meta, Google’s Alphabet) must judge whether the incident is material to investors under the SEC’s 2023 cybersecurity disclosure rules.
Open-Source Maintainer Burden and the “Single Maintainer” Problem
The LiteLLM project is shepherded by BerriAI, a small commercial entity associated with the maintainers behind the library. The project’s velocity – frequent releases, hundreds of provider integrations, deep refactors of routing logic – is exactly what makes it valuable to users and exactly what makes it hard to harden. Every additional provider integration adds attack surface; every release tightens the temporal window in which a malicious commit can slip past review.
The post-incident playbook from BerriAI now reportedly includes:
- Mandatory two-person review on all release branches.
- Migrating compliance attestation from examine to Vanta, with continuous-control monitoring.
- Signed releases with SLSA-style provenance attestations.
- Tighter contributor identity verification on PR merges.
- A formal security disclosure program with a public PGP key and SLA.
These are the right moves. They are also the same moves the xz-utils incident in 2024 was supposed to trigger across the broader open-source ecosystem and largely did not. The structural question – how does a project downloaded 95 million times a month sustain enterprise-grade security on what is still effectively a venture-funded startup payroll? – does not have a clean answer.
Lessons for Engineering Teams: Concrete Mitigations
Engineering leaders re-reading their own dependency policies in the wake of the Mercor breach are converging on a short list of concrete actions. None of these are novel, but the incident has restored urgency to ideas the industry has been slow-walking:
- Pin every dependency with a hash. Use `poetry.lock`, `uv.lock`, `pip-compile –generate-hashes`, or `requirements.txt` with `–hash=` entries. Teams that did this dodged the LiteLLM payload.
- Vendor or proxy critical packages. Mirror packages through an internal registry (Artifactory, Cloudsmith, GitHub Packages) and refuse outbound builds that resolve from upstream.
- Restrict runtime egress. Containers running LiteLLM or any AI gateway should be unable to phone home to arbitrary destinations. Egress allowlists kill data exfiltration paths.
- Rotate provider keys aggressively. OpenAI, Anthropic, AWS, and Google keys handled by any gateway should have short TTLs and per-environment scoping.
- Build an SBOM and feed it to monitoring. A standing SBOM that triggers alerts when upstream advisories drop is the difference between hours and weeks of exposure.
- Adopt OWASP LLM Top 10 controls. LLM03 (Supply Chain), LLM06 (Sensitive Information Disclosure), and LLM10 (Model Theft) all touch this incident.
# Pin LiteLLM with a hash in requirements.txt
litellm==1.51.3
--hash=sha256:<verified-sha256-from-official-release>
# Or with Poetry – keep poetry.lock under version control
poetry add [email protected]
# Or with uv (faster, lockfile-first)
uv add litellm==1.51.3
uv lockFive Predictions: Where the Fallout Goes Next
The Mercor breach is a forcing function. Based on conversations with security leaders, procurement teams, and AI-infra builders, five outcomes look highly likely over the next 6–18 months:
- Lab procurement contracts will mandate dependency provenance. Expect OpenAI, Anthropic, Meta, and Google to require SLSA Level 3 or equivalent attestations from any vendor handling evaluator data by year-end 2026.
- BerriAI launches an enterprise-supported LiteLLM tier. A paid, SLA-backed offering with signed releases, dedicated security review, and named incident response is the natural commercial response – and a prerequisite for re-establishing trust with risk-averse buyers.
- Cyber-insurance carriers introduce AI-dependency riders. By Q4 2026, expect carriers to require an “LLM gateway architecture” attestation, mirroring the way ransomware riders evolved between 2020 and 2023.
- A second AI-marketplace breach forces consolidation. The structural target – vendors holding evaluator PII for multiple labs – is too valuable for attackers to leave alone. A second incident at a competing marketplace within 12 months would push labs to insource sensitive evaluation work, accelerating moats around in-house evaluator pipelines.
- Regulators name “AI critical infrastructure.” CISA, ENISA, and equivalent agencies in Asia have been edging toward formal designations for AI middleware. The Mercor incident is the kind of event that catalyzes a designation, with associated reporting and security baseline requirements.
Competitive Comparison: Mercor vs. Other AI Evaluator Marketplaces
The breach has thrown the competitive landscape of AI evaluator marketplaces into sharper relief. Procurement teams reassessing single-vendor concentration are looking at the same short list of alternatives. The table below summarizes the headline differences between Mercor and its closest peers as of April 2026; numbers should be treated as directional, drawn from public reporting and company disclosures.
| Marketplace | Founded | Backers | Positioning | Notable customers | Security posture (post-Mercor) |
|---|---|---|---|---|---|
| Mercor | 2022 | Y Combinator and follow-on investors | Expert evaluator network for frontier labs | OpenAI, Anthropic, Meta, Google | Under active remediation after March 2026 incident |
| Scale AI | 2016 | Tiger Global, Accel, others | Data labeling at industrial scale + evaluators | Multiple frontier labs, US DoD | SOC 2 Type II; mature appsec program |
| Surge AI | 2020 | Bootstrapped (reported) | Premium human feedback specialists | Anthropic and others | Quiet but disciplined |
| Invisible Technologies | 2015 | NEA, Tiger Global | AI operations + evaluator workflows | Multiple LLM platforms | Enterprise-grade onboarding |
| Turing | 2018 | WestBridge, Foundation Capital | Developer evaluators + remote talent | Multiple LLM platforms | SOC 2 Type II |
Mercor’s value proposition – fast access to high-quality domain experts on lab timelines – remains intact, and its growth curve has kept investors undeterred: CNBC reported the company logged more than 51% month-over-month revenue growth over a six-month stretch heading into 2025, and by July 2026 Forbes reported Mercor was in talks to raise $500 million at a $20 billion valuation – double its October 2025 mark in under a year. What the breach challenges is the implicit assumption that a fast-growing startup can carry enterprise-grade security posture without dedicated, named investment. That challenge applies, with varying degrees of urgency, to every peer in the table.
What This Says About the State of AI Infrastructure in 2026
The deeper story behind the Mercor breach is that the AI stack of 2026 looks structurally similar to the cloud stack of 2014: it is composed of a small number of widely shared open-source primitives – LiteLLM, LangChain, Triton, vLLM, Ray, Helm – that have moved from “interesting tools” to “load-bearing infrastructure” without the corresponding investment in dependency hygiene, signing, attestation, and incident response.
The cost of treating these projects as commodity dependencies is now visible. Thousands of organizations were silently exposed. A startup serving the four most strategically important labs in the world was breached without the attacker having to touch the labs themselves. And a project downloaded 95 million times per month is being asked, in retrospect, to operate as if it were a Tier-1 vendor – which it is, in everything but staffing and budget.
The Mercor LiteLLM breach is, in that sense, less of a security story and more of a market-structure story. The AI infrastructure stack has outgrown the institutional norms that surround it. The next 18 months will tell us whether the response is incremental – better SBOMs, more lockfiles, additional SOC 2 audits – or structural, with formal designation of AI middleware as critical infrastructure and a corresponding reset of how it is funded, audited, and operated.
FAQ: Mercor, LiteLLM, and the March 2026 Supply-Chain Breach
What is Mercor and why was it attacked?
Mercor is a Y Combinator-backed AI talent marketplace that recruits, vets, and pays expert evaluators for frontier AI labs including OpenAI, Anthropic, Meta, and Google. It was almost certainly targeted because of who its customers are: a single breach surfaces evaluator metadata, NDAs, and program signals tied to the most strategically important labs in the industry.
How was the Mercor LiteLLM breach carried out?
According to Halborn’s post-mortem, attackers first compromised Trivy, a widely used open-source vulnerability scanner. They used that foothold to inject malicious code into a LiteLLM release. Organizations that resolved the poisoned package – including Mercor – had credentials harvested, which were then used to pivot into Mercor’s Slack, source code, ticketing, and database environments.
How much data was stolen in the Mercor breach?
Independent analyses cite roughly 4 TB of exfiltrated data, including a ~211 GB user database, source code, Slack archives, interview videos, ticketing data, contractor passport scans, and Social Security numbers. The 4 TB figure is a reported estimate; Mercor has not published an audited number.
Were OpenAI, Anthropic, Meta, or Google directly breached?
There is no public evidence that the labs’ own networks were compromised. The exposure is indirect: Mercor’s data set contains information about evaluator programs run on behalf of those labs, including correspondence, rubrics, and staffing signals.
Who is responsible for the attack?
Initial reporting attributed the LiteLLM compromise to a group called TeamPCP. The extortion group Lapsus$ subsequently claimed on its leak site to have obtained Mercor’s data. Attribution may evolve as forensic analysis continues.
How can engineering teams protect themselves from a similar attack?
Pin every dependency with a hash (poetry.lock, uv.lock, or hashed requirements.txt), mirror packages through an internal registry, restrict outbound network egress from build and runtime environments, rotate provider API keys frequently, maintain a live SBOM tied to advisory feeds, and adopt the OWASP Top 10 for LLM Applications, especially LLM03 (Supply Chain Vulnerabilities).
Is it still safe to use LiteLLM?
The malicious release was removed within hours and BerriAI has tightened release controls, including a reported move from examine to Vanta for compliance and additional signing requirements. Teams that pinned dependencies were largely protected. Going forward, the prudent stance is to use the latest patched version, pin with hashes, restrict egress, and treat any AI gateway as critical infrastructure.
