Veröffentlicht am 13.08.2026
Ein einziger, nicht widerrufener Zugangs-Token – und plötzlich stehen mehr als 2.500 Organisationen und über 434.000 automatisierte Bauprozesse potenziell offen. Genau das ist beim LiteLLM-Vorfall passiert, der am 24. März 2026 begann und bis heute Wellen schlägt. Angreifer haben zwei manipulierte Versionen einer weit verbreiteten Python-Bibliothek in den offiziellen Software-Katalog PyPI eingeschleust. Wer diese Versionen installierte oder auch nur automatisch bezog, riskierte, dass API-Schlüssel, Cloud-Zugänge, SSH-Keys und Datenbankpasswörter heimlich ausgelesen und an eine fremde Adresse übertragen wurden.
In diesem Artikel erklären wir verständlich, was genau geschehen ist, wer betroffen sein kann – und was besonders kleine und mittlere Unternehmen (KMU) mit eigener Website, Shop oder KI-Chatbot jetzt konkret prüfen und tun sollten.
Betroffen ist LiteLLM, eine Python-Bibliothek und ein Proxy-Server, die als Vermittler zwischen Anwendungen und verschiedenen KI-Modellen (etwa von OpenAI, Anthropic oder Google) dienen. Sie ist in der Entwickler- und KI-Welt sehr verbreitet.
Es handelt sich nicht um einen klassischen Programmierfehler mit einer CVE-Nummer (die standardisierte Kennung für eine öffentlich bekannte Sicherheitslücke), sondern um einen sogenannten Supply-Chain-Angriff – ein Angriff auf den Lieferweg der Software. Konkret wurden zwei bösartig veränderte Ausgaben des Pakets veröffentlicht:
Beide Versionen wurden am 24. März 2026 auf PyPI, dem zentralen Verzeichnis für Python-Pakete, hochgeladen. LiteLLM-Gründer Krrish Dholakia (CEO) und Ishaan Jaffer (CTO) bestätigten:
„The compromised PyPI packages were litellm==1.82.7 and litellm==1.82.8.“ (LiteLLM Security Update)
Die Schadsoftware in diesen Paketen war darauf ausgelegt, Zugangsdaten zu sammeln: aus Umgebungsvariablen, Dateien, sowie Cloud-, SSH-, Datenbank-, Kubernetes-, Git- und Container-Zugängen. Diese Daten wurden verschlüsselt an die Domain models.litellm[.]cloud übertragen – eine Adresse, die laut LiteLLM nicht zum offiziellen Projekt gehört.
Wie kam der Schadcode überhaupt in die offiziellen Pakete? Nach Angaben von LiteLLM und PyPI wurde ein Token bzw. eine Abhängigkeit im Zusammenhang mit dem Werkzeug Trivy (einem Sicherheits-Scanner) in der Bau- und Veröffentlichungsumgebung missbraucht. Die Sicherheitsforscher von CloudSEK beschreiben die Kette bildhaft:
„Trivy, then the LiteLLM build system, then the LiteLLM release: one unrevoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure.“ (CloudSEK)
Übersetzt: Ein einziger, nicht rechtzeitig widerrufener Token reichte, um sich über drei Werkzeuge hinweg bis in die Veröffentlichung zu graben – und aus einem einzelnen Datenleck eine ökosystemweite Gefährdung zu machen.
Besonders heikel war Version 1.82.8. Sie enthielt eine Datei mit dem Namen litellm_init.pth. Solche .pth-Dateien werden von Python bereits beim Start des Interpreters verarbeitet – der Schadcode konnte also loslaufen, ohne dass ein Entwickler LiteLLM überhaupt aktiv im Code eingebunden (importiert) hatte. Für Version 1.82.7 bestätigte LiteLLM einen Schad-Payload in der Datei litellm/proxy/proxy_server.py.
Die Sicherheitsdatenbank OSV (Eintrag PYSEC-2026-2) dokumentiert weitere Funktionen der Malware: Sie durchsuchte unter anderem .env-Dateien, LDAP-Konfigurationen, Shell-Verläufe und sogar Krypto-Wallet-Schlüssel, versuchte Cloud-Metadaten-Token und AWS-Secrets-Manager-Inhalte auszulesen und richtete Persistenz ein – also Mechanismen, um dauerhaft im System zu bleiben. Genannt werden ein als „System Telemetry Service“ getarnter systemd-Dienst sowie in Kubernetes-Umgebungen das Anlegen eines Pods. Zusätzlich rief der Code weitere Anweisungen von checkmarx[.]zone/raw ab.
Hier ist Präzision wichtig – und keine Panik. PyPI zählte im Angriffsfenster über 119.000 Downloads der manipulierten Versionen. CloudSEK rekonstruierte später mehr als 2.500 potenziell exponierte Organisationen und 434.000 potenziell exponierte CI/CD-Pipelines (automatisierte Bau- und Auslieferungs-Abläufe für Software).
Aber: Diese Zahlen belegen keine erfolgreiche Kompromittierung für jede genannte Organisation. CloudSEK betont das selbst deutlich:
„The 2,500+ company and 434,000 pipeline figures describe reconstructed exposure. They should not be read as proof that every listed organization was successfully compromised or that every credential was stolen.“ (CloudSEK)
Man muss also drei Stufen unterscheiden: exponiert (potenziell erreichbar), wahrscheinlich kompromittiert und bestätigt kompromittiert. Eine bestätigte Gesamtzahl abgeflossener personenbezogener Datensätze liegt in den geprüften Quellen nicht vor.
Für deutsche KMU ist der Vorfall vor allem dann relevant, wenn eine eigene Website, ein Shop, ein Kundenportal, ein KI-Chatbot oder eine Agentur- bzw. Entwicklungsumgebung Python, LiteLLM oder darauf aufbauende KI-Tools nutzt.
Besonders gefährdet waren:
Ein wichtiger Hinweis von PyPI: LiteLLM wird gewöhnlich rund 15 bis 20 Millionen Mal pro Woche installiert, und schätzungsweise 40 bis 50 Prozent dieser Installationen waren ungepinnt – zogen also bei jedem Vorgang automatisch die aktuellste (und damit im Angriffsfenster die vergiftete) Version.
Entwarnung für zwei Fälle: Wer die offizielle LiteLLM-Proxy-Docker-Version nutzte, war laut Hersteller nicht betroffen, weil dieser Weg die Abhängigkeiten festpinnt:
„Customers running the official LiteLLM Proxy Docker image were not impacted. That deployment path pins dependencies in requirements.txt and does not rely on the compromised PyPI packages.“ (LiteLLM)
Ebenso ist ein statisches CMS ohne Python/LiteLLM nicht unmittelbar durch dieses Paket betroffen. Trotzdem gilt: Fragen Sie bei Ihrem externen Webhoster, Ihrer Digitalagentur oder Ihrem KI-Dienstleister nach einer dokumentierten Prüfung.
python -m pip show litellm und durchsuchen Sie zusätzlich requirements*.txt, Lockfiles, Containerfiles, Image-Manifeste sowie Build- und Deployment-Logs nach litellm==1.82.7 oder litellm==1.82.8. Wichtig: pip show zeigt nur die gerade aktive Umgebung – suchen Sie über alle Umgebungen.pip install litellm, ein Upgrade, ein Image-Build oder eine transitive (indirekt mitgezogene) LiteLLM-Abhängigkeit? Da die Zeitangaben von LiteLLM und PyPI voneinander abweichen (LiteLLM: ab 10:39 UTC etwa 40 Minuten; PyPI: 2 Stunden 32 Minuten bis zur Quarantäne), sollte Ihre Log-Suche den gesamten 24. März 2026 abdecken.site-packages-Bereich nach litellm_init.pth. LiteLLM nennt beispielhaft: find /usr/lib/python3.13/site-packages/ -name "litellm_init.pth". Passen Sie den Pfad an Ihre Python-Version an. Ein Fund ist ein deutliches Warnzeichen.models.litellm[.]cloud und checkmarx[.]zone. Achten Sie zusätzlich auf unerwartete systemd-Dienste mit dem Tarnnamen „System Telemetry Service“ sowie auf unbekannte Kubernetes-Pods oder Service-Accounts.Wenn Sie eine der Versionen 1.82.7/1.82.8 gefunden haben oder sie ausgeführt wurde, gilt: Ein einfaches Update genügt nicht. Geheimnisse und Persistenzmechanismen können bereits kopiert worden sein.
litellm_init.pth, falls vorhanden, und bauen Sie betroffene Umgebungen aus einer nachweislich sauberen Basis neu auf. Ein bloßes pip uninstall ersetzt keine ordentliche Reaktion auf gestohlene Zugangsdaten.pip-compile --generate-hashes, uv lock oder Pipenv). Ein bloßes pip freeze ist kein sicherer Ersatz, weil die Artefakt-Hashes fehlen.uv unterstützt hierfür etwa exclude-newer.Die folgende Einordnung ist eine allgemeine Erläuterung und keine Rechtsberatung.
Wichtig zu verstehen: Die DSGVO-Relevanz hängt nicht davon ab, ob LiteLLM installiert war, sondern davon, ob durch den Vorfall personenbezogene Daten unbefugt zugänglich, offengelegt, verändert oder verloren wurden. Die entscheidende Frage lautet: Hatten die für LiteLLM erreichbaren Geheimnisse Zugriff auf CRM-, Shop-, Newsletter-, Support-, Datenbank- oder Hosting-Daten mit Personenbezug?
Wenn ja, muss der Verantwortliche den Vorfall dokumentieren und unverzüglich eine Risikobewertung durchführen. Der Europäische Datenschutzausschuss (EDPB) fasst die Pflichten so zusammen:
„If your SME acts as a data controller, there are three primary principles regarding data breaches: documentation; notification … within 72 hours, unless it is unlikely to result in a risk to individuals; and communication … where the breach is likely to result in a high risk to individuals.“ (EDPB)
Konkret: Eine Meldung nach Art. 33 DSGVO an die zuständige Aufsichtsbehörde ist innerhalb von 72 Stunden nach Bekanntwerden erforderlich – es sei denn, ein Risiko für Betroffene ist voraussichtlich unwahrscheinlich. Bei voraussichtlich hohem Risiko müssen zusätzlich die Betroffenen unverzüglich informiert werden. Ein Auftragsverarbeiter – etwa eine Agentur oder ein Hosting-/SaaS-Anbieter – muss den Verantwortlichen unverzüglich informieren; die Meldewege gehören in den Vertrag nach Art. 28 DSGVO.
Bußgeldrisiken sind stets einzelfallabhängig. Art. 83 DSGVO wägt unter anderem Schwere, Dauer, Verschulden, Minderungsmaßnahmen und die Zusammenarbeit mit der Aufsicht ab; die gesetzliche Obergrenze liegt bei bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist. Das ist keine automatische Sanktion und keine Prognose für diesen Vorfall.
Ein lehrreicher Vergleich ist der Codecov-Vorfall von 2021: Damals dokumentierte Codecov 108 Zeitfenster mit einem manipulierten Bau-Skript, über das potenziell Zugangsdaten aus CI-Umgebungen abfließen konnten. Die Lehre ist dieselbe wie heute: Bei kompromittierten Bau-Artefakten muss nicht nur der Paketstand geprüft werden, sondern der gesamte Umfang der Berechtigungen, die dem betroffenen Prozess zur Verfügung standen.
Der LiteLLM-Vorfall zeigt eindringlich, dass moderne Angriffe nicht mehr nur die öffentlich sichtbare Website treffen, sondern die unsichtbare Lieferkette der Software dahinter. Das eigentliche Risiko entsteht aus der Berechtigungstiefe des betroffenen Python-Prozesses – nicht aus der Größe Ihrer Website. CI/CD-Runner, Build-Server, Docker-Builder, Entwicklerrechner und KI-Gateways sind besonders kritisch, weil dort viele Schlüssel zusammenlaufen.
Für Sie als KMU heißt das: Wenn Sie oder Ihre Dienstleister Python und KI-Werkzeuge einsetzen, prüfen Sie systematisch auf die Versionen 1.82.7/1.82.8, auf die Datei litellm_init.pth und auf verdächtigen Netzwerkverkehr. Finden Sie Hinweise, handeln Sie sofort: isolieren, Geheimnisse rotieren, sauber neu aufbauen und die Datenschutz-Spur dokumentieren.
Und die richtige Sprachregelung, falls Ihr Unternehmen nur in einer Liste auftaucht: „potenziell exponiert – Validierung erforderlich“, nicht „erfolgreich gehackt“. Panik ist fehl am Platz – schnelles, geordnetes Handeln dagegen genau richtig. Denn erbeutete Zugangsdaten können auch Monate später noch missbraucht werden. Wer jetzt rotiert und aufräumt, schließt die Tür, bevor jemand hindurchgeht.