Shai-Hulud über gekaperte KI-Coding-Session: Wurm erreicht rund 100 interne Repositories

Mandiant hat im AI-Risk-and-Resilience-Bericht vom September 2026 eine Fallstudie veröffentlicht, die kein klassisches Patch-Thema ist: Bei einem nicht genannten Software-as-a-Service-Anbieter übernahm ein Angreifer eine aktive Sitzung eines KI-Coding-Assistenten auf dem Arbeitsplatz eines Entwicklers. Der Assistent empfahl daraufhin die Installation eines externen Pakets, das der Angreifer zuvor vergiftet hatte. Die Empfehlung wurde angenommen. Danach installierte der Angreifer über dieselbe Sitzung einen Infostealer per präpariertem PyPI-Paket, griff GitHub-OAuth-Token ab und brachte den selbstverbreitenden Shai-Hulud-Wurm auf rund 100 interne Code-Repositories. Der Wurm stahl Repository-Secrets und exfiltrierte proprietären Produkt-Quellcode.

Betroffen ist konkret ein einzelnes Unternehmen, das Mandiant nicht benennt. Es gibt hier keine CVE, keinen Patch und kein verwundbares Produkt, das Sie heute aktualisieren müssten. Wer keine KI-Coding-Assistenten mit Repository- oder Token-Zugriff einsetzt, ist von diesem Angriffsweg nicht betroffen. Für alle anderen ist die Sache trotzdem heute relevant, aber als Konfigurations- und Berechtigungsfrage: Wenn ein Coding-Agent bei Ihnen mit den geladenen Anmeldedaten des Entwicklers arbeitet, ist er ein privilegierter Zugangsweg zu Ihren Repositories und sollte auch so behandelt werden. Ein ungeplantes Notfallfenster braucht es dafür in der Regel nicht, eine Bestandsaufnahme der ausgegebenen Token allerdings schon.

Was ist passiert?

Die Fallstudie steht als "Case study 1: Weaponizing active developer AI sessions to deploy the Shai-Hulud worm" im Mandiant-Bericht "AI risk and resilience" vom September 2026. Der dort beschriebene Ablauf lässt sich in fünf Schritten zusammenfassen, wie ihn Mandiant selbst darstellt.

• Der Angreifer kompromittierte den SaaS-Anbieter und kaperte eine aktive Sitzung eines KI-Coding-Assistenten auf einer Entwickler-Workstation.
• Der Assistent, der in der Umgebung als vertrauenswürdiger Interpreter lief, empfahl die Installation eines externen Softwarepakets, das der Angreifer vergiftet hatte.
• Mit der Annahme dieser Empfehlung wirkte der Assistent laut Mandiant als trojanisches Pferd: Über die aktive Sitzung wurde ein Infostealer per vergiftetem PyPI-Paket installiert und GitHub-OAuth-Token wurden abgegriffen.
• Anschließend verteilte der Angreifer den selbstverbreitenden Shai-Hulud-Wurm über etwa 100 interne Code-Repositories. Der Wurm automatisierte den Diebstahl von Repository-Secrets und die Exfiltration von Produkt-Quellcode.
• Danach vergiftete der Angreifer ein Paket in der offiziellen Namespace des Unternehmens. Ein weiterer Mitarbeiter zog die kompromittierte Version, was zu einer zweiten Infektion führte.

Wichtig für die Bewertung: Der öffentlich zugängliche Teil des Berichts sagt nicht, wann der Vorfall stattfand und nicht, wie der Angreifer die aktive Assistenten-Sitzung übernommen hat. Ob dahinter ein gestohlenes Session-Token, eine kompromittierte Erweiterung, ein Zugriff auf die Workstation oder ein anderer Weg steckt, ist damit offen. Auch eine Zuordnung dieser konkreten Fallstudie zu einer benannten Angreifergruppe nimmt Mandiant an dieser Stelle nicht vor. Die Zahl von rund 100 Repositories ist von Mandiant selbst als Näherung ("approximately") formuliert.

Wer ist betroffen?

Unmittelbar betroffen ist der nicht genannte SaaS-Anbieter. Für die Risikoeinschätzung im eigenen Haus ist aber das Muster entscheidend, nicht der einzelne Geschädigte. Relevant ist der Fall für Organisationen, die mindestens eine der folgenden Bedingungen erfüllen.

• KI-Coding-Assistenten oder Coding-Agenten laufen auf Entwickler-Arbeitsplätzen und haben Zugriff auf die dort geladenen Anmeldedaten, also Git-Credentials, GitHub-OAuth-Token, Personal Access Tokens oder npm-Publish-Token.
• Der Assistent darf Paketinstallationen vorschlagen oder ausführen, ohne dass ein Prüfschritt gegen eine Freigabeliste oder eine Prüfsumme dazwischen liegt.
• Die Organisation veröffentlicht eigene Pakete in einer öffentlichen Registry unter einem eigenen Namespace, etwa auf npm oder PyPI.
• Entwickler-Workstations dürfen Abhängigkeiten direkt aus dem Internet ziehen, statt über einen internen Proxy oder eine interne Registry.
• Repository-Token sind organisationsweit gültig und langlebig, statt eng auf einzelne Repositories und kurze Laufzeiten begrenzt.

