SANDCLOCK: LiteLLM-Supply-Chain-Angriff greift CI/CD-Secrets ab

Veröffentlicht am 18.08.2026

Ein einziger manipulierter Software-Baustein reichte aus, um Cloud-Schlüssel, SSH-Zugänge, Datenbankpasswörter und die Zugangsdaten ganzer Bauprozesse abzugreifen: Am 24. März 2026 gelangten zwei bösartige Versionen des weit verbreiteten KI-Gateways LiteLLM auf die offizielle Python-Paketquelle PyPI. Wer in diesem Zeitfenster die Versionen 1.82.7 oder 1.82.8 installierte oder ausführte, könnte unbemerkt einen Datendiebstahl im Herzen seiner IT ausgelöst haben – vor allem in automatisierten Bau- und Deployment-Pipelines (sogenannten CI/CD-Umgebungen, in denen Software gebaut und veröffentlicht wird).

Dieser Vorfall ist kein gewöhnlicher Programmierfehler, den man mit einem schnellen Update behebt. Es handelt sich um einen Supply-Chain-Angriff – also einen Angriff auf die Software-Lieferkette: Nicht ein gefälschtes Nachahmerpaket, sondern das echte, vertrauenswürdige Projekt wurde mit Schadcode versehen. Das macht die Sache so gefährlich. In diesem Artikel erklären wir verständlich, was passiert ist, ob Sie betroffen sein könnten, wie Sie das prüfen und was Sie jetzt konkret tun müssen.

Was ist passiert?

LiteLLM ist ein Open-Source-Werkzeug, mit dem Anwendungen verschiedene KI-Modelle über eine einheitliche Schnittstelle ansteuern – etwa für Chatbots, interne Tools oder KI-Agenten. Das Projekt ist enorm verbreitet: Laut PyPI wurde es typischerweise rund 15 bis 20 Millionen Mal pro Woche installiert.

Nach der offiziellen LiteLLM-Mitteilung veröffentlichte ein Angreifer am 24. März 2026 um 10:39 UTC die manipulierte Version 1.82.7, kurz darauf um 10:52 UTC folgte 1.82.8. Ursache war nach damaligem Ermittlungsstand ein kompromittierter Maintainer- bzw. Veröffentlichungszugang. Der Angreifer umging die regulären, abgesicherten Veröffentlichungswege über GitHub und lud die Schadpakete direkt zu PyPI hoch.

„The compromised PyPI packages were litellm==1.82.7 and litellm==1.82.8.“ – LiteLLM, offizielle Security-Mitteilung

Die beiden Versionen enthielten einen sogenannten Credential-Stealer – Schadcode, der gezielt Zugangsdaten sammelt und nach außen schickt. Betroffen sein können laut den Analysen von OSV, Datadog und Snyk: API-Schlüssel, Umgebungsvariablen, SSH-Schlüssel, Git- und Registry-Tokens, .env-Dateien, Cloud-Zugangsdaten für AWS, GCP und Azure, Kubernetes-Service-Account-Tokens, Datenbank- und LDAP-Konfigurationen sowie Shell-Historien. Die gestohlenen Daten wurden lokal verschlüsselt und per HTTPS an die Angreifer-Domain models.litellm.cloud übertragen.

Die bösartigen Versionen wurden schnell entdeckt und aus dem Verkehr gezogen – LiteLLM nennt ein Expositionsfenster von etwa 40 Minuten, PyPI berechnete vom Upload bis zur Quarantäne 2 Stunden und 32 Minuten. In dieser kurzen Zeit wurden die Schadpakete jedoch bereits über 119.000 Mal heruntergeladen.

Der technische Hintergrund – verständlich erklärt

Die zweite Version, 1.82.8, war besonders heimtückisch. Sie enthielt eine Datei namens litellm_init.pth. Solche .pth-Dateien werden von Python bereits beim Start des Interpreters verarbeitet – also jedes Mal, wenn irgendwo Python gestartet wird. Der entscheidende Punkt: Der Schadcode konnte auslösen, ohne dass LiteLLM überhaupt aktiv verwendet oder importiert wurde. Für automatisierte Bauprozesse ist das gefährlich, weil bereits ein beliebiger Build-Schritt oder ein Werkzeug, das Python startet, den Schadcode aktivieren konnte.

In der ersten Version 1.82.7 steckte der Schadcode dagegen in der Datei litellm/proxy/proxy_server.py und wurde erst beim Import des Proxy-Moduls ausgelöst.

