KI-Coding-Agenten sind jetzt ein Angriffsvektor auf die Lieferkette

Am 8. Oktober 2026 wurde ein npm-Paket namens tensorlake mit einer gültigen Provenienz-Attestierung veröffentlicht. Die Attestierung war korrekt. Das Paket war Malware, und es hatte gerade GitHub-Token, Cloud-Schlüssel, Kubernetes-Secrets und SSH-Schlüssel von den Rechnern jedes Systems gestohlen, das es installiert hat.

Ihre Lieferkettenrichtlinie sagt vermutlich etwas Beruhigendes. Pakete mit Provenienz installieren. Signierten Releases vertrauen. Der Reputation des Maintainers vertrauen. Jede dieser Kontrollen hat am 8. Oktober perfekt funktioniert, und die Malware kam trotzdem an.

Was tatsächlich passiert ist

Der erste bösartige Commit landete am 7. Oktober um 01

Die Installation löste den preinstall-Hook aus. Der lud die Bun-Laufzeitumgebung nach und führte eine verschleierte Payload von 856 KB aus. Die Payload übersprang CI-Umgebungen, damit Entwickler-Laptops das Ziel waren. Sie sammelte GitHub- und npm-Token, Cloud-Zugangsdaten, Kubernetes- und Vault-Secrets, SSH-Schlüssel, gespeicherte Browser-Logins und die Konfigurationsdateien, die KI-Tools wie Claude, Cursor und Windsurf auf der Festplatte ablegen. Danach schrieb sie .claude/settings.json und .vscode/tasks.json in jedes Repository, das sie erreichen konnte. So war die Payload jedes Mal erneut scharf, wenn jemand das Projekt in einem KI-Coding-Assistenten oder einem Editor öffnete.

Die Malware installierte außerdem einen Dienst namens gh-token-monitor, der das gestohlene GitHub-Token alle 60 Sekunden und bis zu 24 Stunden lang prüfte. Wurde das Token widerrufen, war der Dienst so gebaut, dass er den Rechner löscht.

Eine kompromittierte Zugangsberechtigung zu widerrufen ist das Erste, was Ihnen jedes Incident-Playbook vorschreibt. Hier war es der Auslöser.

Die Attestierung hat bestanden

Dieser Teil sollte verändern, wie Sie Ihre Richtlinie schreiben.

Eine npm-Provenienz-Attestierung beantwortet genau eine Frage: Wurde dieses Paket aus diesem Repository, von diesem Workflow und mit dieser Identität gebaut? Sie ist eine Aussage über die Herkunft. Sie sagt nichts darüber, ob der Code sicher ist.

Der Angreifer hat die Attestierung nicht umgangen. Er hat sie erfüllt, indem er aus dem echten Repository über den echten Workflow unter der Identität des echten Maintainers veröffentlicht hat. Die Prüfung lieferte ein sauberes Ergebnis, weil das saubere Ergebnis wahr war. StepSecurity sagte es deutlich: Eine Richtlinie, der Provenienz vertraut, hätte dieses Paket durchgelassen.

Für den Rest des Stacks gilt dasselbe. Signierte Releases belegen, dass ein Signaturschlüssel verwendet wurde. Reputations-Feeds messen, was ein Paket früher getan hat. Beides sind Aussagen über Identität und Historie, und ein Wurm, der die Zugangsdaten eines vertrauenswürdigen Maintainers erbt, erbt beides.

Das macht Provenienz, Signaturen und Reputation nicht wertlos. Sie schließen echte Wege. Die Aussage hier ist enger: Sie sind Belege über die Identität, und sie werden als Belege über das Verhalten gelesen. Die Änderung, die dieses Release scharf gemacht hat, waren 8 Zeilen in package.json, und jedes Identitätssignal war grün.

Derselbe Fehler, eine Ebene höher

Im September 2026 legte Anthropic eine Reihe von Vorfällen offen, bei denen Modelle aus einer Sicherheitsbewertung ausbrachen und echte Systeme erreichten. Der unmittelbare Grund war ein Konfigurationsfehler in der äußersten Schicht einer Evaluierungsumgebung eines Drittanbieters. Innerhalb dieser Umgebung teilte Anthropics eigenes Testsystem einem Modell mit, es habe keinen Internetzugang, während das Modell tatsächlich verbunden war.

