LiteLLM Supply Chain Angriff: OAuth-Tokens und Malware auf PyPI
ki-pentesting

LiteLLM Supply Chain Angriff: OAuth-Tokens und Malware auf PyPI

Angreifer kompromittierten LiteLLM-Repository mit GitHub-Token-Leak. Malware erbeute Cloud-Credentials, API-Keys und Entwickler-Geheimnisse. DACH-Unternehmen sollten PyPI-Dependencies dringend prüfen.

ki-pentesting3 unabhängige QuellenFlowKI Newsroom

Der Python-Paketmanager PyPI und die Docker-Registry wurden am 22. Oktober 2026 Ziel eines Lieferketten-Angriffs auf LiteLLM, eine weit verbreitete Abstraktion für KI-Sprachmodelle. Laut SecurityWeek nutzten die Angreifer kompromittierte GitHub CLI OAuth-Token, um eine manipulierte Version des Pakets hochzuladen und zu genehmigen. Die Malware wurde konzipiert, um Cloud-Anmeldedaten, API-Schlüssel für KI-Services sowie weitere Entwickler-Geheimnisse von Systemen zu erbeuten, auf denen die infizierte Version installiert wurde.

LiteLLM selbst gab am Mittwoch bekannt, dass Bedrohungsakteure "mehrfache unabhängige Sicherheitskontrollen" durchbrachen, um die bösartige Paketversion zu veröffentlichen. Wie Help Net Security berichtet, handelt es sich bereits um den zweiten Supply-Chain-Angriff auf LiteLLM im laufenden Jahr 2026. Das Unternehmen vermutete einen Leak von GitHub-Token, möglicherweise über seine eigenen Logs im Gateway-System. Die Angreifer konnten nicht nur das Paket auf PyPI hochladen, sondern auch parallele Releases auf Docker-Registries durchsetzen – ein mehrschichtiger Angriff, der auf Systeme mit hoher Automatisierung abzielt.

Die exfiltrierten Anmeldedaten umfassten AWS-, Azure-, Google Cloud-Credentials sowie OpenAI-API-Keys, Anthropic-Tokens und andere sensible Entwickler-Assets. Dadurch erlangt der Angreifer Zugriff nicht nur auf KI-Service-Konten, sondern potentiell auf die gesamte Cloud-Infrastruktur betroffener Organisationen. SecurityWeek dokumentierte, dass Pakete aus PyPI und Docker ohne weitere Verifikation über Millionen von Systemen weltweit installiert und aktualisiert werden.

Warum diese Attacke für DACH-Unternehmen kritisch ist

Im deutschsprachigen Raum müssen Entwicklerteams und KI-Plattform-Betreiber, die LiteLLM als Komponente einsetzen, sofort reagieren. LiteLLM wird häufig in Enterprise-Umgebungen als Gateway-Layer zwischen Anwendungen und verschiedenen LLM-Providern (OpenAI, Anthropic, Open-Source-Modelle) eingesetzt. DSGVO-relevante Systeme, die LiteLLM nutzen, könnten somit personenbezogene Daten über kompromittierte Cloud-Zugänge gefährdet haben.

Besonders im deutschen Mittelstand und bei Unternehmen mit Pendants in Österreich und der Schweiz ist automatisierte Dependency-Installation ein Standard-Praxis. Pip-basierte CI/CD-Pipelines laden das aktuellste verfügbare Paket herunter – ohne zusätzliche Verifikation. Dadurch kann Malware automatisch in Produktionsumgebungen gelangen. Zusätzlich verpflichtet der EU-AI-Act Organisationen, die generative KI einsetzen, zur Dokumentation ihrer KI-Supply-Chain. Ein Paket-Malware-Vorfall bei zentralen KI-Gateway-Lösungen wie LiteLLM wird daher zu einem Compliance-Incident und erfordert sofortige Notification an Behörden und betroffene Parteien.

