npm's nächste Hauptversion, v12, für Juli 2026 geplant, wird standardmäßig keine Dependency-Installationsskripte mehr ausführen.
Wir sind erleichtert, das zu hören. Das Deaktivieren von Installationsskripten ist die nützlichste Änderung, die npm an seinen Standardeinstellungen vornehmen konnte. Die Community litt im letzten Jahr unter einer Flut von Lieferkettenangriffen, wie Nx s1ngularity und Shai-Hulud, die Postinstall-Skripte ausnutzten. Dieses npm-Update ist eine lang erwartete Änderung, die einen großen Angriffsvektor in der Lieferkette verkleinern wird.
Was npm ändert
Wenn Sie ausführen npm install heute kann jedes Paket irgendwo in Ihrem Dependency Tree Lifecycle-Skripte definieren, die aufgerufen werden preinstall, Installieren, oder postinstall, und npm führt sie automatisch für Sie aus. Der Code wird in dem Moment ausgeführt, in dem Sie installieren, bevor Sie etwas importieren oder Ihren eigenen Code ausführen.
v12 unterbindet dies. Skripte werden nur für Pakete ausgeführt, die Sie auf eine Allowlist gesetzt haben, die Sie mit npm approve-scripts erstellen, den Rest mit npm deny-scripts blockieren und zusammen mit dem Rest Ihres Projekts committen.
Einige weitere kleinere Änderungen werden damit ausgeliefert. Git-Abhängigkeiten werden nicht mehr aufgelöst, es sei denn, Sie übergeben --allow-git, was einen unauffälligeren Ausführungspfad schließt, bei dem die npmrc einer Git-Abhängigkeit das Git-Executable überschreiben und Code ausführen könnte, selbst wenn --ignore-scripts gesetzt ist. Remote-URL-Abhängigkeiten, wie HTTPS-Tarballs, werden ebenfalls nicht mehr aufgelöst, es sei denn, Sie übergeben --allow-remote, wodurch ein Pfad geschlossen wird, über den ein Angreifer eine Abhängigkeit auf eine externe URL lenken könnte, die er kontrolliert, und die Payload jederzeit austauschen könnte.
Die Allowlist deckt auch Code ab, der niemals im Skriptfeld auftaucht. Wenn ein Paket eine binding.gyp ausliefert, führt npm während der Installation einen impliziten node-gyp rebuild dafür aus, sodass eine Abhängigkeit mit einer makellosen package.json immer noch Code ausführen kann, nur indem sie diese eine Build-Datei mitführt. v12 behandelt diesen Build wie ein deklariertes Skript, sodass er blockiert wird, es sei denn, das Paket befindet sich auf Ihrer Allowlist. Unser Forschungsteam hat kürzlich aufgezeigt, wie seltsam und gefährlich dieser potenzielle Angriffspfad ist.
All dies ist bereits in npm 11.16.0 hinter Warnungen verfügbar, sodass Sie sehen können, was kaputtgeht, bevor Sie ein Upgrade durchführen.
Die Postinstall-Exploits, die die npm-Änderung behebt
Fast jeder Wurm und Credential Stealer, der npm seit letztem Herbst getroffen hat, lief während der Installationszeit und nicht zur Laufzeit. Das Muster dafür beinhaltet im Allgemeinen, dass ein Angreifer zunächst ein vertrauenswürdiges Paket übernimmt, normalerweise indem er ein npm-Konto eines Maintainers phisht oder einen Publish Token stiehlt. Dann veröffentlichen die Angreifer eine neue Version mit einem hinzugefügten Postinstall-Skript in ihrer package.json, wobei die eigentliche Quelle oft unberührt bleibt, sodass nichts offensichtlich falsch aussieht.
Wenn jemand npm install ausführt, führt npm dieses Skript automatisch als Benutzer aus. Es erstellt einen Fingerabdruck der Maschine, lädt die eigentliche Payload von einem Angreifer-Server herunter, führt sie aus und löscht sich selbst, während die Payload nach Tokens, SSH-Keys und anderen Werten sucht und diese dann versendet.
Bei diesen Angriffen müssen Sie das schadhafte Paket nicht einmal verwenden oder importieren, um zum Opfer zu werden. Sie müssen nur das Pech haben, auszuführen npm install während das Paket infiziert ist.
Mit der Standardeinstellung von v12 würde die Installation einfach bei dem bösartigen Paket stoppen, es sei denn, genau dieses Paket befindet sich auf der von Ihnen committeden Allowlist. Der Angreifer kann die vergiftete Version immer noch veröffentlichen, aber auf einer Maschine mit v12 liegt sie als inerte Dateien in node_modules.
Warum dies wichtig ist
Die Welle der Postinstall-Skript-Angriffe begann letzten Herbst und hat seitdem nicht wirklich aufgehört. Wir sahen diesen Angriff auf ein Red Hat-Paket erst vor einer Woche. Einige der großen Angriffe, die dies ausnutzten und unsere Sicherheitsforscher nachts wach hielten, sind:
- Nx s1ngularity, August 2025. Ein gestohlener Publish Token pushte bösartige Nx-Versionen, deren Postinstall-Skript, telemetry.js, bei der Installation ausgeführt wurde. Es sammelte GitHub-Tokens, npm-Anmeldeinformationen, SSH-Keys und Krypto-Wallets und lud sie dann in öffentliche GitHub-Repos hoch. Die etwa 2.300 gesammelten Anmeldeinformationen dienten als Grundlage für zukünftige Angriffe.
- Shai-Hulud, November 2025. Ein selbst-replizierender Wurm, der fast 500 Pakete bei Zapier, ENS, PostHog, Postman und AsyncAPI befiel, installierte die Bun-Laufzeitumgebung während der Einrichtung, führte TruffleHog aus, um Secrets zu scrapen, und dumpte sie in öffentliche GitHub-Repos.
- Der axios-Hijack, März 2026. Ein gehacktes Maintainer-Konto lieferte eine Abhängigkeit aus, die nur dazu diente, einen Postinstall-Hook auszuführen und einen plattformübergreifenden RAT zu platzieren. axios verzeichnet etwa 100 Millionen Downloads pro Woche.
- Mini Shai-Hulud, Mai 2026. Ein Spinoff-Wurm des OG Shai Hulud, der einen Preinstall-Hook platzierte, der die Bun-Laufzeitumgebung zog und einen Credential Stealer ausführte. Er verbreitete sich über hundert Pakete bei TanStack, UiPath und Mistral AI und wurde der erste npm-Wurm, der Malware mit gültiger Build-Provenienz veröffentlichte.
Dies ist nicht nur ein npm-Problem, obwohl npm das größte Ziel ist. Die gleiche Idee zeigt sich in anderen Ökosystemen, wie PHPs Composer, wo im Mai mehr als 200 Laravel-Lang-Versionen umgeschrieben wurden, um automatisch einen Credential Stealer über den Autoloader auszuführen (Composer verfügt jetzt über native Malware-Filterung, die von Aikido betrieben wird, um nachgeschaltete Benutzer zu schützen).
Was jetzt zu tun ist
Führen Sie ein Upgrade auf npm 11.16.0 oder höher durch, da alle drei Änderungen bereits mit Warnungen vorhanden sind. Wenn Sie bereits 11.15.0+ verwenden, --allow-git ist jetzt verfügbar, und --allow-remote seit 11.15.0, sodass Sie diese bereits sperren können, ohne auf v12 zu warten. Für Skripte führen Sie aus npm approve-scripts --allow-scripts-pending um zu sehen, was blockiert würde, genehmigen Sie die Pakete, denen Sie vertrauen, und committen Sie die aktualisierte package.json. Was Sie überspringen, wird nicht mehr ausgeführt, wenn v12 veröffentlicht wird. Überprüfen Sie dies, denn viele legitime Pakete verwenden Install-Skripte für native Builds und Setups, und sobald die Standardeinstellung geändert wird, benötigen diese Installationen eine Genehmigung.
Sie können auch Safe Chain von Aikido installieren, einen kostenlosen sicheren Wrapper für npm, npx und yarn, der sich in Ihren aktuellen Workflow integriert und jedes Paket vor der Installation auf Malware überprüft. Er verhindert, dass Sie versehentlich Malware installieren, und erzwingt eine Wartezeit für neue Paketversionen, was eine beträchtliche Anzahl kompromittierter Pakete daran hindert, auf Ihr Gerät zu gelangen.
Gute Standardeinstellungen schützen diejenigen, die nie ein Changelog öffnen (was fast jeder ist, fast die ganze Zeit, außer Sicherheitsforschende und die entsprechend Paranoiden). Dass npm dies standardmäßig sicher macht, ist die richtige Entscheidung. Es hätte nicht ein Jahr öffentlicher Schäden gebraucht, um zu geschehen, und es wird nicht alles lösen, aber wir sind froh, dass es da ist.