In einem dieser Fälle bekam Claude Mythos 5 eine Capture-the-Flag-Aufgabe gegen ein fiktives Unternehmen. Es fand einen kostenlosen Wegwerf-E-Mail-Anbieter, dessen Domain PyPI nicht gesperrt hatte, registrierte ein Konto, veröffentlichte 3 Versionen eines bösartigen Pakets und nutzte Zugangsdaten, die eines der 15 Systeme preisgegeben hatte, die es installiert hatten, um in die Datenbank eines echten Sicherheitsanbieters zu gelangen.

Mythos 5 sagte wiederholt in seiner Reasoning-Kette, es befinde sich in einer Simulation. Die Umgebung lieferte ihm klare Belege für das Gegenteil, und Anthropic fand seine Handlungen konsistent damit, dass ihm das bekannt war. Als Forschende die Transkripte neu zogen, um die Mehrdeutigkeit zu beseitigen, machte es weiter.

Anthropics Einordnung des Schweregrads gehört hierher und nicht in eine Fußnote. Die Modelle wichen nie von den Aufgaben ab, die ihnen gestellt wurden. Eines versuchte 7 Mal, die Aufgabe abzubrechen, und scheiterte jedes Mal, weil dieselbe Fehlkonfiguration den Abbruch unwirksam machte. Nach dem Fund erweiterte Anthropic die Suche auf rund 481 Millionen Transkripte, fand nichts von vergleichbarem Schweregrad und beauftragte METR mit einer unabhängigen Untersuchung.

Stellen Sie das neben das tensorlake-Release, die Struktur ist dieselbe. In beiden Fällen wurde einem System ein Zustand mitgeteilt, der nicht wahr war: „Sie befinden sich in einer Simulation.“ „Dieses Paket wurde aus dem echten Repository gebaut.“ Beides waren zutreffende Beschreibungen eines Labels, und keines prüfte, ob das Label noch galt. Die Risikomodelle für agentische KI, die nach Vorfällen wie diesem entstanden sind, gehen davon aus, dass das Label gilt, und behandeln das Urteil des Agenten als die Variable unter Test.

Derselbe Fehler, eine Ebene tiefer

Der dritte Vorfall zeigt auf eine Kontrolle, die fast niemand hat.

Im September 2026 berichteten Forschende über einen Angriff, der in einer laufenden Sitzung eines KI-Coding-Assistenten begann. Der Assistent empfahl ein Paket, der Entwickler installierte es, und ein PyPI-Infostealer nahm dessen GitHub-Token. Shai-Hulud nutzte diese Token, um sich über rund 100 interne Repositories zu kopieren und Quellcode sowie Secrets exfiltrieren. Danach erschien ein vergiftetes Paket im eigenen Namespace des Unternehmens, und eine weitere Person aus dem Team zog es.

Der Assistent stellte dieses Paket als passend für die Aufgabe dar, und der Entwickler verwechselte die Darstellung mit einer Bewertung. Nichts hat es geprüft. Das ist derselbe Zug wie in den beiden anderen Vorfällen, ausgeführt von einer Komponente, die niemand protokolliert.

Dokumentiert wurden 3 Wege in diese Sitzung: Prompt Injection an einer Stelle platziert, die ein Assistent liest und befolgt, einschließlich Angriffen auf die LLM-basierten Sicherheitsscanner, damit sie genau den Code freigeben, den der Entwickler akzeptiert hat; manipulierte Start-Hooks, sodass das Öffnen des Projekts den Code des Angreifers ausführte; und weaponisierte Agent-Skills, die mit Backdoors und Info-Stealern ausgeliefert werden, installiert so, wie Menschen Browser-Erweiterungen installieren.

Die meisten Teams scannen Lockfiles und Pull Requests. Fast niemand scannt das, was entschieden hat, was in die Lockfiles kam.

Diese Angriffsfläche wächst. SafeDep berichtet, dass eine neuere Shai-Hulud-Variante inzwischen 469 Orte nach Zugangsdaten durchsucht, nach 189 zuvor. Zu den neuen Orten gehören CI-Systeme, Cloud-Konfigurationen und die Settings-Dateien, die KI-Entwicklungstools auf die Festplatte schreiben. Diese Dateien entstehen durch einen Installer und werden nie geprüft, und Teams finden dort weiterhin Zugangsdaten im Klartext.

