Die nächste Hauptversion von npm, v12, die für Juli 2026 geplant ist, wird standardmäßig keine Skripte zur Installation von Abhängigkeiten mehr ausführen.
Das beruhigt uns. Die Deaktivierung von Installationsskripten ist die sinnvollste Änderung, die npm an seinen Standardeinstellungen vornehmen könnte. Die Community wurde Lieferkettenangriffe letzten Jahr Lieferkettenangriffe einer Flut von Lieferkettenangriffe heimgesucht, wie beispielsweise Nx s1ngularity und Shai-Hulud, bei denen Postinstallationsskripte ausgenutzt wurden. Dieses npm-Update ist eine lang erwartete Änderung, die einen riesigen Angriffsvektor in der Lieferkette einschränken wird.
Was sich bei npm ändert
Wenn du npm install Heute kann jedes Paket in Ihrem Abhängigkeitsbaum Lebenszyklus-Skripte definieren, die preinstall, installieren, oder postinstall, und npm führt sie automatisch für dich aus. Der Code wird sofort nach der Installation ausgeführt, noch bevor du etwas importierst oder deinen eigenen Code ausführst.
Mit v12 ist damit Schluss. Skripte werden nur für Pakete ausgeführt, die Sie auf eine Zulassungsliste gesetzt haben – diese erstellen Sie mit `npm approve-scripts`, während Sie alle anderen mit `npm deny-scripts` blockieren und zusammen mit dem Rest Ihres Projekts committen.
Es gibt noch einige weitere kleinere Änderungen. Git-Abhängigkeiten werden nur noch aufgelöst, wenn Sie --allow-git, wodurch eine weniger offensichtliche Ausführungsmöglichkeit geschlossen wird, bei der die npmrc-Datei einer Git-Abhängigkeit die Git-Ausführungsdatei überschreiben und Code ausführen könnte, selbst wenn --ignore-scripts eingestellt. Auch Abhängigkeiten von Remote-URLs, wie z. B. https-Tarballs, werden nicht mehr aufgelöst, es sei denn, Sie übergeben --remote zulassen, wodurch eine Schwachstelle geschlossen wird, über die ein Angreifer eine Abhängigkeit auf eine von ihm kontrollierte externe URL verweisen und die Nutzlast jederzeit austauschen könnte.
Die Zulassungsliste umfasst auch Code, der nie im Feld „scripts“ erscheint. Wenn ein Paket eine „binding.gyp“-Datei enthält, führt npm während der Installation implizit einen „node-gyp rebuild“ dafür durch. Daher kann eine Abhängigkeit mit einer makellosen „package.json“-Datei allein durch das Vorhandensein dieser einen Build-Datei dennoch Code ausführen. In Version 12 wird dieser Build wie ein deklariertes Skript behandelt, sodass er blockiert wird, sofern das Paket nicht auf Ihrer Zulassungsliste steht. Unser Forschungsteam hat kürzlich aufgezeigt, wie seltsam und gefährlich dieser potenzielle Angriffsweg ist.
All dies ist in npm 11.16.0 bereits hinter Warnmeldungen verborgen, sodass Sie vor dem Upgrade sehen können, was nicht mehr funktioniert.
Die Exploits nach der Installation, die durch die Änderung an npm behoben werden
Fast jeder Wurm und jeder Credential-Stealer, der seit letztem Herbst npm befallen hat, wurde während der Installation und nicht zur Laufzeit ausgeführt. Das Muster sieht in der Regel so aus, dass ein Angreifer zunächst ein vertrauenswürdiges Paket übernimmt, meist durch Phishing des npm-Kontos eines Betreuers oder durch den Diebstahl eines Veröffentlichungstokens. Anschließend veröffentlichen die Angreifer eine neue Version, der ein Postinstall-Skript zur Datei „package.json“ hinzugefügt wurde, wobei der eigentliche Quellcode oft unverändert bleibt, sodass nichts offensichtlich verdächtig wirkt.
Wenn jemand „npm install“ ausführt, führt npm dieses Skript automatisch im Namen des Benutzers aus. Es erstellt einen Fingerabdruck des Computers, lädt die eigentliche Schadsoftware von einem Server des Angreifers herunter, führt sie aus und löscht sich anschließend selbst, während die Schadsoftware nach Tokens, SSH-Schlüsseln und anderen wertvollen Daten sucht und diese dann weiterleitet
Bei diesen Angriffen muss man nicht einmal das schädliche Paket verwenden oder gar importieren, um Opfer zu werden. Man muss nur das Pech haben, es auszuführen npm install solange das Paket infiziert ist.
Wenn die Standardeinstellung von v12 aktiv ist, würde die Installation bereits beim schädlichen Paket abbrechen, es sei denn, genau dieses Paket steht auf der von Ihnen festgelegten Zulassungsliste. Der Angreifer kann die manipulierte Version zwar weiterhin veröffentlichen, doch auf einem Rechner mit v12 verbleibt sie als inaktive Datei im Verzeichnis „node_modules“.
Warum das wichtig ist
Die Welle von Angriffen über Postinstallationsskripte begann im vergangenen Herbst und hat seitdem nicht wirklich nachgelassen. Erst vor einer Woche haben wir einen solchen Angriff auf ein Red Hat-Paket beobachtet. Zu den größten Angriffen, die diese Schwachstelle ausnutzten und unseren Sicherheitsforschern schlaflose Nächte bereiteten, zählen:
- Nx-S1ngularity, August 2025. Ein gestohlener Veröffentlichungstoken verbreitete bösartige Nx-Versionen, deren Postinstallationsskript „telemetry.js“ bei der Installation ausgeführt wurde. Es sammelte GitHub-Token, npm-Anmeldedaten, SSH-Schlüssel und Krypto-Wallets und lud diese anschließend in öffentliche GitHub-Repositorys hoch. Die rund 2.300 gesammelten Anmeldedaten dienten als Grundlage für spätere Angriffe.
- Shai-Hulud, November 2025. Ein sich selbst replizierender Wurm, der fast 500 Pakete bei Zapier, ENS, PostHog, Postman und AsyncAPI befallen hat, installierte während der Einrichtung die Bun-Laufzeitumgebung, führte TruffleHog aus, um secrets abzugreifen, und speicherte diese in öffentlichen GitHub-Repositorys.
- Der Axios-Hack, März 2026. Über ein gehacktes Maintainer-Konto wurde eine Abhängigkeit bereitgestellt, die einzig und allein dazu diente, einen Postinstall-Hook auszuführen und eine plattformübergreifende RAT zu installieren. Axios verzeichnet etwa 100 Millionen Downloads pro Woche.
- Mini Shai-Hulud, Mai 2026. Ein Ableger des ursprünglichen Shai-Hulud-Wurms, der einen vorinstallierten Hook einbaute, der die Bun-Laufzeitumgebung auslöste und einen Credential-Stealer ausführte. Er verbreitete sich über mehr als hundert Pakete in TanStack, UiPath und Mistral AI und war der erste npm-Wurm, der Malware mit gültiger Build-Herkunft veröffentlichte.
Dies ist nicht nur ein Problem von npm, auch wenn npm das größte Ziel ist. Das gleiche Prinzip taucht auch in anderen Ökosystemen auf, wie beispielsweise bei PHPs Composer, wo im Mai mehr als 200 Laravel-Lang-Versionen umgeschrieben wurden, um über den Autoloader automatisch einen Credential-Stealer auszuführen (Composer verfügt nun über eine native Malware-Filterung auf Basis von Aikido, um nachgelagerte Nutzer zu schützen).
Was nun?
Führen Sie ein Upgrade auf npm 11.16.0 oder höher durch, da alle drei Änderungen dort bereits vorhanden sind – allerdings mit entsprechenden Warnungen. Wenn Sie bereits Version 11.15.0 oder höher verwenden, --allow-git ist ab sofort erhältlich, und –-remote zulassen seit Version 11.15.0, du kannst also schon damit anfangen, diese zu sichern, ohne auf Version 12 zu warten. Für Skripte führe Folgendes aus: npm approve-scripts --allow-scripts-pending um zu sehen, was blockiert würde, die Pakete zu genehmigen, denen Sie vertrauen, und die aktualisierte Version zu übernehmen package.json. Was auch immer du überspringst, wird nicht mehr ausgeführt, sobald v12 verfügbar ist. Überprüfe das, denn viele legitime Pakete verwenden Installationsskripte für native Builds und die Einrichtung, und sobald die Standardeinstellung geändert wird, müssen diese Installationen genehmigt werden.
Sie können auch „Safe Chain“ von Aikido installieren, einen kostenlosen Sicherheits-Wrapper für npm, npx und yarn, der sich nahtlos in Ihren aktuellen Arbeitsablauf einfügt und jedes Paket vor der Installation auf Malware überprüft. Er verhindert, dass Sie versehentlich Malware installieren, und legt eine Wartezeit für neue Paketversionen fest, wodurch ein Großteil der kompromittierten Pakete davon abgehalten wird, auf Ihr Gerät zu gelangen.
Gute Standardeinstellungen schützen diejenigen, die niemals ein Changelog öffnen (das sind fast alle, fast immer, außer Sicherheitsforscher und die angemessen Paranoiden). Dass npm diese Einstellung standardmäßig sicher macht, ist die richtige Entscheidung. Es hätte nicht erst ein Jahr voller öffentlicher Chaoserfordern müssen, damit dies geschieht, und es wird nicht alle Probleme lösen, aber wir sind froh, dass es nun so ist.
