npm 12 verschärft Installationen gegen Supply-Chain-Angriffe

GitHub bereitet für npm 12 mehrere sicherheitsrelevante Änderungen vor. Die nächste Hauptversion des Paketmanagers soll voraussichtlich im Juli 2026 erscheinen und den Standardablauf von npm install deutlich restriktiver machen. Für Unternehmen ist das relevant, weil viele Entwicklungs- und CI/CD-Umgebungen heute automatisch Installationsskripte, Git-Abhängigkeiten oder entfernte Paketquellen ausführen.

Was ist neu?

npm 12 soll mehrere Verhaltensweisen ändern, die bisher automatisch erlaubt waren. Die wichtigste Änderung betrifft Installationsskripte von Abhängigkeiten. preinstall, install und postinstall aus Dependencies sollen nicht mehr automatisch laufen, sofern sie nicht vorher explizit erlaubt wurden. Das gilt auch für native Builds über node-gyp und für prepare-Skripte aus Git-, Datei- und Link-Abhängigkeiten.

GitHub beschreibt das Prinzip als Wechsel von implizitem Vertrauen zu expliziter Freigabe. Teams können mit npm approve-scripts --allow-scripts-pending prüfen, welche Pakete betroffen sind. Erlaubte Pakete werden mit npm approve-scripts bestätigt, blockierte Pakete mit npm deny-scripts festgelegt. Die daraus entstehende Richtlinie wird in der package.json gespeichert und sollte versioniert werden.

Zusätzlich werden Git-Abhängigkeiten und entfernte URL-Abhängigkeiten restriktiver behandelt. Für Git-Quellen soll künftig standardmäßig --allow-git=none gelten. Für entfernte Quellen wie HTTPS-Tarballs ist --allow-remote=none vorgesehen. Beide Änderungen sollen verhindern, dass Installationen unbemerkt Code oder Paketquellen außerhalb des erwarteten Registry-Pfades einbinden.

Welche Fehler wurden behoben?

Es handelt sich nicht um ein klassisches Fehlerbehebungsupdate mit einer einzelnen korrigierten Schwachstelle. Die Änderung adressiert vielmehr ein strukturelles Risiko im npm-Ökosystem: Paketinstallationen konnten bisher automatisch Code ausführen oder externe Quellen auflösen. Genau diese Mechanismen wurden in den vergangenen Monaten mehrfach bei Supply-Chain-Angriffen missbraucht.

Ein konkretes Beispiel liefert der TanStack-Postmortem-Bericht vom Mai 2026. Dort wurden 84 bösartige npm-Versionen über 42 Pakete veröffentlicht. Die Malware nutzte Installationsabläufe, um Zugangsdaten aus Entwicklungs- und CI-Umgebungen abzugreifen. TanStack erklärte später, dass die aktuell verfügbaren Paketversionen wieder sicher seien. Der Vorfall zeigt aber, warum automatische Ausführung während einer Paketinstallation für Angreifer attraktiv ist.

Gibt es Sicherheitskorrekturen?

Ja, allerdings in Form neuer Sicherheitsdefaults und nicht als Patch für eine einzelne CVE. BleepingComputer ordnet die Ankündigung als Maßnahme gegen Supply-Chain-Angriffe ein, die npm install als Einstiegspunkt nutzen. Für IT-Teams ist besonders wichtig, dass Installationsskripte häufig in Umgebungen laufen, in denen Cloud-Zugangsdaten, Repository-Tokens, npm-Tokens, SSH-Schlüssel oder weitere Build-Geheimnisse verfügbar sind.

Die Änderungen in npm 12 reduzieren dieses Risiko, indem fremder Code nicht mehr allein durch eine Abhängigkeit automatisch zur Ausführung kommt. Das verhindert nicht jede kompromittierte Dependency, erhöht aber die Hürde für Angreifer und macht erlaubte Ausnahmen im Repository nachvollziehbarer.

Wen betrifft das Update?

Betroffen sind Entwicklerteams, Administratoren und DevOps-Verantwortliche, die Node.js-Anwendungen bauen oder JavaScript-Abhängigkeiten in CI/CD-Pipelines installieren. Besonders relevant ist die Änderung für Projekte mit nativen Modulen, Headless-Browsern, Git-Abhängigkeiten, privaten Tarballs, lokalen Link-Abhängigkeiten oder gewachsenen Build-Skripten.

Auch Unternehmen, die eigene npm-Pakete veröffentlichen, sollten ihre Prozesse prüfen. Neben den Installationsänderungen bleibt Trusted Publishing per OIDC wichtig, weil es langfristige npm-Tokens in CI/CD-Pipelines ersetzt. Die npm-Dokumentation nennt dafür derzeit GitHub Actions, GitLab CI/CD und CircleCI als unterstützte Anbieter.

Sollte man sofort aktualisieren?

Ein produktiver Umstieg auf npm 12 ist erst sinnvoll, wenn die eigenen Projekte getestet wurden. GitHub empfiehlt, schon jetzt npm 11.16.0 oder neuer einzusetzen, weil diese Version Warnungen für künftige Brüche ausgeben kann. Dadurch lässt sich vorab erkennen, welche Abhängigkeiten Skripte ausführen oder externe Quellen benötigen.

Ein sofortiges blindes Aktualisieren in produktiven Build-Pipelines wäre riskant, weil legitime Installationen nach dem Wechsel fehlschlagen können. Besser ist ein kontrollierter Test in Entwicklungs- und CI-Umgebungen, anschließend die gezielte Freigabe notwendiger Skripte und Quellen.

Was ist vor dem Update zu beachten?

1. npm 11.16.0 oder neuer in einer Testumgebung verwenden.
2. Normale Installations- und Build-Prozesse laufen lassen.
3. Warnungen zu Installationsskripten, Git-Abhängigkeiten und entfernten Quellen auswerten.
4. Nur wirklich benötigte Pakete mit Skriptausführung freigeben.
5. Freigaben in der package.json prüfen und committen.
6. CI/CD-Pipelines mit denselben Regeln testen, die später produktiv gelten.
7. Langfristige npm-Tokens prüfen und, wo möglich, Trusted Publishing einsetzen.

Empfehlung für Administratoren

Administratoren und DevOps-Teams sollten npm 12 nicht als reines Entwickler-Thema behandeln. Paketinstallationen sind Teil der Software-Lieferkette und laufen häufig auf Build-Systemen mit weitreichenden Berechtigungen. Deshalb sollten Freigaben für Installationsskripte wie eine Sicherheitsrichtlinie behandelt werden: dokumentiert, überprüfbar und im Repository versioniert.

Mehr dazu auf s-edv.com: Für Kontoschutz und Veröffentlichungsprozesse sind Zwei-Faktor-Authentifizierung einführen und sichere Passwörter und Passkeys im Unternehmen passende Grundlagen.

Fazit

npm 12 bringt keine spektakuläre Einzelkorrektur, sondern eine wichtige Verschiebung der Sicherheitslogik. Installationen sollen weniger automatisch vertrauen und mehr explizite Entscheidungen verlangen. Für Unternehmen ist das zunächst zusätzlicher Prüfaufwand, langfristig aber ein sinnvoller Schritt gegen Supply-Chain-Angriffe in Entwicklungs- und Build-Umgebungen.

Quellen: GitHub Changelog, BleepingComputer, npm-Dokumentation zu approve-scripts, npm-Dokumentation zu Trusted Publishing, TanStack-Postmortem.