Zwei bösartige npm-Kampagnen wurden innerhalb von drei Wochen bekannt. Wer die Überschriften liest, bekommt eine Botschaft: npm-Pakete sind gefährlich. Wer die Berichte liest, findet sie genau an dem Punkt verschieden, der darüber entscheidet, ob ein Entwickler überhaupt die Gelegenheit bekommt, sie zu stoppen.
Fall eins: der Wurm, der Ihr Vertrauen braucht
Ein Wurm, der Zugangsdaten stiehlt, tauchte zuerst in keyv@6.0.0 auf und breitete sich am 4. August 2026 über die Namensräume Keyv und Cacheable hinaus auf Hunderte Pakete aus.
Die bösartige Version fügte node setup.mjs als preinstall-Befehl hinzu und ließ den kompilierten Bibliothekscode unangetastet. Die erste Stufe prüft, ob die Bun-Laufzeitumgebung vorhanden ist, lädt sie bei Bedarf nach und übergibt an ein kompiliertes Bundle von 727.680 Byte. Laut der Analyse von SafeDep sammelt dieses Bundle Material von GitHub, npm, Cloud-Diensten, Vault, Kubernetes, Datenbanken und private Schlüssel ein, liest den Speicher des GitHub-Actions-Runners aus und bringt eigene npm-Veröffentlichungsmechanik mit, worüber es sich weiterverbreitet.
Im Repository blieben zusätzlich getrennte Hooks für Claude Code und Visual Studio Code liegen. Sie sind wichtig, und ebenso wichtig ist die Einschränkung, die der Bericht ihnen mitgibt: Sie „können die Nutzlast ausführen, sobald ein Nutzer dem Arbeitsbereich vertraut oder die Projektkonfiguration zulässt“.
Es gibt ein Tor. Jemand muss hindurchgehen.
Fall zwei: der, der nicht fragt
Am 21. August meldete TrendAI vierzehn trojanisierte npm-Pakete, die sich als Kalender- und Streak-Werkzeuge ausgeben. Sie funktionieren: Die versprochene Funktion ist da, und genau deshalb bleiben sie installiert.
Darunter arbeitet die Einstiegsdatei als Lader für eine Linux-Hintertür, getarnt als nativer Mathematikbeschleuniger. Der Dateiname wechselt von Paket zu Paket (math-core.bin, calc-math.dat, calc-cache.bin und weitere), der Inhalt ist jedes Mal dieselbe Bake.
Am Mechanismus trennt sich dieser Fall vom ersten. In den Worten der Forscher: „Wenn das Modul geladen wird, findet es die mitgelieferte Binärdatei, markiert sie als ausführbar und startet sie als abgekoppelten Hintergrundprozess. Es ist kein Aufruf einer Installations-Hook-Funktion nötig; ein einziger Import irgendwo im Abhängigkeitsgraphen, auch ein transitiver, genügt, um die Nutzlast auszuführen.“
Kein Installations-Hook. Keine Vertrauensabfrage. Keine exportierte Funktion, die jemand aufrufen muss. Ein Import drei Ebenen tiefer, in einer Abhängigkeit, die Sie nie gewählt haben, reicht aus.
Warum der Unterschied die Nachricht ist
Beides sind Angriffe auf die npm-Lieferkette. Sie in eine gemeinsame Warnung zu packen, verliert den einzigen Teil, der das eigene Handeln ändert.
Fall eins wird durch eine menschliche Entscheidung gebremst. npm 12 blockiert Lifecycle-Skripte nicht freigegebener Abhängigkeiten standardmäßig, und die Editor-Hooks brauchen jemanden, der dem Arbeitsbereich vertraut. Ältere npm-Clients und andere Installationswege, die Lifecycle-Skripte zulassen, bleiben offen. Der Schutz ist real und zugleich an Bedingungen geknüpft.
Fall zwei hat diesen Schritt nicht. Die Nutzlast läuft beim Import, und damit zählen die Verteidigungen, die nicht davon abhängen, dass jemand etwas bemerkt: feste Abhängigkeitsversionen, Disziplin beim Lockfile, und zu wissen, was tatsächlich im eigenen Baum steckt.
Wer hier mit „bei npm-Paketen vorsichtig sein“ herausgeht, hat die Hälfte übersprungen, die sagt, wo der Aufwand hingehört.
Die Größenangaben widersprechen sich, und der Bericht sagt das
Hier wird die Geschichte falsch zitiert, deshalb das vollständige Bild.
SafeDep bestätigte 353 vergiftete Versionen über 79 Paketnamen. Die eigene Überwachung setzte den weiteren Umfang auf 442 Versionen über 353 Namen. Aikido meldete später mindestens 868 Pakete in 1.381 Versionen.
Drei Zählungen, drei Quellen, und der Bericht sagt ausdrücklich: „Keiner der beiden größeren Gesamtwerte war zum Redaktionsschluss aus einer vollständigen öffentlichen Liste unabhängig nachvollziehbar.“
Er fügt eine zweite Einschränkung an, die schwerer wiegt als die Spannweite: Diese Summen „zählen bösartige Paket-Artefakte, keine betroffenen Systeme. Sie belegen den Umfang der Kampagne, zeigen aber nicht, wie viele Maschinen die Nutzlast installiert oder ausgeführt haben.“
Wenn Ihnen also eine einzelne, selbstsichere Zahl zu dieser Kampagne begegnet, stammt sie aus einem Satz von dreien, die sich widersprechen, und sie zählt in jedem Fall Pakete statt Infektionen.
Der Aufräumschritt gegen den Instinkt
Das ist der nützlichste Satz aus beiden Berichten, und er wird leicht überlesen.
Die Nutzlast installiert einen Wächter für den Widerruf von Zugangsdaten. SafeDep rät, diesen Wächter zu entfernen, bevor offengelegte Token und Schlüssel rotiert werden, denn der Widerruf ist es, was ihn auslöst: Wer zuerst rotiert, kann einen vom Angreifer hinterlegten lokalen Handler starten.
Die instinktive Reaktion auf gestohlene Zugangsdaten ist, sofort alles zu rotieren. Hier löst dieser Instinkt die Falle aus.
Die Einschätzung von Socket, wen es betrifft, ist weit gefasst: „Jede Arbeitsstation und jeder Runner, der eine betroffene Version ausgeführt hat, sollte als kompromittiert hinsichtlich der Zugangsdaten behandelt werden.“
Warum eine Paketliste Sie nicht rettet
Der Bericht hält fest, dass sich das Registry zu schnell änderte, um eine feste kampagnenweite Liste zu tragen. Stunden nach den ersten Funden waren bei mindestens neun Paketen aus SafeDeps Anfangsmenge frühere Versionen wieder als latest gesetzt.
Die praktische Folge: Prüfungen auf Betroffenheit müssen exakte Paketnamen, aufgelöste Versionen und Lockfiles verwenden, keine gespeicherte Liste aktueller Tags. Eine Sperrliste auf Namensraum-Ebene läuft doppelt Gefahr, vergiftete Versionen zu übersehen und Versionen zu markieren, die nie betroffen waren.
Die Form ist bekannt. Eine Liste, die maßgeblich aussieht, beim Lesen schon veraltet ist und in beide Richtungen selbstsichere Antworten liefert.
Was daraus mitzunehmen ist
Finden Sie heraus, ob Ihre Installationswege Lifecycle-Skripte ausführen. Wenn Sie auf einer npm-Version arbeiten, die sie standardmäßig blockiert, hat Fall eins ein Tor davor. Wenn nicht, hat er keines.
Machen Sie sich klar, wie weit ein transitiver Import reicht. Fall zwei braucht nichts weiter als ein geladenes Modul irgendwo im Graphen, und damit wird Abhängigkeitstiefe zu einer Sicherheitseigenschaft statt zu einer Frage der Ordnung.
Und falls Sie je auf einen Vorfall mit gestohlenen Zugangsdaten reagieren: Lesen Sie die Reihenfolge der Gegenmaßnahmen, bevor Sie rotieren. Diesmal war der naheliegende erste Schritt genau der, der die Nutzlast auslöst.
Quellen
- The Hacker News, “Keyv-Linked npm Worm Poisons Hundreds of Packages, Plants Claude Code and VS Code Hooks”, 4. August 2026: https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html (abgerufen am 26. August 2026). Quelle des Ursprungs in keyv@6.0.0, des preinstall-Mechanismus und der Nutzlastgröße, des eingesammelten Materials, der drei widersprüchlichen Umfangszahlen samt der Einschränkungen, die der Bericht selbst dazu macht, der Einschränkung zu den Editor-Hooks, der Reihenfolge beim Widerrufs-Wächter, der Einschätzung von Socket und des Hinweises auf die wechselnden Registry-Tags.
- The Hacker News, “14 Trojanized npm Packages Drop RedC2 4.0 Linux Backdoor With AI-Assisted C2”, 21. August 2026: https://thehackernews.com/2026/08/14-trojanized-npm-packages-drop-redc2.html (abgerufen am 26. August 2026). Quelle der vierzehn Pakete, des Lader-Mechanismus, der wechselnden Binärdateinamen und der Zuordnung der Nutzlast zur RedShell-Linux-Bake.
- Beide Berichte existieren nur auf Englisch: Die Zitate in diesem Artikel sind eigene Übersetzung des Originals, keine wörtlichen deutschen Zitate.
