Was der Shai-Hulud-npm-Wurm für dsh-Nutzer bedeutet

Was passiert ist

Laut der Analyse von Wiz veröffentlichte der Angreifer über eine kompromittierte Maintainer-Identität bösartige Versionen von keyv und verbreitete sich dann über legitime GitHub-Actions-Workflows in mehr als 400 Pakete, die zusammen rund zwei Milliarden Downloads pro Monat verzeichnen.

Die Welle, die Agenten-Nutzer beunruhigen sollte, ist die sechste. Ihre Payload versteckte sich in Konfigurationsdateien von KI-Agenten — Dateien, die kein herkömmlicher Scanner liest. Command-and-Control lief über einen Ethereum-Smart-Contract statt über eine Domain, die man beschlagnahmen könnte. Und sie brachte einen Wächter mit, der in dem Moment Angreifer-Code zündete, in dem Verteidiger versuchten, die gestohlenen Zugangsdaten zu rotieren.

Warum das dsh betrifft

Ein dsh-Plugin ist ein npm-Paket plus ein Eintrag in der cordis.yml. Bei der Installation läuft die gesamte npm-Maschinerie — Installationsskripte, transitive Abhängigkeiten, alles, was das Lockfile nicht gepinnt hat — und das Ergebnis wird in den Prozess geladen, der deine API-Schlüssel hält und deine Shell ausführt. Jeder Mechanismus, den Shai-Hulud nutzte, existiert in diesem Ökosystem unverändert.

Das Detail, das man sich merken sollte: Die Payload lebte in Agenten-Konfigurationsdateien. In dsh ist die Loader-Konfiguration die Angriffsfläche — die cordis.yml entscheidet, welcher Code in den Prozess gelangt. Eine Datei, die die meisten aus einem README kopieren, ohne sie zu lesen, ist genau der Ort, an dem sich diese Klasse von Angriffen versteckt.

Hat es ein dsh-Plugin erwischt?

Nicht, dass es jemand nachgewiesen hätte. Zum Zeitpunkt der Veröffentlichung (18. August 2026) kennen wir kein bestätigtes bösartiges Paket unter den 1805 Repositories, die wir indexieren. Aber das Topic ist ein offenes Tag ohne Prüfung dahinter, das Ökosystem ist Tage alt, und der npm-Angriff oben lief bereits zwei Wochen vor dem dsh-Launch. Das Fehlen eines bestätigten Falls so früh ist kein Beleg für Sicherheit.

Trägt ein Eintrag ein nachprüfbares Warnzeichen — einen Namen, der eine Änderung von einem beliebteren Repository entfernt ist, eine Homepage hinter einem Link-Kürzer, eine Beschreibung, die einen Download in eine Shell leitet —, drucken wir diesen Fakt auf die Eintragsseite. Urteile drucken wir nicht; Repository-Metadaten können sie nicht tragen.

Was konkret zu tun ist

Pinne die exakten Versionen, die du geprüft hast, committe dein Lockfile und halte Produktionszugangsdaten aus der Umgebung heraus, in der du neue Plugins ausprobierst. Bevor etwas in die cordis.yml wandert, geh die vollständige Prüf-Checkliste durch. Findest du etwas Bösartiges in einem von uns indexierten Repository, melde es — bestätigte Fälle nehmen wir aus dem Verzeichnis.