Ein vergiftetes PyPI-Paket drang in das KI-Training-Startup Mercor ein – und legte 4 TB an Auftragnehmerdaten gegenüber Lapsus$ offen

Am 31. März 2026 bestätigte Mercor – ein 10-Milliarden-Dollar-Startup, das KI-Datenkennzeichnungs-, Annotations- und Auftragnehmermanagementdienste für OpenAI, Anthropic, Meta und Google anbietet – einen Sicherheitsvorfall, den Sicherheitsforscher als einen der folgenreichsten Lieferkettenangriffe gegen die KI-Branche bisher bezeichnen. Etwa 4 TB Daten wurden exfiltriert: 939 GB Plattformquellcode, 211 GB Benutzerdatenbankeinträge und rund 3 TB Storage-Bucket-Inhalte, darunter Passkopien von Auftragnehmern, Sozialversicherungsnummern, Identitätsnachweise und Videoaufzeichnungen von technischen Interviews. Die Gruppe, die die Verantwortung übernimmt, ist Lapsus$, die die gestohlenen Daten auf ihrem Dark-Web-Marktplatz zur Versteigerung angeboten hat. Bereits fünf Sammelklagen wurden von betroffenen Auftragnehmern gegen Mercor eingereicht.

Die Angriffskette: Drei Schritte vom Scanner zur Produktion

Was diesen Vorfall technisch besonders macht, ist der Angriffspfad. Es handelte sich nicht um einen direkten Einbruch in Mercors Systeme. Es war ein dreistufiger Lieferkettenangriff, der sich durch das Open-Source-Tooling-Ökosystem bewegte, bevor er eine Produktionsumgebung erreichte.

Schritt 1 – 19. März: Trivy wird kompromittiert. Trivy ist ein weit verbreiteter Open-Source-Schwachstellenscanner, der von Aqua Security gewartet und in CI/CD-Pipelines tausender Organisationen integriert wird. Die Angreifergruppe, die unter dem Namen TeamPCP operierte, erlangte Schreibzugriff auf Trivys Release-Artefakte. Der genaue Anfangseintrittspunkt in Trivy wurde nicht öffentlich bekannt gegeben, aber das Ergebnis war, dass TeamPCP die Möglichkeit hatte, zu beeinflussen, was Trivy während seiner Scanläufe ausführte.

Schritt 2: CI/CD-Anmeldedaten-Extraktion aus LiteLLM. LiteLLM – eine beliebte Open-Source-Python-Bibliothek, die ein einheitliches API-Gateway für den Aufruf verschiedener Large-Language-Model-Anbieter bietet – verwendete Trivy als Teil seiner automatisierten CI/CD-Pipeline, um Container und Abhängigkeiten auf bekannte Schwachstellen zu scannen. Entscheidend dabei: LiteLLMs CI/CD-Konfiguration pinnte Trivy nicht an einen bestimmten Versions-Hash. Es zog Trivy ohne Versionssperrung, was bedeutete, dass das kompromittierte Trivy, als es in LiteLLMs Build-Umgebung lief, Zugriff auf die Secrets der Pipeline hatte: PyPI-Publishing-Anmeldedaten, Repository-Tokens und Umgebungsvariablen. TeamPCP extrahierte diese Anmeldedaten während eines routinemäßigen Build-Durchlaufs durch den kompromittierten Scanner.

Schritt 3 – 27. März: Schädliche LiteLLM-Versionen auf PyPI. Bewaffnet mit LiteLLMs PyPI-Publishing-Anmeldedaten veröffentlichte TeamPCP zwei schädliche Versionen: litellm==1.82.7 und litellm==1.82.8. Die Pakete waren in ihrem äußeren Verhalten funktional identisch zu den legitimen Versionen – sie bestanden grundlegende Importtests und konnten LLM-API-Aufrufe normal routen. Die eingeschleuste Payload wurde beim Import oder bei der ersten Verwendung ausgeführt, stellte eine ausgehende Verbindung her und exfiltrierte Umgebungsvariablen, API-Schlüssel und Dateisystempfade, die für den laufenden Prozess zugänglich waren. Jede Organisation, die diese Versionen in eine Produktionsumgebung zog – über pip install litellm ohne Version-Pinning oder über Automatisierung von Abhängigkeitsaktualisierungen – führte angreifergesteuerten Code aus.

