Vergiftete Modelle: Die KI-Lieferkette als neues Einfallstor - und wie man sie absichert

Wer 2026 ein KI-System aufbaut, lädt selten alles selbst: Modellgewichte kommen von einem öffentlichen Hub, die Inferenz-Bibliothek von PyPI, das Container-Image von einer Registry, das Gateway aus einem npm-Paket. Jeder dieser Bausteine ist ein fremdes Artefakt, das irgendwann in Ihrer Umgebung ausgeführt wird. Genau diese Kette – vom Download bis zum Produktivbetrieb – ist im ersten Halbjahr 2026 zum bevorzugten Einfallstor geworden.

Die Angriffe der letzten Monate zeigen ein Muster: Nicht die Firewall wird durchbrochen, sondern das Vertrauen. Ein manipuliertes Paket, ein präpariertes Modell, ein gekaperter Publishing-Zugang – und der Schadcode läuft im Herzen der KI-Pipeline, oft mit denselben Rechten wie die legitime Anwendung. Dieser Artikel ordnet die Angriffsfläche ein, belegt sie mit den konkreten Vorfällen dieses Jahres und zeigt, warum On-Premise-Betrieb die Voraussetzung, aber nicht die Garantie für Sicherheit ist.

Warum die KI-Lieferkette 2026 zum Ziel wurde

Die Angriffsfläche ist eine direkte Folge der Arbeitsweise moderner ML-Teams. Modelle und Bibliotheken werden im Minutentakt aus öffentlichen Quellen gezogen – Hugging Face, PyPI, npm, Container-Registries. Der Reflex „einfach installieren und laden" ist tief eingeübt, eine Provenienzprüfung findet in den seltensten Fällen statt. Das Vertrauen richtet sich auf den Namen des Repositories, nicht auf das konkrete Artefakt.

Diese Bequemlichkeit ist teuer erkauft, denn die Eigenschaften der Lieferkette verstärken jeden einzelnen Treffer:

• Modelle und ML-Pakete kommen meist ungeprüft aus öffentlichen Hubs. Ein pip install oder ein Modell-Download über die Transformers-Bibliothek ist bequemer als jede interne Freigabe – und genau deshalb der Normalfall.
• Ein einziges vergiftetes Artefakt kompromittiert die gesamte Pipeline. Weil ML-Code oft mit weitreichenden Rechten läuft (GPU-Zugriff, Netzwerk, Secrets), reicht ein schädliches Paket, um Trainings-Cluster, Inferenz-Server und CI/CD zu erreichen.
• Hier geht es um die Distribution, nicht ums Training. Klassische Datenvergiftung manipuliert Trainingsdaten. Der Lieferketten-Angriff sitzt eine Ebene davor oder danach: im Kanal, über den fertige Artefakte verteilt werden.
• Vertrauen in Repos ersetzt keine technische Verifikation. „Das kommt von einem bekannten Projekt" sagt nichts über die Integrität der konkret geladenen Version aus, wenn der Publishing-Zugang kompromittiert wurde.

Der entscheidende Punkt: Ein bekanntes, seriöses Projekt schützt nicht, wenn die Version, die Sie heute ziehen, aus einem gekaperten Account stammt. Genau das ist 2026 mehrfach passiert.

Die Vorfälle: LiteLLM, PyTorch Lightning, Bitwarden-CLI

Die These „KI-Lieferkette zum Ziel geworden" ist keine Prognose mehr, sondern durch eine zusammenhängende Angriffswelle belegt. Die drei folgenden Vorfälle stammen nach übereinstimmenden Analysen (Checkmarx u. a.) aus einer Kampagne, die dem Threat-Actor „TeamPCP" zugeordnet wird – teils unter dem Namen „Mini Shai-Hulud" geführt. Das macht sie besonders lehrreich: Es war kein Zufall, sondern ein systematisches Abgrasen der ML-nahen Distributionskanäle.

März 2026: LiteLLM auf PyPI

Am 24. März 2026 veröffentlichte der Angreifer zwei backdoored PyPI-Versionen (1.82.7 und 1.82.8) von LiteLLM. Der Zugang wurde nicht erraten – die PyPI-Publishing-Credentials wurden über eine kompromittierte Trivy-GitHub-Action in der CI/CD-Pipeline gestohlen. Die Pakete waren rund zwei bis drei Stunden verfügbar. LiteLLM ist ein LLM-Gateway, das API-Keys diverser Provider (OpenAI, Anthropic, Google u. a.) hält – ein ideales Ziel. Der Stealer arbeitete dreistufig: Credential-Harvesting (Cloud-Credentials, API-Keys, SSH-Keys, Kubernetes- und CI/CD-Tokens), anschließend Lateral Movement über Kubernetes und schließlich ein persistenter systemd-Backdoor.

