Sicherheitsexperten von Mandiant haben einen Cyberangriff auf einen ungenannten Software-as-a-Service-Anbieter öffentlich gemacht, bei dem ein Angreifer die aktive Sitzung eines KI-gestützten Programmierassistenten übernahm. Über die gekaperte Sitzung verteilte er den selbstverbreitenden Wurm Shai-Hulud über rund 100 interne Code-Repositories und stahl Zugangsdaten sowie proprietären Quellcode. Der Fall zeigt, wie vertrauenswürdige KI-Helfer zur Einfallspforte für Lieferkettenangriffe werden.
Der Fall ist Teil des Berichts „AI risk and resilience“ von Mandiant (Google Cloud) vom September 2026 und wird dort als „Case study 1: Weaponizing active developer AI sessions to deploy the Shai-Hulud worm“ geführt [1] [3]. Er gilt als Beleg dafür, dass Angreifer KI-Werkzeuge in Entwicklungsumgebungen nicht mehr nur zur Beschleunigung ihrer Arbeit nutzen, sondern gezielt als Angriffsvektor missbrauchen.
So lief der Angriff ab
Nach den öffentlich zugänglichen Angaben von Mandiant begann die Kompromittierung mit einer Fehlleitung durch den KI-Assistenten: Das System empfahl die Installation eines externen Softwarepakets, das der Angreifer zuvor vergiftet hatte [1]. Nachdem diese Empfehlung akzeptiert worden war, installierte der Angreifer über die aktive Sitzung des Entwicklers einen Infostealer über ein präpariertes PyPI-Paket und griff GitHub-OAuth-Tokens ab [1] [2].
Anschließend brachte er den selbstverbreitenden Wurm Shai-Hulud auf rund 100 interne Code-Repositories. Der Wurm automatisierte den Diebstahl von Repository-Secrets und die Exfiltration des Quellcodes von Unternehmensprodukten [1] [3]. In einer zweiten Welle vergiftete der Angreifer zudem ein Paket im offiziellen Namespace des Unternehmens; ein weiterer Mitarbeiter zog die kompromittierte Version, was zu einer zweiten Infektion führte [1] [3].
Der öffentlich zugängliche Teil des Berichts nennt weder den Zeitpunkt des Eindringens noch den genauen Weg, über den der Angreifer die aktive Assistenten-Sitzung übernahm [1] [3]. Auch eine Zuordnung zu einer benannten Angreifergruppe nimmt Mandiant für diese Fallstudie nicht vor. Die Zahl von rund 100 Repositories ist laut Mandiant selbst als Näherung („approximately“) zu verstehen [3].
Kein Patch, kein verwundbares Produkt
Für Admins ist der Fall ungewöhnlich, weil es keine klassische Schwachstelle gibt: keine CVE, keinen Patch und kein Produkt, das aktualisiert werden müsste [3]. Der Angriffspfad ist der Missbrauch einer bereits authentifizierten Sitzung, gefolgt von Datenabfluss und Manipulation der Lieferkette. Der Angreifer nutzte keine Sicherheitslücke, sondern eine Vertrauensbeziehung: Ein Werkzeug, dessen Vorschläge routinemäßig bestätigt werden, empfahl etwas Schädliches [3].
Die Schadenswirkung ist dennoch erheblich, weil der Wurm zwei Schritte automatisierte, die sonst viel Angreiferzeit kosten: das Einsammeln von Secrets aus vielen Repositories und die Weiterverbreitung. Die zweite Infektionswelle über ein vergiftetes Paket im eigenen Namespace zeigt zudem, dass ein solcher Vorfall nicht am Rand des eigenen Netzes endet, sondern potenziell auch Kunden und nachgelagerte Projekte trifft [3].
Einordnung: Shai-Hulud ist keine neue Malware
Shai-Hulud ist keine neue Schadsoftware. Die Wurmfamilie tauchte im September 2025 auf und lief seither in mehreren Wellen über die Paketregister npm und PyPI [3]. Bei der Welle vom Mai 2026 rund um TanStack- und Mistral-Pakete zählte Endor Labs nach Angaben von BleepingComputer über 160 kompromittierte Pakete, Aikido 373 schädliche Paketversionen und Socket 416 betroffene Artefakte über npm und PyPI hinweg [3]. Diese Kampagnen sind eigenständig und werden in den vorliegenden Quellen nicht mit dem Mandiant-Vorfall verknüpft [1] [3].
Der Bericht von Mandiant enthält weitere Vorfälle, die das Risikobild ergänzen: In einem Fall ermöglichten ein vergiftetes internes KI-Repository und manipulierte Befehlszeilen-Hooks eine vollständige Remotecodeausführung [2]. In einem weiteren Szenario führte ein autonomer Agent innerhalb von weniger als einer Stunde über 15.000 Anfragen an Reasoning-Schnittstellen aus; die unkontrollierte Aktivität verursachte geschätzte Cloud-Kosten von rund 50.000 US-Dollar und blockierte zugleich eine Unternehmensdatenbank [2].
Empfohlene Gegenmaßnahmen
Mandiant empfiehlt für die Absicherung KI-gestützter Entwicklung drei zentrale Kontrollen [1] [3]:
-
Von KI-Assistenten vorgeschlagene Drittanbieter-Abhängigkeiten gegen kryptografische Prüfsummen und Freigabelisten validieren.
-
Rohe API-Schlüssel und langlebige OAuth-Tokens außerhalb der Reichweite von Erweiterungen halten.
-
Den Datenverkehr für Abhängigkeiten über kontrollierte interne Repositories leiten.
Darüber hinaus raten die Sicherheitsexperten, vertrauliche Zugangsdaten strikt von Entwicklungserweiterungen fernzuhalten, dynamische Identitäten für Arbeitslasten anstelle langlebiger Service-Accounts einzusetzen und die Telemetriedaten von KI-Assistenten lückenlos in bestehende Sicherheitsüberwachungssysteme wie SIEM- und EDR-Lösungen einzuspeisen [2].
Für Unternehmen ist die wichtigste Lehre organisatorischer Natur: Ein Coding-Agent gehört in dieselbe Kategorie wie ein Dienstkonto mit Repository-Zugriff – mit benannter Verantwortung, eng gefassten Rechten, kurzen Token-Laufzeiten und einer Protokollierung, die im Ernstfall beantworten kann, welche Pakete auf seinen Vorschlag hin installiert wurden [3]. Wenn eine Paketinstallation als Änderungsvorgang behandelt wird und nicht nur als Klick im Chatfenster, verliert der beschriebene Angriffsweg seinen entscheidenden Schritt.