Mercor war eine dieser Organisationen. Da LiteLLM im gesamten KI-Entwicklungsökosystem als Infrastruktur für den Bau von Anwendungen verwendet wird, die GPT-4, Claude, Gemini und andere Modelle aufrufen, war das Zeitfenster der Offenlegung breit. Mercors Plattform, die Auftragnehmer-Workflows verwaltet, Identitätsdokumente von Auftragnehmern speichert und proprietäre Trainingsdaten für große KI-Labore verarbeitet, war in diesem Zeitfenster ein Ziel mit hohem Wert.

Was gestohlen wurde

Die aus Mercor exfiltrierten Daten unterteilen sich in drei Kategorien mit jeweils unterschiedlichen Risikoprofilen:

• 939 GB Plattformquellcode. Dies umfasst Mercors Auftragnehmermanagementsystem, Bewertungswerkzeuge und die Schnittstellen, über die Auftragnehmer mit KI-Trainingsaufgaben interagieren. Für Mercors Kunden – OpenAI, Anthropic, Meta, Google – offenbart die Offenlegung dieses Codes potenziell, wie ihre Trainingspipelines auf der Auftragnehmerschnittstellenebene strukturiert sind, welche Arten von Aufgaben über Mercor geleitet werden und welche Qualitätskontrollmechanismen vorhanden sind.
• 211 GB Benutzerdatenbankeinträge. Dies umfasst Auftragnehmerprofile, Kontometadaten, Zahlungsaufzeichnungen und interne Korrespondenz. Das genaue Schema wurde nicht bestätigt, aber angesichts der Compliance-Anforderungen von Mercor für die Auftragnehmeranbindung enthält die Datenbank mit ziemlicher Sicherheit personenbezogene Daten von Zehntausenden von Auftragnehmern.
• ~3 TB Storage-Bucket-Inhalte. Dies ist für einzelne Auftragnehmer die sensibelste Kategorie. Die Storage-Buckets enthielten Videoaufzeichnungen technischer Interviews zur Identitätsprüfung und Kompetenzbewertung, Scans amtlicher Ausweise, darunter Pässe und Personalausweise, bei der US-Auftragnehmeranbindung erhobene Sozialversicherungsnummern sowie Identitätsnachweise, die zur Erfüllung von KYC-Anforderungen eingereicht wurden. Die Kombination aus biometrischem Video, amtlichem Ausweis und SSN stellt ein vollständiges Identitätspaket für die betroffenen Auftragnehmer dar – ausreichend für Identitätsdiebstahl, synthetischen Identitätsbetrug und gezieltes Social Engineering.

Warum KI-Trainings-Lieferketten ein besonders sensibles Ziel sind

Ein Sicherheitsvorfall bei einer standardmäßigen SaaS-Auftragnehmermanagementplattform wäre vor allem aufgrund der Offenlegung persönlicher Daten schwerwiegend. Mercors Vorfall ist grundlegend anders, weil die über Mercor arbeitenden Auftragnehmer tatsächlich mit sensiblen Inhalten umgehen.

KI-Auftragnehmer auf dem Niveau von Mercors Kundenbasis erledigen keine generische Dateneingabe. Sie führen Aufgaben aus, die die proprietärsten und wettbewerbsempfindlichsten Aspekte der KI-Entwicklung berühren: Sie bewerten Modellausgaben anhand von Fähigkeitsbenchmarks, die nicht öffentlich veröffentlicht wurden, annotieren Grenzfälle, die zeigen, wo ein Modell derzeit versagt, bewerten Antworten nach Kriterien, die die RLHF-Trainingsmethodik eines Unternehmens kodieren, und testen Sicherheitsfilter auf eine Weise, die offenlegt, was das Modell kann und was nicht. Die Anweisungen, Bewertungsrichtlinien und Aufgabenbeschreibungen, die die Auftragnehmer erhalten, sind der intellektuelle Kern der Art und Weise, wie diese Labore ihre Modelle trainieren und ausrichten.