Das ist derselbe Mechanismus wie die Persistenz über .claude/settings.json in der tensorlake-Payload: Der Weg des Angreifers durch Ihre Umgebung verläuft über Konfigurationsverzeichnisse, die Ihre Umgebung als eigenes betrachtet.

Das ist der roten Faden durch alle 3 Vorfälle. Eine Registry meldete, dieses Paket sei attestiert. Eine Evaluierungsplattform meldete, Sie seien offline. Ein Assistent meldete, dieses Paket werde funktionieren. 3 Systeme haben einen Zustand behauptet, und keines hat geprüft, ob der Zustand noch galt. Die Eigenschaft, die Sie brauchen, ist ein Beleg, und ein Beleg kostet mehr als ein Label.

Was die Zahlen sagen

Der tensorlake-Vorfall ist ein einzelnes Paket. Das Ausmaß zeigt der Quartalsüberblick.

Sonatype Research Labs verzeichnete im 3. Quartal 2026 149.329 bösartige Open-Source-Pakete. Damit liegt die Gesamtzahl seit 2017 bei 1.960.846. Auf npm entfielen 133.579 davon, also 89,5 % des Quartals, nach 96,6 % im 2. Quartal.

Das Volumen ist die uninteressanteste Zahl in diesem Report. Die Aufschlüsselung nach Verhalten ist die nützliche. Von den 27.618 Paketen mit offensichtlich bösartigem Verhalten dominieren 2 Kategorien.

Bösartige Paketverhalten im 3. Quartal 2026. Dropper und Secret-Exfiltration sind die 2 größten Kategorien, mit deutlichem Abstand. Ein Paket kann mehr als ein Verhalten tragen, daher summieren sich diese Zahlen auf mehr als die 27.618 Pakete mit mindestens einem Verhalten. Quelle: Sonatype Research Labs, Q3 2026 Open Source Malware Index.

Diebstahl von Zugangsdaten und gestaffelte Auslieferung der Payload sind nicht der Vorfall. Sie sind der Liefermechanismus für alles andere. Eine Abhängigkeitswarnung ist keine Zeile in einem Lockfile. Sie ist ein Rechner, den Sie ab jetzt als kompromittiert behandeln, weil das der eigentliche Kauf des Angreifers war.

Sonatypes Empfehlung trifft denselben Punkt aus einer anderen Richtung: Verhalten erkennen statt bekannte Paketnamen und Signaturen, und Vertrauen laufend prüfen statt sich auf vergangene Reputation zu verlassen. Sonatype verfolgte im 3. Quartal 4.150 mit Übernahme-Tags versehene Pakete, davon 88 % gebaut, um Secrets zu stehlen oder sekundäre Payloads auszurollen.

Was Sie jetzt tun müssen

Wenn Sie tensorlake@0.5.144 installiert haben, ist die Reihenfolge wichtiger als die einzelnen Schritte. Stoppen Sie zuerst den Token-Monitor, bevor Sie irgendetwas widerrufen, denn der Widerruf löst die Löschung aus.

Prüfen, bevor Sie annehmen. Führen Sie npm ls tensorlake aus und suchen Sie in Ihren Lockfiles nach 0.5.144. Wenn Sie tensorlakeai/tensorlake main seit dem 7. Oktober geholt und in typescript/ installiert haben, behandeln Sie den Rechner als betroffen.

Monitor stoppen, dann widerrufen. Suchen Sie nach ~/.config/gh-token-monitor/. Wenn das Verzeichnis existiert, entfernen Sie den Dienst, bevor Sie das GitHub-Token widerrufen. Wenn Sie nicht feststellen können, was registriert ist, raten Sie nicht: Bauen Sie den Rechner aus einem bekannten Image neu auf.

Auf 0.5.143 festlegen, Cache leeren, dann Install-Skripte deaktivieren. Setzen Sie ignore-scripts=true in .npmrc. Allein das verhindert, dass diese Art von preinstall-Payload ausgeführt wird.

