Ein KI-Coding-Assistent gehört in vielen Entwicklerteams inzwischen zur Standardausrüstung, genau wie eine IDE oder ein Git-Client. Genau das hat sich am 16. September 2026 als Sicherheitsproblem entpuppt. Die Google-Tochter Mandiant meldete laut The Hacker News den nach eigenen Angaben ersten dokumentierten Fall, in dem ein Angreifer die aktive Sitzung eines KI-Coding-Assistenten bei einem nicht genannten SaaS-Anbieter übernommen und darüber die Wurm-Malware “Shai-Hulud” in rund 100 interne Code-Repositories geschleust hat. Der Vorfall zeigt, wie aus einem Werkzeug, das Code vorschlägt und Pull Requests öffnet, ein Einfallstor für die gesamte Software-Lieferkette wird.
Der Angriff im Detail: Vom vergifteten Paket zur Wurm-Ausbreitung
Der Ablauf, den Mandiant rekonstruiert hat, beginnt harmlos. Ein Entwickler bei dem betroffenen SaaS-Unternehmen ließ sich von seinem KI-Coding-Assistenten eine Software-Abhängigkeit vorschlagen. Das Paket, ein präparierter PyPI-Eintrag, stammte jedoch von einem Angreifer und enthielt einen Infostealer. Der Entwickler folgte der Empfehlung des Assistenten und installierte das Paket, ohne die Herkunft zu prüfen. Damit hatte der Angreifer bereits Zugriff auf Zugangsdaten und Session-Tokens im Entwicklungsrechner.
Der eigentliche Bruch folgte im zweiten Schritt: Der Angreifer kaperte die noch aktive Sitzung des KI-Assistenten selbst. Weil solche Assistenten oft mit weitreichenden Lese- und Schreibrechten auf Repositories, Build-Pipelines und teils sogar Paketregister ausgestattet sind, konnte der Angreifer diese Rechte missbrauchen, statt sie sich mühsam selbst zu erarbeiten. Über die gekaperte Sitzung verteilte er die selbstverbreitende Schadsoftware Shai-Hulud in etwa 100 interne Repositories des Unternehmens. Die Zahl macht deutlich, wie schnell sich ein einzelner kompromittierter Zugang in einer Organisation ausbreiten kann, wenn ein KI-Assistent quasi als Universalschlüssel für den gesamten Quellcode fungiert.
Wer betroffen ist – und warum Mandiant den Namen zurückhält
Mandiant nennt weder das betroffene Unternehmen noch den verwendeten KI-Coding-Assistenten öffentlich. Diese Zurückhaltung ist in der Incident-Response-Branche üblich, wenn eine Untersuchung noch läuft oder vertragliche Vertraulichkeit greift. Wichtiger als der Name des Opfers ist ohnehin die strukturelle Erkenntnis: Das Unternehmen wird als “unbenannter SaaS-Anbieter” beschrieben, was nahelegt, dass es sich um einen Anbieter handelt, dessen Software wiederum von zahlreichen Kunden eingesetzt wird. Ein kompromittiertes SaaS-Produkt kann also theoretisch weitere Kunden in einer zweiten Angriffswelle treffen, ähnlich wie bei früheren Lieferkettenvorfällen etwa rund um SolarWinds oder die npm-Registry.
Bemerkenswert ist außerdem, dass Mandiant den Vorfall ausdrücklich nicht als Einzelfall eines schlecht konfigurierten Tools einordnet, sondern als Beleg dafür, dass KI-Coding-Assistenten grundsätzlich Teil der Angriffsfläche der Software-Lieferkette geworden sind. Ein Assistent, der Code lesen, schreiben und über mehrere Repositories hinweg aktualisieren darf, verhält sich aus Sicherheitssicht wie ein privilegierter CI/CD-Dienst, nicht wie ein einfaches Entwickler-Add-on.
Mandiants drei konkrete Schutzempfehlungen
Aus dem Fall leitet Mandiant drei praktische Maßnahmen für Teams ab, die KI-Coding-Assistenten produktiv einsetzen. Erstens sollen von der KI empfohlene Drittanbieter-Abhängigkeiten künftig gegen kryptografische Prüfsummen und interne Freigabelisten geprüft werden, bevor sie installiert werden. Zweitens rät Mandiant, rohe API-Schlüssel, langlebige OAuth-Tokens und andere Geheimnisse so zu verwahren, dass Erweiterungen und Assistenten nicht direkt darauf zugreifen können. Drittens empfiehlt die Firma, den gesamten Abhängigkeitsverkehr über kontrollierte interne Repositories zu leiten, anstatt Assistenten frei aus öffentlichen Registern wie npm oder PyPI laden zu lassen.
Diese drei Punkte klingen nach klassischer Supply-Chain-Hygiene, und genau das ist die Pointe: Mandiant behandelt KI-Coding-Assistenten nicht als neue Kategorie, für die man völlig neue Regeln erfinden muss, sondern verlangt, dass bestehende DevOps- und CI/CD-Sicherheitsprinzipien konsequent auch auf sie angewendet werden. Details zur Rolle von Mandiant als Incident-Response-Einheit von Google Cloud finden sich auf der offiziellen Mandiant-Seite.
Shai-Hulud: Vom npm-Wurm 2025 zum internen SaaS-Vorfall 2026
Der Name Shai-Hulud taucht nicht zum ersten Mal auf. Bereits im September 2025 sorgte ein gleichnamiger, selbstverbreitender Wurm im npm-Ökosystem für Aufsehen. Laut Analysen von Wiz und Unit 42 von Palo Alto Networks begann die Kampagne am 14. September 2025 mit dem kompromittierten Paket “rxnt-authentication”, kurz darauf folgte das populäre Farb-Utility “@ctrl/tinycolor”. Am 16. September 2025 zählten Forscher bereits mehr als 180 betroffene Pakete, zwei Tage später waren es über 500 Pakete mit zusammen rund 600 kompromittierten Versionen über etwa 200 unterschiedliche Paketnamen hinweg.
Der Mechanismus damals: Der Wurm nutzte gestohlene npm-Tokens, meldete sich als kompromittierter Maintainer an, identifizierte dessen weitere Pakete und infizierte sie automatisch weiter. Die Ausbreitung war horizontal über das gesamte öffentliche Paketregister verteilt, weshalb praktisch jedes Unternehmen betroffen sein konnte, das eines der infizierten Pakete installierte. Der Fall aus dem September 2026 verläuft strukturell anders: Statt sich über ein öffentliches Register zu verbreiten, nistete sich Shai-Hulud über einen einzigen, gehijackten KI-Assistenten in einer einzelnen Organisation ein und breitete sich von dort aus intern über Repositories aus. Gleicher Wurm-Name, aber ein komplett neuer Verbreitungsweg über modernes Entwickler-Tooling statt über die öffentliche Registry.
| Merkmal | September 2025 (npm-Ökosystem) | September 2026 (SaaS-Unternehmen) |
|---|---|---|
| Erster Auslöser | Kompromittiertes Paket “rxnt-authentication” | Vergiftetes PyPI-Paket, von KI-Assistent empfohlen |
| Verbreitungsweg | Gestohlene npm-Tokens, automatische Neuveröffentlichung | Gekaperte Session eines KI-Coding-Assistenten |
| Umfang | 500+ Pakete, ca. 600 Versionen, ca. 200 Paketnamen | Ca. 100 interne Code-Repositories bei einem Anbieter |
| Reichweite | Global, öffentliches Register, viele Downstream-Nutzer | Intern, ein einzelner SaaS-Anbieter (Name nicht öffentlich) |
| Erste Offenlegung | 15./16. September 2025 | 16. September 2026 |
| Meldende Stelle | CISA, Wiz, Unit 42, Checkmarx | Mandiant (Google Cloud) |
Warum KI-Coding-Assistenten zum neuen Risikofaktor werden
Der Grund, warum ausgerechnet KI-Coding-Assistenten in den Fokus von Angreifern rücken, liegt in ihrer Funktionsweise. Ein moderner Assistent liest nicht nur den aktuellen Editor-Tab, sondern durchsucht ganze Repositories, schlägt Abhängigkeiten vor, öffnet Pull Requests und kann in agentischen Modi sogar eigenständig Testläufe starten und Code committen. Diese Rechte sind aus Produktivitätssicht sinnvoll, aus Sicherheitssicht aber genau das, was ein Angreifer sich wünscht: einen Zugang, der bereits über Repository-weite Berechtigungen verfügt und dem der Entwickler vertraut.
Hinzu kommt ein psychologischer Faktor. Entwickler, die täglich Vorschläge eines Assistenten übernehmen, prüfen jede einzelne Empfehlung seltener kritisch, weil das gesamte Werkzeug auf Geschwindigkeit ausgelegt ist. Genau diese Lücke nutzte der Angreifer im Mandiant-Fall aus: Die vergiftete Abhängigkeit wurde nicht durch einen technischen Trick installiert, sondern schlicht durch eine Empfehlung, die ein Mensch akzeptierte. Das OWASP-Projekt zu Sicherheitsrisiken bei LLM-Anwendungen führt unsichere Ausgabeverarbeitung und übermäßige Handlungsfreiheit von Agenten seit Jahren als zentrale Risikokategorien, der aktuelle Fall liefert dazu ein reales Beispiel aus der Praxis.
Marktauswirkungen: Vertrauen in KI-Tools unter Beobachtung
Der Zeitpunkt des Vorfalls trifft eine Branche, die gerade auf dem Höhepunkt ihrer Wachstumskurve steht. Laut einer aktuellen JetBrains-Erhebung, über die i-Programmer Mitte September 2026 berichtete, nutzen inzwischen 90 Prozent der professionellen Entwickler mindestens wöchentlich einen KI-Coding-Agenten, 68 Prozent sogar täglich. Bei einer derart hohen Durchdringung wirkt sich jede systemische Schwachstelle in diesen Werkzeugen nicht mehr nur auf einzelne Nutzer aus, sondern potenziell auf einen Großteil der professionellen Softwareentwicklung.
Für Anbieter von KI-Coding-Assistenten entsteht dadurch ein Zielkonflikt. Mehr Autonomie für den Assistenten bedeutet mehr Produktivität und ist ein zentrales Verkaufsargument im Wettbewerb zwischen GitHub Copilot, Cursor, JetBrains AI Assistant und anderen Anbietern. Gleichzeitig vergrößert jede zusätzliche Berechtigung die Angriffsfläche. Sicherheitsteams in Unternehmen, die bislang KI-Assistenten primär als Produktivitätswerkzeug beschafft haben, dürften den Vorfall zum Anlass nehmen, diese Werkzeuge künftig durch dieselbe Prüfung laufen zu lassen wie andere privilegierte Software mit Repository-Zugriff, etwa CI/CD-Runner oder Deployment-Bots.
| Kennzahl | Wert | Quelle |
|---|---|---|
| Wöchentliche Nutzung von KI-Coding-Agenten (Profi-Entwickler) | 90 % | JetBrains-Erhebung, September 2026 |
| Tägliche Nutzung von KI-Coding-Agenten | 68 % | JetBrains-Erhebung, September 2026 |
| Einsatz spezialisierter KI-Entwicklertools (Assistent/Editor/Agent) | 62 % | JetBrains-Umfrage, April 2026 |
| Kumulierte bösartige Open-Source-Pakete (Ende 2025) | über 1,233 Mio. | Sonatype State of the Software Supply Chain 2026 |
| Neue bösartige Pakete allein 2025 | 454.648 (+75 % ggü. Vorjahr) | Sonatype, 2026 |
| Anteil der OSS-Malware 2025, der über npm verbreitet wurde | ≥ 99 % | Sonatype, 2026 |
| Von Shai-Hulud kompromittierte npm-Pakete (Sept. 2025) | über 500 | CISA-Warnung, Wiz |
Wettbewerbsvergleich: Wie unterschiedlich anfällig sind die großen KI-Coding-Assistenten?
Mandiant nennt im aktuellen Fall bewusst kein konkretes Produkt, was aus Sicht der Analyse Sinn ergibt: Das zugrunde liegende Risiko ist architektonisch, nicht produktspezifisch. GitHub Copilot, Cursor, JetBrains AI Assistant, Amazon Q beziehungsweise dessen Nachfolger Kiro und andere Agenten-Plattformen teilen sich alle dasselbe Grundmuster. Sie erhalten breiten Lese- und teils Schreibzugriff auf Repositories, sie schlagen Abhängigkeiten vor, und sie laufen in vielen Fällen mit denselben Zugangsdaten wie der Entwickler selbst, der sie bedient.
Unterschiede zeigen sich vor allem darin, wie granular einzelne Anbieter Berechtigungen konfigurierbar machen und wie transparent sie protokollieren, welche Aktion ein Agent im Namen eines Nutzers ausgeführt hat. Ein Assistent, der jede Dependency-Installation und jeden Repository-Zugriff nachvollziehbar loggt, erleichtert es Sicherheitsteams, eine gekaperte Sitzung frühzeitig zu erkennen. Ein Assistent, der Aktionen im Hintergrund bündelt und nur das Endergebnis anzeigt, erschwert genau das. Für Unternehmen, die zwischen mehreren Anbietern wählen, wird die Prüfbarkeit von Agenten-Aktionen damit zu einem ebenso wichtigen Auswahlkriterium wie Modellqualität oder Preis pro Token. Auch GitHub selbst veröffentlicht regelmäßig eigene Sicherheitshinweise zu seiner Copilot-Plattform, was zeigt, dass das Thema branchenweit ernst genommen wird.
Für Einkaufsentscheidungen in größeren IT-Abteilungen bedeutet das einen Rollenwechsel für Sicherheitsteams. Bisher bewerteten sie KI-Coding-Assistenten meist anhand von Datenschutzfragen, etwa ob Quellcode zum Training externer Modelle verwendet wird. Nach dem Mandiant-Fall dürfte zusätzlich geprüft werden, wie ein Anbieter Sitzungen absichert, wie schnell ein gestohlenes Token widerrufen werden kann und ob sich verdächtige Aktivitäten eines Agenten von normaler Nutzung unterscheiden lassen. Anbieter, die dazu heute schon belastbare Antworten liefern, verschaffen sich im Vertrieb an Enterprise-Kunden einen Vorteil, der über reine Modellqualität hinausgeht.
Historischer Kontext: Von SolarWinds bis zur agentischen Software-Lieferkette
Angriffe auf die Software-Lieferkette sind kein neues Phänomen. Der SolarWinds-Vorfall 2020, Log4Shell 2021 und die wiederholten npm-Kompromittierungen seit 2022 haben gezeigt, dass Angreifer zunehmend nicht mehr das Endziel direkt attackieren, sondern die Werkzeuge und Abhängigkeiten, auf die dieses Ziel vertraut. Der aktuelle Fall setzt diese Linie fort, verschiebt den Angriffspunkt aber eine Ebene weiter nach vorne: Statt eine Bibliothek zu vergiften, die viele Unternehmen nutzen, wird das Werkzeug vergiftet, mit dem Entwickler täglich Bibliotheken auswählen und Code schreiben.
Der Sonatype-Report für 2026 unterstreicht, wie sehr sich diese Dynamik bereits vor dem aktuellen Fall beschleunigt hat: Mit über 1,233 Millionen kumulierten bösartigen Open-Source-Paketen und einem Zuwachs von 75 Prozent allein im Jahr 2025 beschreibt der Bericht laut Sonatype den Trend zu automatisierter, selbstverbreitender Malware als zentrales Merkmal der aktuellen Bedrohungslage. Shai-Hulud wird darin ausdrücklich als Beispiel für genau diese Kategorie genannt.
Interessant ist der Vergleich zur Reaktionszeit. Der npm-Vorfall 2025 wurde binnen weniger Tage öffentlich gemacht, mit einer Warnung der US-Cybersicherheitsbehörde CISA bereits am 23. September 2025, wenige Tage nach dem ersten kompromittierten Paket. Beim aktuellen Fall vergingen nach bisherigem Kenntnisstand mehrere Monate zwischen der eigentlichen Kompromittierung und der öffentlichen Aufarbeitung durch Mandiant im September 2026. Interne Vorfälle bei einzelnen Unternehmen werden generell langsamer bekannt als Angriffe auf öffentliche, für jeden einsehbare Paketregister, was aus Sicht der Verteidiger ein zusätzliches Problem darstellt: Wer nicht weiß, dass eine bestimmte Angriffstechnik bereits erfolgreich eingesetzt wurde, kann sich auch nicht gezielt davor schützen.
NIS2, Cyber Resilience Act und die Pflichten für Unternehmen in Österreich
Für Unternehmen in Österreich bekommt der Vorfall durch die parallel laufende Regulierung zusätzliches Gewicht. Mit dem NIS2-Umsetzungsgesetz müssen ab Oktober 2026 rund 5.000 heimische Betriebe strengere Nachweispflichten zur Software-Lieferkettensicherheit erfüllen, andernfalls drohen Strafen von bis zu 10 Millionen Euro. Parallel dazu verlangt der EU Cyber Resilience Act von Herstellern digitaler Produkte, Schwachstellen in ihrer Lieferkette aktiv zu managen und offenzulegen, mit Bußgeldern von bis zu 15 Millionen Euro bei Verstößen. Ein Vorfall wie der von Mandiant beschriebene, bei dem ein alltägliches Entwicklerwerkzeug zum Einfallstor wird, dürfte in Audits nach beiden Regelwerken künftig explizit abgefragt werden: Wer kontrolliert, was ein KI-Assistent in der eigenen Codebasis darf, und wie schnell würde eine missbräuchliche Nutzung auffallen?
Konkrete Schutzmaßnahmen für Entwicklerteams
Über die drei Mandiant-Empfehlungen hinaus lassen sich aus dem Vorfall praktische Schritte ableiten, die Teams unabhängig vom eingesetzten Assistenten umsetzen können. Dazu gehört, KI-Assistenten grundsätzlich mit eigenen, eingeschränkten Zugangsdaten auszustatten statt mit den vollen Rechten des jeweiligen Entwicklers, Abhängigkeits-Installationen über eine interne Paket-Spiegelung mit Freigabeprüfung laufen zu lassen und jede von einem Agenten ausgelöste Aktion in einem separaten, auswertbaren Log zu erfassen.
# Beispiel: Abhängigkeit nur nach Prüfsummen-Check aus internem Spiegel installieren
pip install --index-url https://internal-mirror.example.at/simple/ \
--require-hashes -r requirements.txt
# Beispiel: npm-Installation auf internes, geprüftes Registry beschränken
npm config set registry https://internal-npm-mirror.example.at/
npm ci --ignore-scriptsDer Parameter “–require-hashes” erzwingt, dass pip nur Pakete installiert, deren Prüfsumme vorab bekannt und freigegeben ist. Die Option “–ignore-scripts” bei npm verhindert, dass beim Installieren automatisch Skripte ausgeführt werden, genau der Mechanismus, über den sich der npm-Wurm im September 2025 selbst verbreitet hat. Keine dieser Maßnahmen ist neu oder exklusiv für KI-Assistenten gedacht, sie werden im aktuellen Kontext aber wieder relevanter, weil ein Assistent solche Installationsbefehle im Zweifel automatisiert und mit einem Klick ausführt.
Fünf Prognosen: Wohin sich Angriffe auf KI-Coding-Assistenten entwickeln
Erstens ist davon auszugehen, dass in den kommenden zwölf Monaten weitere Fälle von gekaperten Assistenten-Sitzungen öffentlich werden, schlicht weil die Nutzerbasis bei 90 Prozent wöchentlicher Nutzung längst groß genug ist, um für Angreifer attraktiv zu sein. Zweitens dürften Unternehmen beginnen, KI-Assistenten in ihr bestehendes Identity-and-Access-Management einzubinden, mit eigenen Rollen und zeitlich begrenzten Tokens statt dauerhafter Vollzugriffe. Drittens wird der regulatorische Druck durch NIS2 und den Cyber Resilience Act voraussichtlich dazu führen, dass Anbieter wie GitHub, Cursor oder JetBrains detailliertere Sicherheits-Whitepaper zu ihren Agenten-Architekturen veröffentlichen, um Enterprise-Kunden die Auditierung zu erleichtern.
Viertens rechnen wir mit einer Zunahme interner Paketregister und automatisierter Prüfsummen-Kontrollen als Standardkonfiguration in größeren Entwicklungsorganisationen, ähnlich wie sich Zwei-Faktor-Authentifizierung in den letzten Jahren vom Sonderfall zur Grundausstattung entwickelt hat. Fünftens ist plausibel, dass Sicherheitsforscher künftig gezielter nach Schwachstellen in den Session-Management-Mechanismen von KI-Coding-Assistenten suchen werden, da der Mandiant-Fall gezeigt hat, dass sich dort mit vergleichsweise geringem Aufwand ein hoher Wirkungsgrad erzielen lässt.
Was Sicherheitsverantwortliche jetzt konkret prüfen sollten
Für IT-Sicherheitsverantwortliche in österreichischen Unternehmen lohnt sich eine kurze, aber ehrliche Bestandsaufnahme. Welche KI-Coding-Assistenten sind im Unternehmen überhaupt im Einsatz, auch außerhalb offizieller Beschaffung? Mit welchen Zugangsdaten laufen diese Assistenten, und ließe sich eine missbräuchliche Sitzung anhand vorhandener Logs überhaupt erkennen? Werden von der KI vorgeschlagene Abhängigkeiten automatisch installiert oder durchläuft jede neue Bibliothek eine Freigabe, und sei sie noch so kurz? Wer diese drei Fragen aktuell nicht klar beantworten kann, hat nach dem Mandiant-Fall eine konkrete, priorisierbare Aufgabe für die kommenden Wochen.
Häufig gestellte Fragen
Was ist bei dem Mandiant-Vorfall vom September 2026 genau passiert?
Ein Angreifer übernahm die aktive Sitzung eines KI-Coding-Assistenten bei einem nicht namentlich genannten SaaS-Anbieter und verbreitete darüber die Schadsoftware Shai-Hulud in rund 100 interne Code-Repositories. Ausgangspunkt war ein von der KI empfohlenes, vergiftetes PyPI-Paket.
Ist Shai-Hulud dieselbe Malware wie beim npm-Vorfall 2025?
Es handelt sich um denselben Malware-Namen und ein ähnliches Wurm-Prinzip, aber um einen anderen Verbreitungsweg. 2025 verbreitete sich Shai-Hulud über gestohlene npm-Tokens im gesamten öffentlichen Paketregister. 2026 verbreitete er sich innerhalb einer einzelnen Organisation über einen gekaperten KI-Assistenten.
Welches Unternehmen und welcher KI-Assistent waren betroffen?
Mandiant hat weder das betroffene SaaS-Unternehmen noch den konkreten KI-Coding-Assistenten öffentlich benannt. Die Firma beschreibt das Risiko bewusst als architektonisch und nicht als Problem eines einzelnen Anbieters.
Welche drei Maßnahmen empfiehlt Mandiant konkret?
Erstens sollen von der KI vorgeschlagene Abhängigkeiten gegen Prüfsummen und Freigabelisten geprüft werden. Zweitens sollen API-Schlüssel und OAuth-Tokens vor direktem Zugriff durch Erweiterungen geschützt werden. Drittens soll der Abhängigkeitsverkehr über kontrollierte interne Repositories laufen.
Wie viele Entwickler nutzen aktuell überhaupt KI-Coding-Assistenten?
Laut einer JetBrains-Erhebung von September 2026 nutzen 90 Prozent der professionellen Entwickler mindestens wöchentlich einen KI-Coding-Agenten, 68 Prozent täglich.
Betrifft das Risiko nur GitHub Copilot oder auch andere Anbieter wie Cursor und JetBrains AI Assistant?
Das Risiko ist laut Mandiant grundsätzlicher Natur und betrifft alle KI-Coding-Assistenten mit breitem Repository-Zugriff, unabhängig vom konkreten Anbieter. Unterschiede bestehen vor allem in der Granularität der Rechtevergabe und der Nachvollziehbarkeit von Agenten-Aktionen.
Welche rechtlichen Pflichten ergeben sich für Unternehmen in Österreich?
Ab Oktober 2026 gelten für rund 5.000 österreichische Unternehmen verschärfte Pflichten nach dem NIS2-Umsetzungsgesetz, mit möglichen Strafen von bis zu 10 Millionen Euro. Der EU Cyber Resilience Act verlangt zusätzlich ein aktives Schwachstellenmanagement in der Software-Lieferkette, mit Bußgeldern von bis zu 15 Millionen Euro.
Wie kann ich als Entwickler mein Risiko kurzfristig senken?
Sinnvoll sind eigene, eingeschränkte Zugangsdaten für KI-Assistenten, eine interne Paket-Spiegelung mit Prüfsummen-Kontrolle sowie die Deaktivierung automatischer Installationsskripte bei npm- und pip-Installationen, etwa über die Optionen “–ignore-scripts” beziehungsweise “–require-hashes”.
