npm-Schadcode startet erst zur Laufzeit und umgeht damit die Install-Skript-Sperre

Wer seine Lieferkettensicherheit für Node.js darauf stützt, dass npm seit Version 12 keine Installationsskripte von Abhängigkeiten mehr ausführt, hat ab sofort eine belegte Lücke. Eine laufende Schadcode-Kampagne rund um das npm-Paket indexed-btree verzichtet vollständig auf preinstall, install und postinstall. Der Loader sitzt stattdessen in einer ganz normalen Funktion der Bibliothek und läuft erst, wenn die eigene Anwendung diese Funktion aufruft. Die Installation sieht dabei sauber aus und löst keinen der Freigabemechanismen von npm v12 aus.

Betroffen sind Node.js-Projekte, Build-Pipelines und Entwicklerrechner, in denen indexed-btree oder eines von neun weiteren Paketen derselben Operation direkt oder als transitive Abhängigkeit steckt. Nicht betroffen sind Umgebungen ohne Node.js und Projekte, in denen keines der zehn Paketnamen in Projekt- oder Lockfile auftaucht. Heute zu tun ist eine Inventarprüfung: alle Projekte und Lockfiles nach den unten genannten Paketnamen durchsuchen. Ein Treffer bedeutet Vorfallsbehandlung mit Rotation aller Geheimnisse, kein Treffer bedeutet kein akuter Handlungsdruck.

Was ist passiert?

Das Sicherheitsunternehmen Checkmarx hat eine laufende npm-Kampagne analysiert, über die BleepingComputer am 20. September 2026 berichtet hat. Im Zentrum steht das Paket indexed-btree, das sich als die legitime Bibliothek sorted-btree ausgibt, also als gewöhnliches B-Baum- und Indexierungswerkzeug. Das Paket erreichte laut Checkmarx knapp 2 Millionen wöchentliche Downloads.

Neu und redaktionell entscheidend an diesem Fall ist der Auslöser. Bisherige npm-Angriffe dieser Art setzten fast immer auf Lifecycle-Skripte, die beim Installieren automatisch starteten. Genau dieser Weg ist seit npm v12 standardmäßig zu. Die Angreifer haben deshalb den Startpunkt verschoben: In der package.json von indexed-btree steht kein Install-Hook. Der Loader steckt in der Methode BTree.prototype.set(), also in der zentralen Schreibfunktion, die jeder Nutzer der Bibliothek ständig aufruft. Sie feuert erst zur Laufzeit, und zwar wenn die Anwendung sie mit einem bestimmten Schlüsselwert aufruft.

Checkmarx beschreibt das als gut gebauten Weg, an gängiger Taint-Analyse und an den meisten statischen Scannern vorbeizukommen. Ausgelöst wird dabei sharedLoad.min.js, das die verschleierte erste Stufe der Schadsoftware enthält. Nach der Ausführung sammelt der Code Systemdetails wie Architektur, Hostname, CPU, Arbeitsspeicher und Laufzeit und schleust sie über fest eingebaute Slack- und Telegram-Kanäle aus.

Für die Steuerung nutzt die Kampagne keinen klassischen Server, sondern fragt einen Ethereum-Smart-Contract im Sepolia-Testnetz nach Command-and-Control-Informationen ab. Über einen X25519-Schlüsselaustausch leitet sie einen AES-Schlüssel ab und entschlüsselt damit eine zweite Stufe, die im Contract hinterlegt ist. Wollen die Betreiber den Angriff beenden, kann die Schadsoftware ihre eigenen Dateien löschen und den bösartigen Auslöser aus dem Paketcode entfernen, um Spuren zu verwischen.

Die Angreifer haben zusätzlich viel Aufwand in Glaubwürdigkeit gesteckt: ein legitim wirkendes GitHub-Repository, eine gefälschte Commit-Historie und ein sorgfältig gepflegtes Entwicklerkonto. Checkmarx nennt außerdem eine Wallet mit 109 ETH, die der Operation zugeordnet wird. Wichtig zur Einordnung: Der Bericht sagt nicht, dass diese Mittel aus Kryptodiebstahl stammen. Die Zahl belegt also keinen bezifferten Schaden und sollte nicht als Beuteangabe gelesen werden.

Wer ist betroffen?

