Mercor, the San Francisco AI recruiting and data-labeling startup valued at $10 billion, is once again being advertised on a cybercrime forum, with attackers claiming to hold roughly 4TB of company data and source code tied to work for OpenAI, Google, Meta, Microsoft and Anthropic. Cybernews reported the listing on 26 August 2026, one day after Dark Web Intelligence flagged it, and says its research team reviewed the seller's sample data and found it "comprehensive." Mercor has confirmed a separate but almost certainly related fact: that it was compromised in late March 2026 through poisoned versions of the open-source LiteLLM library, an incident the company describes as having hit "one of thousands of companies." What it has never confirmed is the 4TB figure, the authenticity of any leaked sample, or whether customer or contractor data was exfiltrated at all. Note the sourcing floor here: no primary regulator filing or vendor advisory is available, and Mercor's own statements reach us secondhand through TechCrunch and Wired reporting.
What Happened
The confirmed root event is a supply chain compromise of LiteLLM, an open-source routing library that sits between applications and AI model APIs and is downloaded on the order of 95 million times a month, per RiskScope's analysis. On 27 March 2026, someone using stolen PyPI publishing credentials pushed malicious versions 1.82.7 and 1.82.8, which carried a multi-stage backdoor built for credential harvesting and persistence. The poisoned packages were live for roughly 40 minutes before being pulled. Researchers have tied that operation to a group tracked as TeamPCP.
Mercor pulled a bad version. Mercor spokesperson Heidi Hagberg confirmed to TechCrunch that the company "moved promptly" to contain and remediate, and in the company's own words the malware "enabled the unauthorized actor to access some of our systems." RiskScope places the intrusion window at 24 to 30 March 2026, six days inside Mercor's environment. That window is worth reading carefully: it begins three days before the poisoned packages were published, which either means the attackers had another initial foothold or that the reconstructed timeline is imprecise. No source reconciles this.
Where accounts genuinely diverge is on the relationship between the March incident and the August listing. Cybernews frames the current 4TB sale as a new allegation arriving "just months after" the LiteLLM disclosure. But the volume, the composition (database plus source code), and the alleged victim are identical to what Lapsus$ was auctioning in April and July. Defenders should treat it as unresolved whether this is a second intrusion, a resale, or a recirculated listing of the same March haul.
Timeline and Attribution
- 27 March 2026: Poisoned LiteLLM 1.82.7 and 1.82.8 published to PyPI, live approximately 40 minutes.
- 24 to 30 March 2026: Attacker access to Mercor systems, per RiskScope.
- 31 March 2026: Mercor publicly acknowledges it was the target of a breach.
- 4 April 2026: Lapsus$ lists Mercor on its leak site and begins auctioning data. Meta indefinitely pauses its Mercor contracts, per Wired sources cited by TechCrunch.
- 21 April 2026: First class action filed in the Northern District of California.
- 25 to 26 June 2026: Mercor begins direct notification of affected individuals, offering TransUnion identity protection.
- 22 to 23 July 2026: Researcher Dominic Alvieri posts that Mercor data has been sold. Cybersecurity Times separately attributes an Alvieri post to 31 March, so the date of the original researcher claim is inconsistent across reporting.
- 24 July 2026: Lapsus$ announces it is ceasing all operations, claiming it sold Mercor data to buyers in China.
- 25 to 26 August 2026: A 4TB Mercor database and source code listing surfaces on a cybercrime forum.
Attribution splits cleanly across two actors. TeamPCP is credited with the LiteLLM package compromise. Lapsus$ claimed the Mercor data and ran the extortion. No source explains how Lapsus$ obtained data harvested through TeamPCP's operation, and TechCrunch says so explicitly.
What Was Taken
Nothing in the inventory below is confirmed by Mercor. The most granular breakdown comes from Cybersecurity Times and RiskScope, which broadly agree:
- Approximately 939GB of proprietary platform source code.
- A 211GB user and candidate database, described by RiskScope as containing Social Security numbers and full personal information.
- Roughly 3TB of storage bucket content. Cybersecurity Times describes this generically; RiskScope characterizes it specifically as contractor voice recordings and AI video interview footage.
- Government-issued ID scans, passports and driver's licenses. RiskScope ties these to more than 40,000 people, a figure that lines up with the class action's stated scope reported by TNW.
- W-9 tax forms, banking details, background check materials, and screenshots captured from contractors' own machines by monitoring software.
- API keys, employer data and candidate profiles, per TechCrunch's earlier summary of the hackers' claims.
The TechCrunch sample review is the closest thing to independent corroboration: reporters examined material referencing Slack data, apparent ticketing data, and two videos purportedly showing conversations between Mercor's AI systems and platform contractors.
Mercor's own position, following an investigation with Google Mandiant, Latacora, law enforcement and industry peers, is materially narrower. The company says only a "very limited subset" of its nearly 5 million experts had sensitive information affected, and that it found no evidence of fraudulent use. That is a wide gap: 40,000-plus notified individuals against a claimed 211GB database and 3TB of media, versus a "very limited subset" framing. Both statements can be technically true at once, but they point at very different blast radii, and readers should not treat either as settled.
The Lapsus$ claim that the data was sold to Chinese buyers originates entirely with the threat actor, is unverified, and Mercor has confirmed no sale, public leak, or misuse.
Why It Matters
Mercor is not a household brand, but it occupies a chokepoint in the AI supply chain. Founded in 2023 by Brendan Foody, Adarsh Hiremath and Surya Midha, it recruits networks of domain experts, doctors, lawyers, scientists, bankers, journalists, to produce bespoke training data for frontier labs. It says it facilitates more than $2 million in daily payouts, and closed a $350 million Series C led by Felicis Ventures in October 2025 at a $10 billion valuation.
That means the sensitive material here is not just PII. It is the methodology layer: the custom datasets, rubrics and processes that labs use to train models, which several sources describe as among the industry's most closely guarded trade secrets. The commercial reaction tracks that assessment. Meta paused its Mercor work indefinitely, per Wired sources. OpenAI confirmed to Wired it was investigating its exposure but had not paused or terminated contracts at that time. TechCrunch reported hearing from multiple sources that other large model makers were weighing their relationships, while cautioning it had not confirmed enough detail. For context on the stakes, Meta continued working with Mercor even after spending $14.3 billion on competitor Scale AI.
The second-order risk is biometric. A dataset pairing hours of clean voice recordings and video interview footage with passport scans, SSNs and banking details is close to an ideal input for synthetic identity fraud and voice-cloning attacks; off-the-shelf cloning tools need roughly fifteen seconds of clean reference audio. Every one of those 40,000 people submitted the material voluntarily, believing they were applying for a job. That is a category of exposure that credit monitoring does not remediate, because a face and a voice cannot be reissued.
The Attack Technique
The chain is a textbook package-registry compromise escalating into a credential cascade. Attackers stole LiteLLM's PyPI publishing credentials and shipped a multi-stage backdoor inside two legitimate-looking point releases. Any environment that installed 1.82.7 or 1.82.8 during the roughly 40-minute exposure window executed credential-harvesting code. Those harvested credentials unlocked further software and accounts, which yielded more credentials, and so on, which is how a 40-minute window converts into six days of access and terabyte-scale exfiltration.
Cybersecurity Times reports the Mercor data allegedly stemmed from the company's Tailscale VPN environment, which is consistent with a stolen-credential path into a flat internal network. That specific detail comes from a single lower-tier source and has not been independently verified; neither Mercor nor Tailscale has confirmed it, and there is no indication of any flaw in Tailscale itself.
Two properties make this hard to defend against with conventional controls. First, the malicious artifacts were signed and served by the legitimate publisher, so provenance checks that stop at "is this the real package name from the real index" pass cleanly. Second, the exposure window was short enough that most scheduled dependency scans would never have seen it, but long enough for automated CI/CD pipelines pulling unpinned versions to ingest it.
What Organizations Should Do
- Pin and verify dependencies rather than tracking latest. Use hash-pinned lockfiles for every Python and Node dependency in build and production paths, and enforce them in CI. A version-range install of LiteLLM during that 40-minute window was the entire attack.
- Retroactively hunt for LiteLLM 1.82.7 and 1.82.8. Query artifact caches, container image layers, CI logs and SBOMs going back to 27 March 2026. Treat any host that installed them as credential-compromised, not merely as needing an upgrade.
- Rotate on the assumption of harvest. Any long-lived API key, service account token, cloud credential or VPN identity that was present on an affected host should be rotated, and prior sessions revoked. Move toward short-lived, workload-bound credentials so a single harvesting event has a limited useful life.
- Segment internal network access. A compromised developer credential should not yield reachability to source repositories, production storage buckets and the candidate database. Apply per-service authorization to VPN and mesh network access rather than treating network presence as trust.
- Instrument for bulk egress. Terabyte-scale movement out of object storage should generate an alert on its own. Establish baselines for storage bucket read volume and enforce rate and volume caps on service accounts that have no business reason to bulk-export.
- Audit what your vendors hold on your behalf, and what you hold on candidates. Push data-minimization and retention limits into contracts with labeling, recruiting and BPO vendors, and ask specifically about biometric and identity-verification retention. If you collect video interviews or ID scans, define a deletion clock and enforce it.
- Shorten your own notification path. The gap between the intrusion window closing on 30 March and notification on 25 to 26 June is roughly 87 days. Whatever the forensic justification, it left tens of thousands of people unaware that their passport, voice and banking details were in circulation. Pre-build the notification workflow before you need it.
Sources: Hackers claim massive 4TB haul from AI firm serving OpenAI, Google,... | Meta freezes AI data work after breach puts training secrets at risk | Mercor AI Allegedly Hit by Lapsus$ Data Breach Exposing Massive Sou... | Mercor Allegedly Hit by Massive 4TB Data Breach: AI Startup’s Datab... | The AI Job Interview Is the Product: What the Mercor Breach Proved... | LAPSUS$ Claims to End All Operations After Allegedly Selling Mercor... | Mercor says it was hit by cyberattack tied to compromise of open so... | After data breach, $10B-valued startup Mercor is having a month