Die Sicherheitsforscher von Datadog und Snyk zeichnen eine ganze Angriffskette nach: Zuvor, am 19. März 2026, war bereits das Sicherheits-Scanning-Werkzeug Trivy kompromittiert worden. Über gestohlene CI/CD- und PyPI-Zugangsdaten führte der Weg dann weiter zu den LiteLLM-Releases. Diese Zuordnung – der Kampagne werden die Namen „TeamPCP“ und „SANDCLOCK“ zugeschrieben – ist als öffentliche technische Einschätzung zu verstehen, nicht als gerichtsfest bewiesene Täterzuordnung.

Wichtig zur Einordnung: Für diesen Vorfall gibt es keine klassische CVE-Nummer, weil es sich nicht um einen Programmierfehler handelt. Die formale Kennung lautet PYSEC-2026-2 (Alias MAL-2026-2144); Snyk führt den Fall als SNYK-PYTHON-LITELLM-15762713 und stuft ihn ausdrücklich als „Attacked“ ein – also als tatsächlich ausgenutzt, nicht als theoretische Lücke.

Wer ist betroffen?

Für deutsche KMU wird das Risiko konkret, wenn Ihre Website, ein KI-Chatbot, eine KI-Agenten-Anwendung, ein internes Tool oder eine Bau-Pipeline LiteLLM per pip bezogen hat – direkt oder als transitive Abhängigkeit (also als Unterbaustein eines anderen Pakets). Besonders gefährdet sind Systeme mit weitreichenden Rechten: Build-Runner mit Veröffentlichungsrechten, Cloud-Administrationszugängen, Zugriff auf Secrets-Manager, Kubernetes-Berechtigungen, Registries oder Kunden- und Produktivdaten.

Eine gute Nachricht gibt es laut LiteLLM: „Customers running the official LiteLLM Proxy Docker image were not impacted.“ Wer also das offizielle LiteLLM-Proxy-Docker-Image verwendete, war nach Herstellerangabe nicht betroffen.

Zur Größenordnung kursieren große Zahlen, die aber richtig einzuordnen sind. CloudSEK rekonstruierte eine potenzielle Exposition von mehr als 2.500 Unternehmen und 434.000 CI/CD-Pipelines. Resecurity berichtet über ein 152,5 GiB großes Datenarchiv mit 415.427 Secret-Capture-Dateien sowie Manifeste zu 898 GitHub-Ownern und 2.038 Repositories. Beide Anbieter betonen ausdrücklich, dass diese Zahlen keine bestätigten Opferzahlen sind:

„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

Auch die 119.000 Downloads sind keine Zahl einzelner Unternehmen oder personenbezogener Datensätze. Wer die betroffenen Versionen sicher nie bezogen oder ausgeführt hat, hat aus diesem Vorfall kein unmittelbares technisches Risiko.

So prüfen Sie, ob Sie betroffen sind

Wichtiger Sicherheitshinweis vorab: Bei Version 1.82.8 kann bereits das Starten von Python in der verdächtigen Umgebung den Schadcode auslösen. Trennen Sie verdächtige Hosts, Container und CI-Runner deshalb vom Netz (besonders vom ausgehenden Verkehr), bevor Sie sie analysieren, und starten Sie nicht unbedacht pip oder python darin.

1. Alle Systeme identifizieren, auf denen LiteLLM direkt oder als Unterabhängigkeit verwendet wurde. Prüfen Sie: requirements.txt, constraints.txt, pyproject.toml, poetry.lock, uv.lock, Pipfile.lock, Dockerfiles, Helm-Charts, CI/CD-Workflows und Paket-Caches.
2. In den Logs suchen: Durchsuchen Sie Build-, Deployment- und Registry-Logs für den 24. März 2026 nach den exakten Zeichenketten litellm==1.82.7 und litellm==1.82.8. Prüfen Sie auch, ob in dem Fenster ein nicht festgeschriebenes pip install litellm lief.
3. Nach der verräterischen Datei suchen: Suchen Sie auf einem isolierten oder offline gemounteten Dateisystem im site-packages-Verzeichnis nach litellm_init.pth. Ein Fund ist ein starker Hinweis auf Version 1.82.8.
4. Netzwerkverkehr prüfen: Durchsuchen Sie DNS-, Proxy- und EDR-Logs nach models.litellm.cloud und checkmarx.zone sowie nach ausgehenden HTTPS-POSTs aus dem Python- oder Build-Kontext. Kein Treffer schließt eine frühere Exfiltration allerdings nicht sicher aus.
5. Auf Spuren im Dateisystem prüfen (IoCs): ~/.config/sysmon/sysmon.py, ~/.config/systemd/user/sysmon.service, /tmp/tpcp.tar.gz, /tmp/session.key, /tmp/payload.enc, /tmp/session.key.enc, /tmp/.pg_state und /tmp/pglog. Nicht vorschnell löschen – zuerst Beweise sichern.
6. Kubernetes prüfen: Suchen Sie in den Audit-Logs nach ungewöhnlichem Secret-Zugriff, privilegierten Pods und Podnamen nach dem Muster node-setup-*.
7. Erreichbarkeit der Secrets dokumentieren: Notieren Sie für jedes verdächtige System, welche Zugangsdaten der Prozess lesen konnte. Diese Analyse bestimmt Umfang der Rotation und den Datenschutz-Risikoscope.