Betroffen sind Node.js-Umgebungen, in denen eines der zehn Pakete dieser Operation installiert wurde, unabhängig davon, ob es als direkte oder als transitive Abhängigkeit hineinkam. Das schließt Entwicklerrechner, Build-Agents, Container-Images und produktive Node.js-Dienste ein. Weil der Auslöser in der Anwendung selbst liegt, reicht das reine Installieren nicht aus, das Paket muss auch importiert und benutzt worden sein. Da es sich aber um die Hauptschreibfunktion einer Datenstruktur handelt, ist Benutzung im Normalfall der Regelfall und nicht die Ausnahme.

Neben indexed-btree hat Checkmarx neun weitere npm-Pakete derselben Operation gefunden, die inzwischen aus npm entfernt wurden, jeweils mit den genannten Downloadzahlen:

• ordered-kv-index mit 448.184 Downloads
• btree-leaderboard mit 493.685 Downloads
• priority-slot-queue mit 402.860 Downloads
• btree-range-store mit 468.092 Downloads
• btree-core mit 1.951.274 Downloads
• btree-time-index mit 425.312 Downloads
• btree-lru-cache mit 372.185 Downloads
• neighbor-key-map mit 366.019 Downloads
• sliding-score-window mit 448.024 Downloads

Nicht betroffen sind Umgebungen ganz ohne Node.js sowie Projekte, deren Lockfiles keinen dieser Namen enthalten. Auch die legitime Bibliothek sorted-btree ist nicht das Problem, sie wird lediglich als Vorlage für die Fälschung missbraucht. Wer ausschließlich eingefrorene, vor Monaten geprüfte Lockfiles ohne diese Namen verwendet, muss nichts nachinstallieren oder umstellen.

Wie kritisch ist das?

Es handelt sich nicht um eine CVE mit CVSS-Wert, sondern um eine aktive Lieferkettenkampagne. Die Bewertung läuft deshalb über die Folgen eines Treffers. Wenn der Code auf einem Entwicklerrechner oder Build-Agent gelaufen ist, muss man von einer kompromittierten Umgebung ausgehen: Systemdaten wurden abgezogen, und über die zweite Stufe aus dem Smart Contract ist beliebiger weiterer Code nachladbar. Für Build-Systeme, auf denen Cloud-Zugänge, Registry-Tokens und Signaturschlüssel liegen, ist das ein ernster Vorfall.

Die technische Neuerung ist der eigentliche Kern der Meldung. Der Schutz aus npm v12 ist nicht fehlerhaft, er greift an dieser Stelle schlicht nicht, weil er den Installationszeitpunkt absichert und der Schadcode erst danach startet. Wer Prüfungen nur zur Installationszeit fährt, sieht ein sauberes Paket ohne Install-Hook und stuft es damit eher als unauffällig ein. Genau diese Fehleinschätzung ist der Hebel der Kampagne.

Gesichert ist die technische Beschreibung durch die Checkmarx-Analyse und die Berichterstattung darüber. Unsicher ist die Frage nach dem tatsächlichen wirtschaftlichen Schaden. Die 109 ETH sind eine Wallet-Beobachtung, keine belegte Aussage über Diebstahlserlöse. Ebenfalls nicht öffentlich belegt ist, wie viele der Downloads tatsächlich in produktiven Anwendungen landeten und wie oft die zweite Stufe wirklich ausgeliefert wurde. Der Fall ist außerdem laut Checkmarx weiter im Gange, die Analyse wird fortgeschrieben.

Was sollten Admins jetzt tun?