April 2026: PyTorch Lightning und Bitwarden-CLI

Am 30. April 2026 folgten die schädlichen PyPI-Versionen 2.6.2 und 2.6.3 von PyTorch Lightning (CVE-2026-44484). Sie waren zwischen 12:45:20 und 13:27:30 UTC installierbar – exakt 42 Minuten, bevor die Community Alarm schlug und PyPI das Paket quarantänisierte. Der Stealer lädt zur Import-Zeit die Bun-Runtime von GitHub nach und führt einen rund 11 MB großen, obfuskierten Credential-Stealer aus.

Bereits am 22. April 2026 war das npm-Paket @bitwarden/cli@2026.4.0 etwa 90 Minuten kompromittiert (rund 334 Downloads). Ein preinstall-Hook lud erneut die Bun-Runtime plus einen ~9,7 MB großen Stealer nach. Besonders bemerkenswert: Die Zielliste umfasste explizit KI-Tool-Konfigurationen – Claude Code, Cursor, Kiro, Codex CLI und Aider – neben SSH-Keys, npm/GitHub-Tokens sowie AWS- und GCP-Credentials.

Vorfall	Kanal	Fenster	Kern-Payload
LiteLLM 1.82.7 / 1.82.8	PyPI	ca. 2–3 Std.	3-stufiger Stealer, K8s-Lateral-Movement, systemd-Backdoor
PyTorch Lightning 2.6.2 / 2.6.3	PyPI	42 Min.	Bun-Runtime + ~11 MB obfuskierter Credential-Stealer
@bitwarden/cli 2026.4.0	npm	ca. 90 Min.	preinstall-Hook, ~9,7 MB Stealer, zielt auf KI-Tool-Configs

Die Lehre aus der Tabelle: Selbst ein Angriffsfenster von 42 Minuten reicht. In automatisierten CI/CD-Pipelines, die permanent die neueste Version ziehen, ist eine Stunde eine Ewigkeit. Wer nicht auf feste, geprüfte Versionen pinnt, ist dem Zufall ausgeliefert, ob der eigene Build gerade in dieses Fenster fällt.

Pickle-Exploits: Warum das Ladeformat Code ausführt

Bis hierher ging es um Pakete. Jetzt zur zweiten Angriffsklasse – den eigentlich „vergifteten Modellen". Der Kern des Problems steckt im Serialisierungsformat, mit dem Modellgewichte über Jahre verteilt wurden: Pickle.

Pickle ist Pythons Standardformat, um Objekte zu speichern und wieder zu laden. Der Haken: Beim Deserialisieren führt Pickle nicht nur Daten zusammen, sondern kann beliebigen Python-Code ausführen. Das ist kein Bug, sondern by design – das Format darf beim Laden Objekte rekonstruieren und ruft dabei Konstruktoren und reduce-Methoden auf. Ein Angreifer, der eine Modelldatei präpariert, kann so Code hinterlegen, der allein durch das Laden des Modells startet. Kein Klick, kein Ausführen – der bloße load-Aufruf genügt.

Die Größenordnung der Angriffsfläche ist erheblich – wobei hier die belegbaren Zahlen wichtig sind, nicht die kursierenden Schätzungen:

