KI-Lieferkettenangriffe in 50 Tagen: Warum Release-Pipelines oft ignoriert werden

In den ersten 50 Tagen des Jahres 2026 erschütterten vier spektakuläre Lieferkettenangriffe auf KI-Unternehmen wie OpenAI, Anthropic und Meta die Branche. Drei der Vorfälle waren gezielte Cyberangriffe, während einer auf einen internen Fehler zurückging. Doch allen gemeinsam war ein kritischer Befund: Keiner der Angriffe zielte auf die KI-Modelle selbst, sondern auf die Release-Pipelines – die oft vernachlässigten Sicherheitslücken in der Softwareverteilung.

Mini Shai-Hulud: Ein selbstpropagierender Wurm in nur sechs Minuten

Am 11. Mai 2026 veröffentlichte ein neuartiger Wurm namens Mini Shai-Hulud 84 bösartige Paketversionen in 42 @tanstack/*-npm-Paketen innerhalb von sechs Minuten. Der Angriff nutzte eine Kombination aus einer pull_request_target-Fehlkonfiguration, einer Cache-Vergiftung in GitHub Actions und der Extraktion von OIDC-Tokens aus dem Speicher der CI-Runner. Das Verhängnis: Die Pakete verfügten über gültige SLSA Build Level 3-Provenienz, da sie aus dem richtigen Repository, über den korrekten Workflow und mit einem legitim erstellten OIDC-Token veröffentlicht wurden – ohne dass ein Passwort oder ein 2FA-Token kompromittiert werden musste.

Der Angriff zeigte, dass selbst vertrauenswürdige Mechanismen wie SLSA (Supply Chain Levels for Software Artifacts) keine absolute Sicherheit garantieren, wenn die Veröffentlichungsinfrastruktur selbst angreifbar ist. Die Angreifer – mit hoher Wahrscheinlichkeit die Gruppe TeamPCP – hatten damit einen Weg gefunden, die vertrauenswürdige Lieferkette zu unterwandern, ohne physische Zugangsdaten zu stehlen.

OpenAI: Kompromittierte Geräte durch CI/CD-Lücken

Nur zwei Tage später bestätigte OpenAI, dass zwei Mitarbeitergeräte kompromittiert worden waren und Anmeldedaten aus internen Code-Repositories exfiltriert wurden. Das Unternehmen reagierte mit der Zwangsinstallation neuer macOS-Sicherheitszertifikate bis zum 12. Juni 2026. OpenAI räumte ein, dass zwar bereits an der Härtung der CI/CD-Pipelines gearbeitet worden war, die betroffenen Geräte jedoch noch nicht die aktualisierten Konfigurationen erhalten hatten.

Dieser Vorfall unterstreicht ein zentrales Problem: Sicherheitsupdates erreichen nicht alle Systeme rechtzeitig, selbst wenn die Infrastruktur bereits gehärtet wird. Die Angriffsfläche lag hier nicht im Modell selbst, sondern in der Infrastruktur für die Modellverteilung – ein Bereich, der in herkömmlichen Red-Teaming-Aktivitäten oft ausgeklammert wird.

LiteLLM und Mercor: Eine Kettenreaktion durch eine vergiftete Abhängigkeit

Am 24. März 2026 nutzte die Gruppe TeamPCP gestohlene Anmeldedaten – ursprünglich aus einem früheren Kompromittierung des Vulnerability-Scanners Trivy von Aqua Security – um zwei vergiftete Versionen des LiteLLM-Pakets auf PyPI zu veröffentlichen. LiteLLM ist ein weitverbreiteter Open-Source-LLM-Proxy, der in der Infrastruktur vieler großer KI-Teams eingesetzt wird.

Die bösartigen Versionen waren nur 40 Minuten lang öffentlich und wurden dennoch fast 47.000 Mal heruntergeladen, bevor PyPI sie sperrte. Der Schaden war dennoch enorm: Die Attacke breitete sich auf Mercor aus, ein mit 10 Milliarden US-Dollar bewertetes KI-Datenunternehmen, das Trainingsdaten an Meta, OpenAI und Anthropic lieferte. Vier Terabyte an Daten – darunter proprietäre Trainingsmethoden von Meta – wurden exfiltriert. Meta beendete die Partnerschaft daraufhin unbefristet, und innerhalb weniger Tage folgte eine Klagewelle gegen Mercor.

Dieser Vorfall demonstriert, wie eine einzelne vergiftete Abhängigkeit eine branchenweite Kettenreaktion auslösen kann – eine Gefahr, die kein Modell-Red-Team hätte vorhersehen können.

Anthropic: Ein Source-Map-Leak durch menschliches Versagen

Am 31. März 2026 veröffentlichte Anthropic versehentlich Claude Code Version 2.1.88 mit einem 59,8 MB großen Source-Map-File im npm-Registry. Dieses File enthielt einen unverschlüsselten Link zu einem ZIP-Archiv auf Anthropics Cloudflare R2-Bucket, der 513.000 Zeilen unobfuskierten TypeScript-Code in 1.906 Dateien enthielt – darunter Agent-Orchestrierungslogik, System-Prompts und Multi-Agent-Koordinationsarchitekturen.

Der Vorfall war kein gezielter Angriff, sondern das Ergebnis eines menschlichen Fehlers: Ein fehlender Eintrag in der .npmignore-Datei führte dazu, dass sensible Build-Artefakte veröffentlicht wurden. Der Sicherheitsforscher Chaofan Shou entdeckte den Leak innerhalb weniger Stunden, woraufhin Anthropic das Paket umgehend zurückzog. Doch dies war bereits der zweite ähnliche Vorfall in 13 Monaten – ein klares Zeichen für systematische Lücken in den Veröffentlichungsprozessen.

Warum herkömmliche Sicherheitsaudits versagen

Die vier Vorfälle zeigen ein gemeinsames Muster: Keiner der Angriffe zielte auf die KI-Modelle selbst, sondern auf die Release-Pipelines und Abhängigkeiten. Dennoch werden diese Bereiche in den meisten Sicherheitsaudits und Red-Teaming-Übungen vernachlässigt. Typische Modell-Red-Teams testen zwar Sicherheitslücken in den Modellen, übersehen jedoch oft:

• CI/CD-Pipelines und deren Konfigurationen
• Abhängigkeitsmanagement und Paketveröffentlichungen
• Provenienzprüfungen und Integritätsnachweise
• Veröffentlichungsworkflows und Cache-Mechanismen

Sicherheitsexperten wie Tyler Jespersen von BeyondTrust Phantom Labs betonen, dass selbst kritische Schwachstellen wie Command-Injection-Angriffe (wie im Fall des OpenAI Codex) oft erst erkannt werden, wenn sie bereits ausgenutzt wurden.

Fazit: Lieferketten-Sicherheit muss zum Standard werden

Die vier Zwischenfälle in nur 50 Tagen sind kein Zufall, sondern ein Weckruf für die gesamte KI-Branche. Release-Pipelines, Abhängigkeiten und Veröffentlichungsworkflows müssen in jedem Sicherheitsaudit berücksichtigt werden – unabhängig davon, ob es sich um Open-Source-Projekte oder geschlossene KI-Systeme handelt.

Unternehmen wie OpenAI, Anthropic und Meta haben bereits reagiert, indem sie ihre CI/CD-Pipelines härten und neue Sicherheitszertifikate einführen. Doch die Herausforderung bleibt: Sicherheit ist kein einmaliger Prozess, sondern eine kontinuierliche Aufgabe, die alle Ebenen der Lieferkette umfassen muss. Die nächste Generation von KI-Sicherheitsstandards wird nicht nur die Modelle selbst, sondern auch die Infrastruktur dahinter in den Fokus nehmen müssen.

Wie schützen Sie Ihre KI-Lieferkette? Teilen Sie Ihre Erfahrungen und Best Practices in den Kommentaren.