Das müssen Sie jetzt tun

Datadog bringt die zentrale Botschaft auf den Punkt:

„Do not treat reverting the compromised packages as a complete remediation.“ – Datadog Security Research

Ein bloßes Zurücksetzen oder Upgrade reicht also nicht. Gehen Sie systematisch vor:

1. Isolieren und pausieren: Trennen Sie betroffene oder nicht sicher auszuschließende Runner, Hosts und Container. Pausieren Sie neue Deployments aus diesen Umgebungen. Sichern Sie Logs, Images und Systemartefakte für die Untersuchung.
2. Alle erreichbaren Zugangsdaten rotieren – nicht nur den LiteLLM- oder OpenAI-Schlüssel: GitHub-Tokens und App-Private-Keys, PyPI-/Registry-Tokens, Cloud-Zugangsdaten und -Rollen, SSH-/Deploy-Keys, Datenbankpasswörter, Kubernetes-Service-Account-Tokens, CI/CD-Secrets, Webhooks und LLM-Provider-Keys. Widerrufen Sie, wo möglich, Sitzungen und Refresh-Tokens.
3. Sauber neu bauen: Bauen und deployen Sie aus bekannten sauberen Build-Inputs neu. Entfernen Sie die kompromittierten Versionen aus Requirements-, Constraint- und Lock-Dateien sowie aus allen Caches.
4. Audit-Logs auswerten: Prüfen Sie Cloud-, Git- und Registry-Logs ab dem Expositionszeitraum auf unerwartete Logins, Token-Nutzung, IAM-Änderungen, Abrufe aus Secrets-Managern, neue Zugänge und verdächtige Commit- oder Workflow-Änderungen.
5. Kubernetes absichern: Prüfen und rotieren Sie bei Verdacht Service-Account-Tokens und RBAC-Rechte, isolieren Sie privilegierte oder unbekannte Pods.
6. Zukünftig härten: Verwenden Sie exakte Versionen samt Hashes in Lock-Dateien, übernehmen Sie neue Paketversionen nicht sofort ungeprüft (Cooldown-Strategie), setzen Sie kurzlebige, minimal privilegierte Zugangsdaten sowie OIDC/Workload Identity statt langlebiger Schlüssel ein und pinnen Sie Build-Abhängigkeiten auf unveränderliche Commit-SHAs. PyPI empfiehlt für Veröffentlichungen „Trusted Publishers“ und phishing-resistente Zwei-Faktor-Authentifizierung.

Zum Patch-Stand: Die kompromittierten Versionen 1.82.7 und 1.82.8 wurden entfernt. LiteLLM veröffentlichte am 30. März 2026 die saubere Version v1.83.0 aus einer überarbeiteten CI/CD-Pipeline und bestätigte die Releases v1.78.0 bis v1.82.6 nach Prüfung gegen die bekannten Indikatoren als sauber. Denken Sie aber daran: In einer möglicherweise dauerhaft kompromittierten Umgebung ist ein Upgrade allein keine vollständige Bereinigung.

Einordnung und DSGVO: Wann wird es meldepflichtig?