Nicht betroffen von diesem konkreten Angriffsweg sind Umgebungen ohne KI-Coding-Assistenten sowie Aufbauten, in denen der Assistent in einem isolierten Container ohne Zugriff auf produktive Token läuft und Abhängigkeiten ausschließlich über eine kuratierte interne Registry kommen. Wer Anwender-Chatbots ohne Repository-Anbindung betreibt, ist ebenfalls nicht gemeint.

Wie kritisch ist das?

Technisch ist das keine Remote Code Execution gegen einen exponierten Dienst und keine lokale Rechteausweitung. Der Angriffspfad ist Missbrauch einer bereits authentifizierten Sitzung, gefolgt von Datenabfluss und Manipulation der Lieferkette. Der Angreifer musste keine Schwachstelle in einem Produkt ausnutzen, sondern nutzte eine Vertrauensbeziehung: Ein Werkzeug, dessen Vorschläge routinemäßig bestätigt werden, schlug etwas Schädliches vor.

Die Schadenswirkung im beschriebenen Fall ist dennoch erheblich, weil der Wurm zwei Dinge automatisierte, die sonst Angreiferzeit kosten: das Einsammeln von Secrets aus vielen Repositories und die Weiterverbreitung. Die zweite Infektionswelle über ein vergiftetes Paket im eigenen Namespace des Unternehmens zeigt zusätzlich, dass so ein Vorfall nicht am Rand des eigenen Netzes endet, sondern potenziell auch Kunden und nachgelagerte Projekte trifft.

Aspekt	Bewertung im beschriebenen Fall
Angriffspfad	Übernahme einer aktiven, bereits authentifizierten Assistenten-Sitzung
Erstinstallation	Infostealer über ein vergiftetes PyPI-Paket, vom Assistenten empfohlen
Erbeutete Zugangsdaten	GitHub-OAuth-Token
Ausbreitung	Shai-Hulud-Wurm über rund 100 interne Repositories
Datenabfluss	Repository-Secrets und proprietärer Produkt-Quellcode
Zweite Welle	Vergiftetes Paket im offiziellen Namespace des Unternehmens
Vorfallzeitpunkt	Im öffentlichen Bericht nicht genannt
Ursprung der Session-Übernahme	Im öffentlichen Bericht nicht erläutert
Zuordnung zu einer Gruppe	Für diese Fallstudie nicht vorgenommen

Ein Hinweis zur Einordnung des Namens: Shai-Hulud ist keine neue Malware. Die Wurmfamilie tauchte im September 2025 auf und lief seitdem in mehreren Wellen über npm und PyPI. 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. Diese Kampagnen sind eigenständig und werden in den vorliegenden Quellen nicht mit dem Mandiant-Vorfall verknüpft. Der Name im Titel bedeutet also nicht, dass Ihr Unternehmen automatisch Teil derselben Kampagne ist.

Was sollten Admins jetzt tun?

Da es keinen Patch gibt, beginnt die Arbeit mit einer Bestandsaufnahme. Die folgende Reihenfolge ist bewusst priorisiert.

• Inventar der KI-Coding-Werkzeuge erstellen. Welche Assistenten, IDE-Erweiterungen, CLI-Agenten und MCP-Server laufen auf Entwickler-Arbeitsplätzen, in welcher Version, und wer hat sie installiert? Unbekannte Erweiterungen zuerst klären.
• Berechtigungen dieser Werkzeuge prüfen. Für jeden Agenten festhalten, auf welche Token, Schlüssel und Repositories er faktisch zugreifen kann. Entscheidend ist nicht die dokumentierte Absicht, sondern was in der Umgebung technisch erreichbar ist.
• Token rotieren, die in Reichweite eines Coding-Agenten lagen. Das betrifft in der Praxis GitHub-OAuth-Token und Personal Access Tokens, npm- und PyPI-Publish-Token, Git-Credentials im Klartext, SSH-Schlüssel ohne Passphrase sowie Cloud- und CI-Zugangsdaten aus lokalen Umgebungsdateien. Bei Verdacht zuerst rotieren, dann analysieren.
• GitHub- und npm-Organisation kontrollieren. In den Organisationseinstellungen die autorisierten OAuth-Apps und GitHub-Apps durchgehen, unbekannte Integrationen entziehen, das Audit-Log nach ungewöhnlichen Push-, Fork- und Repository-Erstellungen durchsehen und die Liste der Paket-Maintainer sowie der aktiven Publish-Token prüfen.
• Auffällige Repositories und Paketversionen suchen. Neu angelegte Repositories, unerwartete Workflow-Dateien unter .github/workflows/, geänderte package.json-Install-Skripte und Paketversionen im eigenen Namespace, die niemand bewusst veröffentlicht hat.
• Logs auswerten. Proxy- und Firewall-Logs der Entwickler-Netze auf ungewöhnliche ausgehende Verbindungen prüfen, dazu die Registry-Logs auf Downloads und Publishes außerhalb der Arbeitszeiten.
• Härtung umsetzen. Secret Scanning und Push Protection in der Organisation aktivieren, Branch Protection mit Pflicht-Review für Standard-Branches erzwingen, Zwei-Faktor-Authentifizierung für alle Mitglieder verbindlich machen, Publishing wo möglich auf Trusted Publishing per OIDC umstellen, damit keine langlebigen Publish-Token mehr auf Arbeitsplätzen liegen, und Abhängigkeiten über eine interne Registry oder einen Proxy beziehen.
• Freigabeschritt vor Paketinstallationen einziehen. Mandiant empfiehlt für genau diesen Fall, von einem KI-Assistenten vorgeschlagene Drittanbieter-Abhängigkeiten gegen kryptografische Prüfsummen und Freigabelisten zu validieren, Erweiterungen von rohen API-Schlüsseln und langlebigen OAuth-Token fernzuhalten und den Abhängigkeitsverkehr über kontrollierte interne Repositories zu leiten.
• Backups und Wiederherstellung prüfen. Vor allem für die Registry-Metadaten und die CI-Konfiguration, damit ein vergiftetes Artefakt sauber zurückgerollt werden kann.