Mercors Quellcode – der die Schnittstellen und Werkzeuge umfasst, über die diese Aufgaben bereitgestellt werden – könnte diese Methodologien selbst dann offenlegen, wenn die einzelnen Aufgabendaten nicht im exfiltrierten Satz enthalten waren. Für einen Konkurrenten, der ein eigenes Modell baut, oder für einen staatlichen Akteur, der versucht, die Sicherheitsgrenzen und Trainingstechniken von Grenz-KI-Systemen zu verstehen, stellt dies einen Zugang zu Informationen dar, die aus öffentlicher Forschung nicht rekonstruiert werden können.

Reaktionen der Betroffenen

Die Reaktionen von Mercors Kunden waren zurückhaltend, aber signifikant. Meta pausierte am 2. April, zwei Tage nachdem der Vorfall bestätigt wurde, alle über Mercor geleiteten Datenarbeiten auf unbestimmte Zeit, unter Berufung auf Unsicherheit über die Integrität der Auftragnehmerumgebung und die mögliche Offenlegung von Aufgabenbeschreibungen. OpenAI und Anthropic gaben beide Erklärungen ab, in denen sie bestätigten, dass sie ihr Risiko prüfen – insbesondere, ob zu dem Zeitpunkt des Vorfalls proprietäre Trainingsdaten, Annotationsrichtlinien oder Bewertungsrahmen für Auftragnehmer über Mercors nun kompromittierte Plattform zugänglich waren.

Weder OpenAI noch Anthropic haben bestätigt, ob proprietäre Trainingsmaterialien in den exfiltrierten Daten enthalten waren. Der 939-GB-Quellcode-Dump ist der wahrscheinlichste Vektor für eine indirekte Offenlegung: Wenn Mercors Plattformquellcode eingebettete Aufgaben-Templates, Bewertungskriterien oder Modellausgabebeispiele enthielt, die zur Schulung der Auftragnehmerqualität verwendet wurden, wären diese jetzt im Besitz von Lapsus$.

Lapsus$ hat den gesamten 4-TB-Datensatz auf seinem Dark-Web-Marktplatz zur Versteigerung angeboten, mit einem nach Angaben von Quellen siebenstelligen Preis. Die Gruppe hat eine dokumentierte Geschichte der Durchführung von Datenverkäufen – insbesondere bei Daten, die 2022 von Nvidia, Samsung und Microsoft gestohlen wurden –, was der Auktionsliste Glaubwürdigkeit über eine typische Erpressungsdrohung hinaus verleiht.

Fünf Sammelklagen sind von betroffenen Auftragnehmern vor US-Bundesgerichten eingereicht worden, mit Vorwürfen fahrlässiger Datensicherheitspraktiken, mangelnder Umsetzung angemessener Lieferkettenkontrollen und unzureichender Benachrichtigung nach dem Vorfall. Die Klagen nennen konkret Mercor; keine hat bisher die KI-Unternehmen genannt, deren Auftragnehmerprogramme auf der Plattform gehostet wurden.

Was Entwickler tun sollten

Wenn Ihre Codebasis LiteLLM verwendet, sind die unmittelbaren Schritte konkret:

