Der Mercor-Hack macht sichtbar, wie riskant die Open-Source-Fundamente der KI-Branche sind

Überschrift und Einstieg

Der Vorfall bei Mercor ist mehr als ein »weiterer Hack«. Er zeigt schonungslos, wie verwundbar die eigentliche Infrastruktur der KI-Revolution ist: unscheinbare Open‑Source‑Bibliotheken, die Millionen Male pro Tag installiert werden und doch kaum jemand wirklich prüft. Über die Kompromittierung von LiteLLM traf es nun ausgerechnet Mercor – einen 10‑Milliarden‑US‑Dollar‑Einhorn, das für OpenAI, Anthropic und andere hochspezialisierte Experten rekrutiert. In diesem Artikel analysieren wir, was passiert ist, warum LiteLLM ein gefährlicher Single Point of Failure ist, welche Lehren sich für europäische Unternehmen und Regulierer ergeben und was als Nächstes zu erwarten ist.

Die Nachricht in Kürze

Laut einem Bericht von TechCrunch hat die KI‑Recruiting‑Plattform Mercor einen Sicherheitsvorfall bestätigt, der mit einem Supply‑Chain‑Angriff auf das Open‑Source‑Projekt LiteLLM zusammenhängt.

TechCrunch berichtet unter Berufung auf das Unternehmen und Sicherheitsforscher:

• Mercor sei »eines von Tausenden Unternehmen«, die von der Kompromittierung von LiteLLM betroffen seien; der Angriff werde einer Gruppe namens TeamPCP zugeschrieben.
• Die bekannte Erpressungsgruppe Lapsus$ habe separat behauptet, Daten von Mercor erlangt zu haben, und auf ihrer Leak‑Seite Beispiele veröffentlicht – darunter offenbar interne Slack‑bezogene und Ticket‑Daten sowie Videos von Interaktionen zwischen Mercors KI‑Systemen und Auftragnehmern.
• Mercor habe nach eigenen Angaben den Vorfall schnell eingedämmt, Forensik‑Spezialisten hinzugezogen und arbeite an der Aufklärung, verweigere aber konkrete Aussagen dazu, ob Kunden‑ oder Auftragnehmerdaten eingesehen oder exfiltriert wurden.
• Bei LiteLLM sei der bösartige Code innerhalb weniger Stunden entdeckt und entfernt worden; laut dem Sicherheitsunternehmen Snyk, auf das sich TechCrunch beruft, wird die Bibliothek jedoch täglich millionenfach heruntergeladen.

Wie viele Organisationen tatsächlich betroffen sind und ob es zu breiteren Datenabflüssen kam, ist noch unklar.

Warum das wichtig ist

Mercor nimmt im KI‑Ökosystem eine besondere Rolle ein. Die Plattform vermittelt spezialisierte Experten – etwa Ärzte, Juristen und Wissenschaftler – an KI‑Labs und Unternehmen, die ihre Modelle trainieren und evaluieren wollen. Nach eigenen Angaben fließen täglich über 2 Millionen US‑Dollar an diese Auftragnehmer. Damit stehen im Raum:

• personenbezogene und finanzielle Daten hochqualifizierter Fachkräfte,
• vertrauliche Trainings‑ und Testaufgaben von Kunden wie OpenAI oder Anthropic,
• Dialoge zwischen Menschen und KI‑Systemen, die oft reale, sensible Szenarien abbilden.

Ein erfolgreicher Angriff auf diese Schnittstelle ist sicherheitstechnisch heikel: Er berührt sowohl die Schutzinteressen der Auftragnehmer als auch die Geschäftsgeheimnisse der KI‑Labs und ihrer Unternehmenskunden.

Strategisch zeigt der Fall vor allem eines: Die Branche hat Milliarden in Modelle und GPUs investiert, aber die darunterliegende Software‑Supply‑Chain bleibt erstaunlich fragil. Ein 10‑Milliarden‑Einhorn wird mutmaßlich nicht über einen Cloud‑Exploit, sondern über eine vergiftete Open‑Source‑Bibliothek getroffen.

Daraus ergeben sich mehrere Konsequenzen:

1. Open Source ist kritische Infrastruktur. Bibliotheken wie LiteLLM sind längst systemrelevant – trotzdem werden ihre Maintainer oft schlecht bezahlt, überlastet und stehen bei Angriffen allein da.
2. Zertifikate ersetzen keine Code‑Transparenz. Dass LiteLLM nach dem Vorfall den Compliance‑Anbieter wechselt, ist eher Symbolpolitik. Sicherheitsniveau entsteht nicht durch Audits allein, sondern durch überprüfbaren Entwicklungs‑ und Build‑Prozess.
3. Angreifer folgen der Hebelwirkung. Gruppen wie Lapsus$ und TeamPCP haben erkannt, dass sie durch einen einzigen Open‑Source‑Treffer potentiell Zugriff auf Hunderte oder Tausende Unternehmen erhalten – gerade im heißen KI‑Umfeld.

Der größere Kontext

Der Mercor/LiteLLM‑Fall fügt sich nahtlos in eine Serie prominenter Supply‑Chain‑Vorfälle ein.

Historische Beispiele:

• SolarWinds (2020): Kompromittierte Updates ermöglichten Angriffe auf US‑Behörden und Großkonzerne.
• Log4Shell (2021): Eine Schwachstelle in einer allgegenwärtigen Logging‑Bibliothek zwang Unternehmen weltweit zu Notfall‑Patches.
• XZ‑Utils‑Backdoor (2024): Eine hinterhältige Hintertür in einem Kompressions‑Tool wurde glücklicherweise entdeckt, bevor sie in große Linux‑Distributionen ausgerollt wurde.

Gemeinsam ist all diesen Fällen: Ein vergleichsweise kleines Projekt erhält durch seine Verbreitung eine enorme sicherheitsrelevante Hebelwirkung. LiteLLM nimmt nun eine ähnliche Rolle im KI‑Stack ein – als Bequemlichkeits‑Layer für den Zugriff auf verschiedene Sprachmodelle.

Besonders brisant im KI‑Kontext:

• Datenqualität und ‑sensibilität: KI‑Workflows enthalten nicht nur »normale« personenbezogene Daten, sondern oft auch sehr sensible Informationen und Geschäftslogik.
• Automatisierte Abläufe: Ein schadhafter Baustein kann in automatisierten Pipelines still und leise Zugangsdaten, Prompts oder Ergebnisse absaugen.
• Schnelle Experimentierkultur: »Move fast« bleibt in vielen KI‑Teams oberste Maxime; Security‑Reviews halten da selten Schritt.

Die Reaktion der Branche zeichnet sich bereits ab:

• Cloud‑Provider und Großunternehmen etablieren private Paket‑Registries und Whitelists für geprüfte Bibliotheken.
• SBOMs (Software Bill of Materials) werden zunehmend zur Pflicht, um Abhängigkeiten sichtbar zu machen.
• Es gibt eine Tendenz, Community‑Wrapper durch eigene, besser kontrollierte SDKs zu ersetzen.

Der Fall Mercor/LiteLLM wird diese Entwicklung beschleunigen. In Security‑Abteilungen werden Fragen lauter: Welche Open‑Source‑Bausteine in unseren KI‑Workflows haben ein ähnliches Risikoprofil? und Wo hängen wir an Projekten, die faktisch von einer Handvoll Maintainer abhängen?

Die europäische/regionalen Perspektive (DACH)

Für Unternehmen in Deutschland, Österreich und der Schweiz ist der Vorfall ein Musterbeispiel dafür, was die EU‑Gesetzgebung seit Jahren adressiert: Verantwortung für die gesamte digitale Lieferkette.

Relevante Rahmenwerke:

• DSGVO (GDPR): Sollten personenbezogene Daten von EU‑Bürgern betroffen sein, greifen strenge Meldepflichten und potentiell hohe Bußgelder – nicht nur für Mercor, sondern auch für seine Unternehmenskunden als Verantwortliche.
• NIS2‑Richtlinie: Viele kritische und wichtige Einrichtungen in der EU müssen Supply‑Chain‑Risiken aktiv managen und nachweisen, wie sie Drittanbieter und deren Abhängigkeiten bewerten.
• EU‑Cyber‑Resilience‑Act (CRA): Bringt zusätzliche Anforderungen an Hersteller von »Produkten mit digitalen Elementen« – dazu zählen auch Software‑Anbieter, die massiv auf Open Source stützen.
• EU‑AI‑Act: Verlangt bei Hochrisiko‑KI‑Systemen ein systematisches Risikomanagement, inklusive Integrität von Trainings‑ und Evaluationspipelines.

Für den DACH‑Raum bedeutet das: Wer KI‑Funktionen nutzt – vom Medizin‑Startup in Berlin bis zur Bank in Zürich – muss künftig deutlich genauer hinsehen, welche Open‑Source‑Bausteine in den verwendeten Tools stecken und wie deren Maintainer abgesichert sind.

Zugleich berührt der Vorfall das Thema Datensouveränität. Viele deutsche Unternehmen sind ohnehin skeptisch gegenüber US‑Anbietern und den Cloud‑Hyperscalern. Ein prominenter Supply‑Chain‑Vorfall im KI‑Umfeld liefert zusätzliche Argumente für:

• europäische KI‑Toolchains,
• Security‑Audits von Open‑Source‑Komponenten,
• stärkere Förderung von Projekten, die kritische Bibliotheken professionell betreuen.

Ausblick

Wir stehen vermutlich am Anfang der Aufarbeitung. Entscheidend wird sein, wie transparent Mercor, LiteLLM und andere Betroffene kommunizieren – und wie tief Regulierer nachfragen.

Wichtige Punkte für die nächsten Monate:

1. Forensische Details: Wird klar werden, ob Entwicklerkonten, Build‑Systeme oder Paket‑Repos kompromittiert wurden? Daraus leiten sich Schutzmaßnahmen für andere Projekte ab.
2. Betroffenenkreis: Sollten weitere prominente Opfer publik werden, wird LiteLLM in einem Atemzug mit SolarWinds und Log4j genannt werden – als Paradebeispiel für Open‑Source‑Supply‑Chain‑Risiken.
3. Reaktionen der Aufsichtsbehörden: In der EU könnten Datenschutzbehörden und Cybersicherheits‑Agenturen den Fall nutzen, um NIS2‑ und CRA‑Anforderungen mit Leben zu füllen und Leitlinien speziell für KI‑Workflows zu veröffentlichen.

Unternehmen in der DACH‑Region – egal ob Startup aus München oder Konzern in Wien – sollten jetzt handeln:

• Abhängigkeitsmanagement professionalisieren: eigene Mirror‑Repos, strenge Versionskontrolle, automatisierte Vulnerability‑Scans.
• SBOMs einführen: sowohl für selbst entwickelte Software als auch als Anforderung an Zulieferer.
• Security‑Governance für KI etablieren: AI‑Projekte nicht als Spielwiese behandeln, sondern in bestehende ISMS‑Strukturen (ISO 27001 etc.) integrieren.

Die gute Nachricht: Jeder öffentlich gewordene Vorfall schafft politischen und wirtschaftlichen Druck, die lange vernachlässigte Open‑Source‑Infrastruktur besser zu finanzieren und zu sichern. Die spannende Frage ist, ob Unternehmen und Politik diesen Moment nutzen – oder ob erst ein noch größerer KI‑bezogener Supply‑Chain‑Schaden nötig ist, um wirklich umzudenken.

Fazit

Der Mercor–LiteLLM‑Vorfall macht unmissverständlich klar: Die KI‑Branche baut auf einem Fundament aus Open‑Source‑Bausteinen, deren Sicherheit bislang eher Glückssache als Ergebnis systematischer Steuerung ist. Wer KI‑Dienste einkauft oder anbietet, sollte jetzt konsequent nach der Lieferkette fragen: Welche Bibliotheken nutzen Sie, wer betreut sie, und wie werden diese geschützt? Solange diese Fragen nicht überzeugend beantwortet sind, bleibt jede noch so beeindruckende KI‑Demo ein Haus auf wackligen Stelzen.