Ein kompromittiertes Python-Paket ist nicht automatisch eine meldepflichtige Datenschutzverletzung. DSGVO-relevant wird der Vorfall erst, wenn die betroffene Umgebung personenbezogene Daten verarbeiten oder darauf zugreifen konnte und eine Verletzung der Vertraulichkeit, Integrität oder Verfügbarkeit eingetreten oder hinreichend wahrscheinlich ist. Der Begriff umfasst laut Art. 4 Nr. 12 DSGVO ausdrücklich den unbefugten Zugang und die unbefugte Offenlegung personenbezogener Daten. Bei einer Website kann das etwa Kundendatenbanken, CRM- und Shop-Zugänge, Ticket- und Newsletter-Systeme, Backups, Logdaten, Mitarbeiterdaten oder Cloud-Speicher betreffen.

Der Europäische Datenschutzausschuss (EDPB) formuliert den Grundsatz so:

„all data breaches should be notified to the relevant DPA, except for those unlikely to present any risk to individuals.“ – EDPB, KMU-Leitfaden

Ihre Pflichten im Ernstfall:

• Dokumentation: Jeder Vorfall ist zu dokumentieren – auch wenn Sie am Ende keine Meldung abgeben.
• Meldung an die Aufsichtsbehörde (Art. 33 DSGVO): Besteht voraussichtlich ein Risiko für die Rechte und Freiheiten natürlicher Personen, ist die zuständige Datenschutzaufsicht unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden zu informieren. Eine gestufte Meldung ist möglich, wenn zunächst Informationen fehlen.
• Benachrichtigung Betroffener (Art. 34 DSGVO): Bei voraussichtlich hohem Risiko sind die betroffenen Personen unverzüglich und in klarer Sprache zu informieren – vorbehaltlich der gesetzlichen Ausnahmen.
• Auftragsverarbeiter (Art. 33 Abs. 2 DSGVO): Wer als Dienstleister betroffen ist, muss den Verantwortlichen ohne unangemessene Verzögerung informieren.

Zur Haftung: Art. 32 DSGVO verlangt risikoadäquate technische und organisatorische Maßnahmen. Verstöße gegen die Art. 32 bis 34 können nach Art. 83 Abs. 4 DSGVO mit Geldbußen von bis zu 10 Millionen Euro oder bis zu 2 % des weltweiten Jahresumsatzes geahndet werden – je nachdem, welcher Betrag höher ist. Das ist ein Höchstrahmen und keine Prognose für diesen Einzelfall. Für LiteLLM ist zum Recherchezeitpunkt kein behördlich festgestelltes Bußgeld bekannt. Entscheidend ist eine dokumentierte, schnelle Risikobewertung im Einzelfall – idealerweise gemeinsam mit Ihrem Datenschutzbeauftragten und gegebenenfalls rechtlicher Beratung.

Kein Einzelfall: das größere Bild

Der LiteLLM-Vorfall reiht sich in eine Serie ähnlicher Angriffe ein. Bereits die vorgelagerte Kompromittierung von Trivy im März 2026 zeigt, wie ein manipuliertes Sicherheits-Werkzeug als Sprungbrett in weitere Lieferketten dient. Und der prominente Fall XZ Utils von 2024 (CVE-2024-3094), bei dem Schadcode in die Upstream-Pakete einer weit verbreiteten Kompressionsbibliothek eingeschleust wurde, macht das Grundmuster deutlich: Manipulierte Komponenten in einer vertrauenswürdigen Lieferkette können Systeme erreichen, obwohl das Paket selbst völlig legitim erscheint.

Fazit

Der LiteLLM-Angriff ist ein Lehrstück moderner Software-Lieferketten-Risiken: kein Programmierfehler, sondern ein echtes, vertrauenswürdiges Paket, das mit Schadcode versehen wurde und in einem kurzen Zeitfenster über 119.000 Mal heruntergeladen wurde. Wer die Versionen 1.82.7 oder 1.82.8 in einer produktiven Umgebung installiert oder ausgeführt hat, muss davon ausgehen, dass alle für den betroffenen Prozess erreichbaren Zugangsdaten kompromittiert sein können – und entsprechend handeln.

Die entscheidenden Schritte lauten: betroffene Systeme identifizieren und isolieren, alle erreichbaren Zugangsdaten rotieren, sauber neu bauen, Audit-Logs auswerten und – falls personenbezogene Daten im Spiel waren – die DSGVO-Meldepflicht sorgfältig und zeitnah prüfen. Wer die Versionen dagegen sicher nie bezogen hat, kann aufatmen, sollte den Fall aber zum Anlass nehmen, die eigenen Bau- und Deployment-Prozesse zu härten. Denn der nächste Supply-Chain-Angriff ist keine Frage des Ob, sondern des Wann.