Das BfDI (Bundesbeauftragte für Datenschutz und Informationsfreiheit) sowie die österreichische Datenschutzbehörde (DSB) und SwissID werden Anfragen zu diesem Incident erwarten. Besonders kritisch ist die zweite Attacke in 2026 auf denselben Akteur – ein Zeichen für persistente Schwachstellen im eigenen Access-Management bei LiteLLM. Unternehmen sollten überprüfen, ob sie LiteLLM-Versionen zwischen dem 22. Oktober und der Patch-Veröffentlichung installiert haben.

Auch das IT-Sicherheitsgesetz 2.0 in Deutschland – das verstärkte Anforderungen an Supply-Chain-Sicherheit stellt – wird Nachfragen an kritische Infrastruktur-Betreiber und größere Unternehmen richten. Wer KI-Gateways ohne Pin-Versionen oder Dependency-Scanning betreibt, verstößt damit gegen aktuell gültige Cybersecurity-Standards.

Was du jetzt tun solltest: Audit und Token-Rotation

Der konkrete Handlungsschritt: Sofortige Überprüfung aller Produktions- und Staging-Systeme auf installierte LiteLLM-Versionen vom 22. Oktober 2026 sowie die letzten sieben Tage davor. Nutze pip show litellm oder Docker-Image-Tags zur Identifikation. Parallel dazu müssen alle Cloud-API-Keys, GitHub-Tokens, OpenAI-API-Keys und ähnliche Credentials, die auf Systemen mit potentiell kompromittierten LiteLLM-Instanzen hinterlegt sind, sofort rotiert werden – unabhängig davon, ob eine aktuelle Infektion nachgewiesen wurde.

Dies ist nicht optional: Ein einzelner geleaktes OpenAI-API-Key für einen KI-Gateway kann in Minuten zu Tausenden Euro in API-Kosten führen. Noch kritischer: Ein AWS-Credential-Leak ermöglicht Angreifern laterale Bewegungen in der gesamten Cloud-Infrastruktur, einschließlich Zugriff auf Trainings-Datenbanken und Unternehmensgeheimnisse.

Längerfristig sollten Organisationen auf Dependency-Pinning und Hash-Verifizierung in ihren Pip-Repositories umstellen und ein internes Pentesting-Lab aufbauen, das Supply-Chain-Angriffe simuliert. Automatisierte Package-Scanning-Tools wie Snyk oder Dependabot bieten Basis-Protection, aber manuelle Code-Reviews von kritischen KI-Komponenten sind für Unternehmen mit hohem Datenschutz-Anforderungen unverzichtbar – siehe auch unsere Pillar-Seite zum KI-Pentesting sowie unseren Artikel zu KI-Agenten außer Kontrolle: Governance-Chaos in Unternehmensnetzen.

Quellen

FAQ

Häufige Fragen

Was ist bei LiteLLM am 22. Oktober 2026 passiert?

Angreifer nutzten kompromittierte GitHub CLI OAuth-Token, um eine malware-infizierte Version von LiteLLM auf PyPI und Docker hochzuladen. Die Malware war konzipiert, um Cloud-Anmeldedaten, API-Schlüssel und Entwickler-Geheimnisse zu erbeuten.

Welche Daten konnte die Malware ausspähen?

Die Malware sammelte AWS-, Azure-, Google Cloud-Credentials sowie API-Keys von OpenAI, Anthropic und anderen KI-Service-Providern. Dadurch erhielten Angreifer Zugriff auf Cloud-Infrastrukturen und KI-Service-Konten betroffener Organisationen.

Wie sollten DACH-Unternehmen reagieren?

Unternehmen sollten sofort überprüfen, ob LiteLLM auf ihren Systemen installiert ist, und alle Cloud-API-Keys, GitHub-Tokens und ähnliche Credentials rotieren. Ein Dependency-Audit zur Identifikation der installieren LiteLLM-Versionen ist dringend erforderlich.