• Über 1 Million Modelle sind auf Hugging Face gehostet (Angaben von „1,2 Mio." sind plausibel, aber nicht belastbar bestätigt). Jedes im Pickle-Format ist ein potenzieller Träger.
• Protect AI meldete rund 352.000 unsichere oder verdächtige Funde über etwa 51.700 Modelle hinweg; JFrog identifizierte rund 100 Modelle mit tatsächlicher Arbitrary-Code-Execution. Forbes berichtete 2024 von „tausenden" schädlichen Dateien.
• Schädliche Modelle werden seit mindestens 2024 wiederholt gefunden und meist binnen 24 Stunden entfernt – was zugleich heißt, dass sie zwischenzeitlich verfügbar waren.
• Model Cards und Metadaten sind kein Sicherheitsnachweis. Sie beschreiben das Modell, garantieren aber nicht die Integrität der Gewichtsdatei.

Die saubere Alternative heißt Safetensors. Das Format speichert reine Tensordaten plus Metadaten – und nichts, was ausgeführt werden könnte. Beim Laden werden ausschließlich Gewichte in den Speicher gelegt, es gibt keinen Deserialisierungs-Pfad für Code. Wer Safetensors erzwingt und Pickle-Modelle blockiert, schließt diese gesamte Angriffsklasse. Das Prinzip gilt formatübergreifend: Auch bei quantisierten Formaten wie GGUF ist entscheidend, dass die Ladepfade keine Code-Ausführung erlauben und die Datei aus einer verifizierten Quelle stammt.

Datenvergiftung im Verbund: Der 60-Dollar-Angriff

Die dritte Facette der „vergifteten Modelle" sitzt noch eine Ebene früher – nicht im verteilten Artefakt, sondern in den Daten, aus denen das Modell entstanden ist. Auch das gehört zur Lieferketten-Frage, denn Provenienz beginnt beim Trainingsdatensatz.

Wie billig Datenvergiftung sein kann, zeigte ein oft zitiertes Forschungsergebnis – wichtig: Es stammt aus dem Jahr 2023, nicht aus einem aktuellen 2026-Vorfall. Carlini et al. wiesen in „Poisoning Web-Scale Training Datasets is Practical" (arXiv:2302.10149, 20. Februar 2023) nach, dass sich 0,01 % großer Web-Datensätze wie LAION-400M bzw. COYO-700M für rund 60 US-Dollar praktisch vergiften ließen – über Split-View- und Frontrunning-Poisoning, bei dem Angreifer die Inhalte hinter zwischenzeitlich abgelaufenen URLs kontrollieren.

Für die Praxis heißt das:

• Poisoning von nur 0,01 % eines Datensatzes reichte im Forschungssetting aus – die Hürde liegt also niedrig, nicht hoch.
• Kleine Manipulationen wirken dauerhaft. Was einmal in den Gewichten steckt, lässt sich ohne erneutes Training kaum entfernen.
• Provenienz der Trainingsdaten ist Teil der Lieferkette. Ein Modell ist nur so vertrauenswürdig wie die Herkunft der Daten, auf denen es trainiert wurde.
• Model Cards und Datensatz-Zusammenfassungen als Prüfkriterium. Sie ersetzen keine technische Verifikation, geben aber Hinweise auf Herkunft, Lizenz und Zusammensetzung – und ihr Fehlen ist selbst ein Warnsignal.

On-Premise ist nicht automatisch sicher – aber kontrollierbar

An dieser Stelle die wichtigste Klarstellung dieses Artikels – und zugleich die Abgrenzung zu jedem, der Ihnen einfach nur einen Server verkaufen will: Eigenbetrieb löst das Lieferketten-Problem nicht per se. Ein vergiftetes Modell führt auch auf Ihrer Hardware seinen Pickle-Payload aus; ein gestohlener API-Key wird auch von Ihrem Server aus missbraucht, wenn das kompromittierte Paket erst einmal läuft.

Was On-Premise verändert, ist nicht die Immunität, sondern die Kontrolle. Sie entscheiden selbst, welche Artefakte überhaupt in Ihre Umgebung gelangen, und Sie können den Datenabfluss physisch unterbinden. Diese Kontrolle in konkrete Maßnahmen übersetzt:

• Kuratierte, intern geprüfte Modell-Registry statt öffentlicher Hub. Modelle und Pakete durchlaufen eine Freigabe und landen in einem internen Spiegel. Produktionssysteme ziehen nur von dort – nie direkt von PyPI, npm oder Hugging Face.
• Signierte Bereitstellung und Hash-Verifikation vor jedem Deployment. Jedes Artefakt hat einen bekannten, festgeschriebenen Hash. Weicht die geladene Datei ab, bricht der Prozess ab – genau das hätte die manipulierten PyPI-Versionen gestoppt.
• Air-gapped Betrieb entzieht kompromittierten Paketen die Callback-Wege. Ohne Internetzugang kann ein Stealer die erbeuteten Credentials nicht nach außen senden und keine zweite Stufe (wie die nachgeladene Bun-Runtime) beschaffen. Das ist die Domäne der Air-Gapped-KI.
• Safetensors erzwingen, Pickle-Modelle blockieren. Eine harte Richtlinie auf Loader-Ebene schließt die gesamte Pickle-Angriffsklasse – unabhängig davon, wie gut ein einzelner Scanner ist.

On-Premise ist damit die notwendige Bedingung für eine wirklich kontrollierbare Lieferkette – aber erst die genannten Maßnahmen machen daraus Sicherheit. Genau hier setzt seriöse KI-Sicherheit an: nicht beim Hardware-Kauf, sondern beim Prozess.

Praktische Absicherung: Ihre Checkliste für geprüfte Modelle

Die folgende Liste richtet sich an ML- und DevSecOps-Teams. Sie ist bewusst handlungsorientiert und deckt Provenienz wie Integrität ab. Nicht jeder Punkt ist an Tag eins umsetzbar – aber jeder einzelne hätte mindestens einen der oben beschriebenen Vorfälle entschärft.

1. Nur Safetensors aus verifizierten Quellen zulassen. Pickle-basierte Modelle (.bin, .pt, .ckpt mit Pickle) grundsätzlich blockieren oder vor Freigabe konvertieren. Der Loader erzwingt das Format, nicht die Disziplin einzelner Entwickler.
2. Pakete pinnen, per Hash prüfen und eine Software-Bill-of-Materials (SBOM) führen. Feste Versionen plus Hash-Verifikation (z. B. pip install --require-hashes) verhindern, dass ein 42-Minuten-Fenster Ihren Build trifft. Die SBOM macht nachvollziehbar, was überhaupt im System steckt.
3. Modelle vor Freigabe in einer isolierten Sandbox scannen. Neue Modelle zuerst in einem netzwerklosen Docker-Container laden und mit Werkzeugen wie picklescan/ModelScan prüfen. Erst nach bestandenem Scan wandern sie in die interne Registry.
4. Least-Privilege für Credentials, Secrets aus dem Code halten. Kein API-Key, SSH-Key oder Cloud-Token gehört in eine Umgebung, in der frisch gezogene Pakete laufen. Secrets über einen Vault mit kurzlebigen Tokens beziehen – so bleibt der Schaden begrenzt, falls doch ein Stealer greift.
5. Ergänzend: Laufzeit-Absicherung. Guardrails und Ausgangs-Monitoring fangen auffälliges Modellverhalten ab, regelmäßiges Red-Teaming deckt versteckte Backdoors auf. Beides ersetzt keine Provenienzprüfung, ergänzt sie aber wirksam.

Der rote Faden bleibt derselbe: Vertrauen in ein Repository ist keine Sicherheitsmaßnahme. Sicher wird die KI-Lieferkette erst, wenn jedes Artefakt vor dem Einsatz technisch verifiziert wird – und On-Premise gibt Ihnen die Hoheit, genau diese Prüfung zu erzwingen.

Häufig gestellte Fragen zur KI-Lieferkette

Ist ein selbst gehostetes Modell automatisch sicher?

Nein. On-Premise entzieht kompromittierten Artefakten zwar Callback-Wege und Datenabflusskanäle, aber ein vergiftetes Modell oder Paket kann trotzdem lokal Schaden anrichten. Sicher wird es erst durch eine kuratierte, geprüfte und signierte Lieferkette.

Warum ist das Pickle-Format gefährlich?

Pickle führt beim Deserialisieren beliebigen Python-Code aus. Ein manipuliertes Modell kann so beim bloßen Laden Schadcode starten. Die sichere Alternative ist Safetensors, das nur reine Gewichte lädt und keinen Code ausführt.

Was war der LiteLLM-Vorfall?

Im März 2026 wurde das LiteLLM-Paket auf PyPI kompromittiert. Angreifer stahlen über eine kompromittierte CI/CD-Action die Publishing-Credentials und veröffentlichten zwei backdoored Versionen mit Credential-Stealer. Da LiteLLM als LLM-Gateway API-Keys diverser Provider hält, waren potenziell hunderttausende Systeme betroffen – ein Beleg, dass auch etablierte ML-Pakete Teil der Angriffsfläche sind.

Wie sichern wir unsere Modell-Lieferkette ab?

Nur Safetensors aus verifizierten Quellen zulassen, Pakete pinnen und per Hash prüfen, eine Software-Bill-of-Materials führen, Modelle vor Freigabe in einer Sandbox scannen und eine kuratierte interne Registry statt öffentlicher Hubs nutzen.