NPM v12 blockiert ab Juli automatische Skripte und Git-Abhängigkeiten bei der Installation. Experten kritisieren den fehlenden Schutz vor Kontenübernahmen.
Der JavaScript-Paketmanager NPM erhält im Juli 2026 ein umfassendes Sicherheitsupdate mit der Veröffentlichung der Version 12. Die zweite Vorabversion wurde am Montag bereitgestellt. Das Update soll spezifische Sicherheitslücken schließen, die in der Vergangenheit für Angriffe auf die Software-Lieferkette ausgenutzt wurden. Seit der Version 11.16.0 erhalten Entwickler bereits automatische Warnmeldungen, um potenzielle Kompatibilitätsprobleme in ihren Projekten vor dem finalen Release zu identifizieren.
Blockierung von Installationsskripten und externen Quellen
Die wichtigste Änderung in NPM v12 betrifft den Befehl npm install. Bisher wurden bei der Installation eines Pakets automatisch auch alle integrierten Vorinstallations-, Installations- und Nachinstallationsskripte der jeweiligen Abhängigkeiten ausgeführt. Ab Version 12 werden diese Skripte standardmäßig blockiert und erfordern eine explizite Genehmigung durch den Entwickler.
Zudem unterbindet das System künftig das standardmäßige Herunterladen von Abhängigkeiten von externen Drittanbieter-Websites wie GitHub. Diese Git-Abhängigkeiten sind ohne ausdrückliche Erlaubnis gesperrt. Bisher konnten NPM-Pakete Programmcode aus beliebigen externen Quellen nachladen.
Kritik von IT-Sicherheitsexperten an verbleibenden Lücken
Analysten des Sicherheitsunternehmens OX Security weisen darauf hin, dass die neuen Schutzmaßnahmen die grundlegenden Risiken von Lieferkettenangriffen nicht vollständig beseitigen. Moshe Siman Tov Bustan, Sicherheitsforscher bei OX Security, erklärt in einem Bericht:
„Die Übernahme von Konten bleibt eine offene Wunde. Sobald ein Akteur die Zugangsdaten eines legitimen Maintainers kontrolliert, hilft kein Blockieren von Installationsskripten, da der Schadcode als vertrauenswürdiges, signiertes Release ausgeliefert wird.“
Moshe Siman Tov Bustan, Sicherheitsforscher bei OX Security
Schadcode kann weiterhin ohne nachgelagerte Installationsskripte ausgeführt werden, sobald eine kompromittierte Bibliothek in ein Projekt eingebunden wird. Bustan führt dazu aus: „Akteure können immer noch willkürliche Befehle ausführen, sobald ihr kompromittiertes Modul per require() oder import importiert wird – keine Skripte erforderlich, keine Aufforderung zur Benutzerbestätigung, nichts.“ Zudem merken die Forscher an, dass Pakete mit C-Code, die über das Hilfswerkzeug node-gyp kompiliert werden, ein verbleibendes Risiko darstellen können.
Forderung nach systemseitiger Schadsoftware-Erkennung
Laut OX Security sollte die Erkennung bösartiger Absichten direkt beim Hochladen von Paketen ansetzen. Der Forscher stellt fest: „NPM muss anfangen, bösartigen Code und bösartige Absichten so zu behandeln, wie Social-Media-Plattformen anstößige Inhalte behandeln.“ Er ergänzt: „Die Industrie kann Erkennungs- und Reaktionswerkzeuge von außen aufbauen, aber nur für den Teil der Entwickler, die diese bereits nutzen. Die meisten werden es nicht tun.“
Da NPM von GitHub kontrolliert wird, das sich im Besitz von Microsoft befindet, sieht die Sicherheitsfirma die Verantwortung beim Mutterkonzern: „Die in Version 12 kommenden Korrekturen sind ein Anfang, aber sie betreffen weder die Übernahme von Konten noch native Builds oder die Erkennung bösartiger Absichten zum Zeitpunkt der Veröffentlichung. Diese Lücken zu schließen, liegt ganz klar bei Microsoft.“
Häufung von Lieferkettenangriffen im JavaScript-Ökosystem
Die Überarbeitung des Paketmanagers erfolgt als Reaktion auf mehrere Sicherheitsvorfälle in den vergangenen Monaten. Im März 2026 kaperten Angreifer das Konto eines Hauptentwicklers der weit verbreiteten JavaScript-Bibliothek Axios, die wöchentlich über 100 Millionen Downloads verzeichnet, um Schadsoftware zu verteilen. Zwei Monate später wurden über das kompromittierte Konto eines einzelnen Entwicklers mehr als 600 Pakete im Bereich der Datenvisualisierung und Webentwicklung manipuliert. Auch andere bekannte Projekte wie Trivy, Checkmarx und TanStack waren von ähnlichen Vorfällen betroffen.
(red)