npm v12: GitHub blockiert Install-Skripte ab Werk gegen Supply-Chain-Angriffe

GitHub stellt den Paketmanager npm mit Version 12 von „blindem Vertrauen“ auf ausdrückliche Freigabe um. Ab dem geplanten Start im Juli 2026 führt npm install keine Install-Skripte aus Abhängigkeiten mehr automatisch aus. Git- und Remote-Abhängigkeiten sind dann ebenfalls standardmäßig blockiert. Das geht aus dem offiziellen Changelog vom 9. Juni 2026 hervor.

npm ist die größte Paketregistry für JavaScript und gehört über GitHub zu Microsoft. Der Befehl npm install lädt die Abhängigkeiten eines Projekts und startet dabei bisher alle vom Paket definierten Skripte. Entwickler führen ihn nach dem Klonen, beim Aktualisieren und in CI/CD-Pipelines aus. Genau dieser automatische Ablauf ist seit Jahren der zuverlässigste Einstiegspunkt für Angreifer.

Was sich bei npm install konkret ändert

Drei Voreinstellungen kippen von Opt-out auf Opt-in. Jede macht aus einem heute automatischen Verhalten eine bewusste Entscheidung.

preinstall-, install– und postinstall-Skripte aus Abhängigkeiten laufen nicht mehr ohne Freigabe. Das betrifft auch native node-gyp-Builds. Ein Paket mit einer binding.gyp ohne eigenes Install-Skript wird blockiert, weil npm dafür einen impliziten node-gyp rebuild startet. Mit npm approve-scripts --allow-scripts-pending lässt sich anzeigen, was blockiert wird. Vertrauenswürdige Pakete gibt man mit npm approve-scripts frei, der Rest wird mit npm deny-scripts gesperrt.

Zudem löst npm Git-Abhängigkeiten nur noch mit dem Flag --allow-git auf. Das schließt einen Weg zur Codeausführung, bei dem die .npmrc einer Git-Abhängigkeit die Git-Programmdatei austauschen konnte. Außerdem sind Abhängigkeiten von entfernten URLs wie HTTPS-Tarballs nur mit --allow-remote erlaubt. Die Flags --allow-file und --allow-directory behalten ihre bisherigen Voreinstellungen.

Anzeige

Warum GitHub jetzt handelt

Die Umstellung fällt mit einer Welle von Supply-Chain-Angriffen zusammen. Bei einem solchen Angriff schleusen Täter Schadcode in vertrauenswürdige Pakete ein, die andere Projekte als Abhängigkeit laden. Zuletzt traf das die offiziellen npm-Pakete von Red Hat durch den Miasma-Wurm. Davor war das Python-Paket LiteLLM mit 95 Millionen Downloads betroffen. Warum dieser Angriffstyp im KI-Zeitalter so gefährlich wird, haben wir in einer Analyse zur Supply Chain als größte Angriffsfläche eingeordnet.

claw://SECURITY

Miasma: Supply-Chain-Angriff trifft offizielle npm-Pakete von Red HatEin Supply-Chain-Angriff mit dem Namen Miasma hat mehrere offizielle npm-Pakete aus dem Bereich Red Hat Cloud Services kompromittiert. Der eingeschleuste Schadcode stiehlt Zugangsdaten und verbreitet…5. Juni 2026

Was Entwickler jetzt tun sollten

Alle drei Änderungen stehen bereits als Warnungen in npm 11.16.0 oder neuer bereit. Damit lässt sich vor dem Umstieg prüfen, was später Probleme verursachen könnte.

GitHub empfiehlt einen klaren Ablauf. Zuerst auf npm 11.16.0 oder neuer aktualisieren und einen normalen Install ausführen. Dann mit npm approve-scripts --allow-scripts-pending die Pakete mit Skripten prüfen und die vertrauenswürdigen freigeben sowie die aktualisierte package.json ins Repository übernehmen. Nach dem Umstieg laufen nur noch die freigegebenen Skripte.

Wer interne HTTPS-Tarballs oder an Git-Branches gepinnte Pakete nutzt, sollte das vor Juli klären. Die saubere Lösung ist der Wechsel zu einer echten Registry statt --allow-remote in jedem CI-Skript.