Für die Rotation von GitHub-Token lohnt ein kurzer Blick in die eigene Organisation, bevor Sie einzeln nachfassen. Der folgende Aufruf listet die Repositories einer Organisation mit ihrem letzten Push-Zeitpunkt, was beim Aufspüren unerwarteter Aktivität hilft.

# Repositories der eigenen Organisation mit letztem Push-Zeitpunkt auflisten
# GH_TOKEN vorher als Umgebungsvariable setzen, nicht im Befehl hinterlegen
gh repo list MEINE-ORG --limit 200 --json name,pushedAt,isPrivate
# Autorisierte Integrationen und Audit-Log in den Organisationseinstellungen gegenpruefen
gh api /orgs/MEINE-ORG/installations

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist die wichtigste Lehre aus diesem Fall organisatorisch, nicht technisch. Coding-Assistenten werden häufig als Produktivitätswerkzeug eingeführt und laufen deshalb außerhalb der Prozesse, die für andere privilegierte Zugänge selbstverständlich sind. Es gibt keine Inventarliste, keine Rechtematrix, keinen definierten Token-Lebenszyklus und oft auch keine Protokollierung dessen, was der Agent vorschlägt und ausführt. Genau diese Lücke hat der beschriebene Angriff genutzt.

Praktisch heißt das: Ein Coding-Agent gehört in dieselbe Kategorie wie ein Dienstkonto mit Repository-Zugriff. Er braucht eine benannte verantwortliche Person, eng gefasste Rechte, kurze Token-Laufzeiten und eine Protokollierung, die im Ernstfall die Frage beantworten kann, welche Pakete auf seinen Vorschlag hin installiert wurden. Der zweite Punkt ist die Angewohnheit, Vorschläge schnell zu bestätigen. Wenn eine Paketinstallation ein Änderungsvorgang ist und nicht nur ein Klick im Chatfenster, verliert der beschriebene Angriffsweg seinen entscheidenden Schritt.

Zum Aufwand: Die Bestandsaufnahme der eingesetzten Assistenten und der ihnen zugänglichen Token ist in einem kleinen Entwicklerteam an einem Arbeitstag machbar. Secret Scanning, Push Protection, verpflichtende Zwei-Faktor-Authentifizierung und Branch Protection sind in GitHub-Organisationen Konfigurationsschalter. Die Umstellung auf Trusted Publishing und eine interne Registry ist aufwendiger und gehört in ein geplantes Projekt, nicht in eine Nachtaktion.

Passende Anleitungen auf S-EDV

• KI-Agenten absichern: Härtung gegen Prompt Injection: zeigt, wie Sie Rechte, Werkzeugzugriffe und Freigabeschritte für Agenten einschränken.
• Keyv-npm-Wurm mit Hooks für Claude Code und VS Code: eine frühere Welle derselben Wurmfamilie mit Fokus auf Entwicklerwerkzeuge und Zugangsdaten.
• Grafana Labs, GitHub-Token und die TanStack-Lieferkette: Hintergrund zur Rolle gestohlener Token in Supply-Chain-Angriffen.

Quellen

• Mandiant, AI risk and resilience, Special Report September 2026, Case study 1 (Primärquelle, abgerufen am 17.09.2026)
• The Hacker News: Attacker Hijacks AI Coding Assistant Session, Spreads Shai-Hulud Across About 100 Repositories (16.09.2026)
• BleepingComputer: Shai-Hulud attack ships signed malicious TanStack, Mistral npm packages (12.05.2026, Hintergrund zur Wurmfamilie)