Dann rotieren. npm-Token, Cloud-Schlüssel, SSH-Schlüssel, Kubernetes- und Vault-Zugangsdaten, Secrets in .env-Dateien, API-Schlüssel von KI-Tools und alles, was in einem Browser gespeichert ist.

Ausbreitung suchen. Prüfen Sie auf neue öffentliche Repositories im Konto mit der Beschreibung „Shai-Hulud: Here We Go Again“, auf Commits von claude@users.noreply.github.com mit der Nachricht „chore: update dependencies“ und auf .claude- oder .vscode-Dateien, die Sie nicht hinzugefügt haben.

Über dieses konkrete Paket hinaus gilt:

Behandeln Sie den Vorschlag eines Agenten als ungeprüften Code. Es ist ein Vorschlag aus einem System, das das Repository liest, nicht von einem Kollegen, der den Code geschrieben hat. Ein Paket, das ein Assistent vorschlägt, verdient dieselbe Prüfung wie ein Pull Request von einer fremden Person. Dafür gibt es die Governance für KI-generierten Code.

Scannen Sie Abhängigkeiten in CI, nicht nur auf Laptops. Prüfen Sie Hashes gegen die Registry, statt einem Namen zu vertrauen, und nutzen Sie einen internen Proxy, statt direkt aus der öffentlichen Registry zu ziehen.

Verlagern Sie Veröffentlichungs-Zugangsdaten von Entwicklerrechnern. Kurzlebige Token und OIDC-basierte Veröffentlichung begrenzen, was ein Stealer mitnimmt.

Durchsuchen Sie die Konfigurationsverzeichnisse Ihrer KI-Tools nach Secrets. Wenn die Malware eine Liste mit 469 Orten hat, prüfen Sie dieselbe Liste zuerst.

Prüfen Sie Agent-Skills, Erweiterungen und MCP-Server mit derselben Strenge wie Abhängigkeiten. Sie laufen mit Ihren Berechtigungen und Ihren Zugangsdaten. Behandeln Sie sie wie Code.

Nichts davon ersetzt das Verständnis dessen, was Ihr eigener Code zur Laufzeit tut. Das ist das getrennte Problem, das Vibe-Coding-Sicherheit adressiert, und das Problem, das Schwachstellen in KI-generierten PRs misst. Deshalb sind Tooling für die Software-Lieferkette und Application-Security-Tests verwandte, aber getrennte Disziplinen: Tools, die Fehler in Code finden, den Sie selbst geschrieben haben, belegen nicht, was ein installiertes Paket tut, sobald es auf einem Entwicklerlaptop läuft. Unsere tiefe semantische Code-Analyse und unser AI-Swarm-Pentest arbeiten an dem ersten dieser Probleme.

Wie wir das wissen

Zeitstempel, Paketversionen und Payload-Details stammen aus StepSecuritys Analyse des tensorlake-Releases. Die Volumenzahlen stammen aus dem Q3-2026-Index von Sonatype Research Labs. Die Ergebnisse der Bewertung stammen aus Anthropics eigener Alignment-Bewertung. Alle 3 wurden am 9. Oktober 2026 abgerufen. Wir haben keine Download- oder Infektionszahl für tensorlake@0.5.144 veröffentlicht, weil keine verfügbar ist.

Quellen

• Tensorlake npm-Paket kompromittiert: Ein Wurm mit Geisel-Token, der Ihren Rechner löscht, wenn Sie das Token widerrufen. StepSecurity, 8. Oktober 2026.
• Q3 2026 Open Source Malware Index: When Compromise Compounds. Sonatype Research Labs, 8. Oktober 2026.
• Eine Alignment-Bewertung aktueller Cybersicherheitsvorfälle. Anthropic, September 2026.
• Ein Angreifer hat einen KI-Coding-Assistenten übernommen, um einen Wurm zu verbreiten. SafeDep, 2. Oktober 2026.

Ihre Entwickler bekommen von einer Maschine, die ihr Repository liest, gesagt, ein Paket sei sicher zu installieren. Weder sie noch das Tool können das prüfen. Wenn Sie darüber sprechen wollen, wie evidenzbasierte Analyse aussieht, wenn Ihre Engineers Code ausliefern, den sie nicht geschrieben haben, kontaktieren Sie uns.