• Inventar zuerst: Alle Repositories, Projekte, Container-Images und Lockfiles nach den zehn Paketnamen durchsuchen, auch in transitiven Abhängigkeiten. Praktisch geht das mit npm ls indexed-btree je Paketname oder durch direktes Durchsuchen von package-lock.json und npm-shrinkwrap.json nach den Namen. Die reine Suche in package.json reicht nicht, weil transitive Abhängigkeiten dort nicht stehen.
• Bei Fund alle Geheimnisse rotieren: API-Schlüssel, Registry-Tokens, Cloud-Zugangsdaten, SSH-Schlüssel und Signaturzertifikate, die auf dem betroffenen System erreichbar waren. Erst rotieren, dann aufräumen, nicht umgekehrt.
• Build- und Entwicklungsumgebung neu aufsetzen statt bereinigen: Die Schadsoftware kann ihre eigenen Spuren entfernen. Eine Wiederherstellung aus einem sauberen Backup oder ein frisch gebautes Image ist verlässlicher als jede Suche nach Restdateien.
• Ausgehende Verbindungen prüfen: In Proxy- und Firewall-Logs der Build-Netze nach Verbindungen zu Slack- und Telegram-Endpunkten sowie zu Ethereum-RPC-Diensten suchen. Für Build-Systeme sind solche Ziele in der Regel ohnehin kein legitimer Traffic.
• Lockfiles einfrieren und Pipelines umstellen: In CI konsequent npm ci statt npm install verwenden, damit nur aufgelöste und geprüfte Versionen installiert werden und sich keine neuen Abhängigkeiten still einschleichen.
• Neue Abhängigkeiten vor der Aufnahme prüfen: Alter des Pakets, Herausgeber, Downloadverlauf und Verhältnis zum bekannten Originalprojekt bewerten. Ein sehr ähnlicher Name zu einer etablierten Bibliothek ist das Warnsignal dieser Kampagne.
• Laufzeitüberwachung ergänzen: Checkmarx empfiehlt ausdrücklich, sich nicht allein auf Scans zur Installationszeit zu verlassen, sondern zusätzlich Verhaltensanalyse zur Laufzeit einzusetzen. In Build-Containern lohnt sich mindestens eine Beobachtung von Prozessstarts und ausgehenden Verbindungen.
• npm-v12-Einstellungen nicht aufweichen: allowScripts, --allow-git und --allow-remote bleiben sinnvoll und sollten restriktiv konfiguriert bleiben. Sie verlieren durch diesen Fall nicht ihren Wert, sie decken nur eben den Laufzeitpfad nicht ab.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen mit eigener Node.js-Entwicklung ist die Lehre aus diesem Fall vor allem organisatorisch. Im Juli 2026 war die Ansage einfach und gut kommunizierbar: npm führt keine Install-Skripte von Abhängigkeiten mehr aus, damit ist die häufigste Angriffsform entschärft. Diese Ansage bleibt richtig, sie ist aber nicht mehr vollständig. Wer seine interne Richtlinie oder sein Risikoregister auf diesen einen Satz gestützt hat, sollte ihn jetzt um den Laufzeitpfad ergänzen.

Praktisch heißt das: Die Abhängigkeitsprüfung endet nicht beim Installationsvorgang. Ein Paket ohne Install-Hook ist kein sicheres Paket, sondern nur ein Paket ohne Install-Hook. Für die Bewertung neuer Abhängigkeiten zählen weiterhin Herkunft, Alter, Pflegezustand und Namensähnlichkeit zu bekannten Projekten. Namensverwechslungen wie indexed-btree gegen sorted-btree fallen in Code-Reviews auf, wenn jemand gezielt darauf schaut, und sonst eben nicht.

Wirtschaftlich relevant ist der Aufwand im Trefferfall. Eine ernsthafte Rotation aller Geheimnisse und ein Neuaufbau der Build-Umgebung kosten Tage, nicht Stunden. Das spricht dafür, Build-Systeme von vornherein so zu bauen, dass sie reproduzierbar und wegwerfbar sind, und Zugangsdaten in Pipelines eng zu begrenzen, statt einem Build-Agent dauerhaft weitreichende Cloud-Rechte zu geben. Dieselbe Vorbereitung hilft bei jedem künftigen Lieferkettenvorfall, unabhängig vom konkreten Auslöser.

Passende Anleitungen auf S-EDV

• GitHub blockiert npm-Install-Skripte ab npm 12 beschreibt genau die Schutzmaßnahme, die diese Kampagne umgeht, und erklärt die Umstellung auf allowScripts.
• npm 12 und Lieferkettenangriffe bei Installationen ordnet ein, welche Angriffswege der Installationszeitpunkt abdeckt und welche nicht.
• Bösartige npm-Pakete tarnen sich als PostCSS-Werkzeuge zeigt die klassische Variante mit Namensähnlichkeit und Schadcode beim Installieren als Vergleichsfall.

Quellen

• Checkmarx Zero: npm btree malware campaign affects millions of downloads, no need for install script als Primärquelle mit der technischen Analyse des Laufzeit-Auslösers.
• BleepingComputer vom 20. September 2026: Malicious npm packages evade install-script defenses at runtime mit der Aufstellung der neun weiteren Pakete und ihrer Downloadzahlen.
• GitHub Changelog: npm install-time security defaults als Beleg für die im Juni 2026 angekündigten und mit npm v12 aktivierten Sperren für Lifecycle-Skripte, Git- und Remote-Abhängigkeiten.