• Überprüfen Sie Ihre installierte Version. Führen Sie pip show litellm aus oder prüfen Sie Ihre requirements.txt, pyproject.toml oder Lockfile. Wenn Sie litellm==1.82.7 oder litellm==1.82.8 in Ihrem Abhängigkeitsgraphen haben – einschließlich transitiver Abhängigkeiten – behandeln Sie die Umgebung als kompromittiert. Rotieren Sie alle Secrets, die für diesen Prozess zugänglich waren: API-Schlüssel, Datenbankanmeldedaten, Cloud-Provider-Tokens und alle Umgebungsvariablen.
• Überprüfen Sie Ihre PyPI-Abhängigkeits-Pinning-Strategie. Jede Abhängigkeit, die mit einer Versionsspanne (litellm>=1.82) oder ohne Versionseinschränkung (litellm) gezogen wurde, war anfällig für diese Art von Angriff. Pinnen Sie auf exakte Versionen und verwenden Sie eine Lockfile (Poetries poetry.lock oder per pip-compile generierte requirements.txt), die Hashes enthält. Das Hash-Pinning-Flag --require-hashes in pip macht es unmöglich, ein Paket zu installieren, dessen Inhalt nicht mit dem aufgezeichneten Hash übereinstimmt, selbst wenn ein Angreifer eine Version auf PyPI ersetzt.
• Überprüfen Sie das Version-Pinning Ihrer CI/CD-Tools. Der LiteLLM-Vorfall entstand, weil Trivy in LiteLLMs Build-Pipeline nicht an eine bestimmte Version gepinnt war. Jedes Tool in Ihrer CI/CD-Pipeline – Scanner, Linter, Build-Tools, Test-Runner – sollte auf eine bestimmte Version und idealerweise auf einen Content-Hash gepinnt sein. GitHub Actions erlaubt das Pinnen von Aktionen auf einen vollständigen Commit-SHA anstelle eines Tags, was Tag-mutable-Angriffe verhindert. Für containerbasierte Tools wie Trivy pinnen Sie auf den Image-Digest (aquasec/trivy@sha256:...), nicht auf das Tag (aquasec/trivy:latest).
• Prüfen Sie, welche Secrets in Ihrer Build-Umgebung zugänglich sind. PyPI-Publishing-Anmeldedaten sollten niemals als Umgebungsvariablen im selben Pipeline-Schritt verfügbar sein, der Abhängigkeitsscans oder Tests durchführt. Verwenden Sie separate Pipeline-Jobs mit unterschiedlichen Berechtigungsbereichen und wenden Sie das Prinzip der geringsten Berechtigung darauf an, welche Secrets jeder Schritt zugreifen kann.

Das Muster: Lieferkettenangriffe auf Entwicklerwerkzeuge

Der LiteLLM-Angriff ist der jüngste in einer Reihe von Lieferkettenangriffen, die zunehmend tiefere Schichten des Entwickler-Tooling-Stacks angreifen:

• SolarWinds (Dezember 2020): Staatliche Akteure (APT29/Cozy Bear) kompromittierten das Build-System von SolarWinds, injizierten eine Hintertür in die an etwa 18.000 Organisationen, darunter US-Bundesbehörden, verteilte Orion-Plattform. Der Angriffsvektor war die Build-Pipeline selbst.
• Codecov (April 2021): Angreifer modifizierten das auf der eigenen Infrastruktur gehostete Bash-Uploader-Skript von Codecov. Jede CI/CD-Pipeline, die das Skript ausführte – ein häufiges Muster für Codeabdeckungsberichte – lud Umgebungsvariablen, einschließlich Secrets, auf angreifergesteuerte Server hoch.
• xz Utils (März 2024): Eine ausgeklügelte, mehrjährige Social-Engineering-Kampagne führte dazu, dass eine Hintertür in die xz-Komprimierungsbibliothek eingefügt wurde, die auf die SSH-Serverauthentifizierung unter Linux abzielte. Der Angreifer verbrachte zwei Jahre damit, Vertrauen als legitimer Mitwirkender aufzubauen, bevor er den schädlichen Code einfügte.
• LiteLLM via Trivy (März 2026): Ein ohne Version-Pinning eingesetzter Schwachstellenscanner wurde zum Einstiegspunkt für den Diebstahl von Anmeldedaten, was dann die Veröffentlichung eines schädlichen Pakets unter dem Namen einer vertrauenswürdigen Bibliothek auf PyPI ermöglichte.

Der rote Faden ist durchgängig: Angreifer durchbrechen keine gehärteten Anwendungssicherungen. Sie nutzen die Vertrauensbeziehungen zwischen Tools aus, auf die Entwickler angewiesen sind, um Software zu bauen, zu testen und bereitzustellen. Je vernetzter die KI-Entwicklungswerkzeuge werden – mit Bibliotheken wie LiteLLM als kritischer Infrastruktur für das Routen von Aufrufen an Grenzmodelle – desto proportional größer wird der Schadensradius einer einzigen kompromittierten Abhängigkeit. Der Mercor-Vorfall ist kein Ausreißer. Er ist eine Veranschaulichung dessen, wie die nächsten Jahre von Lieferkettenangriffen gegen die KI-Branche aussehen werden.