npm tackles its riskiest security issues

Contents

With npm v12, GitHub is eliminating several security-critical default settings of the Node.js package manager. The main version, announced for July 2026, will no longer automatically execute installation scripts from dependencies. npm will also only install Git and remote dependencies if developers explicitly approve them. With this, GitHub aims to close one of the most important attack vectors in the software supply chain: the automatic code execution during an npm install.

npm is the standard package manager for the Node.js ecosystem and one of the most widely used package management systems. Modern applications often pull in hundreds or thousands of direct and indirect dependencies. The attack surface is correspondingly large. For years, security researchers have warned of supply chain attacks in which malicious code enters development environments via compromised packages, stolen maintainer accounts, or manipulated installation scripts. Mechanisms that execute code when a package is installed are particularly dangerous – often before developers have even started the application.

Installation scripts no longer run automatically

This is precisely where the most important innovation of npm v12 comes in. In the future, the package manager will not execute installation scripts from dependencies by default. This affects the lifecycle scripts preinstall, install, and postinstall. Native extensions that npm previously compiled automatically via node-gyp will also no longer be built without approval. The same applies to certain prepare scripts from Git, file, or linked dependencies.

Previously, a simple npm install was sufficient to execute such scripts automatically. Many packages use the mechanism for legitimate purposes, such as downloading additional binary files or compiling native components. However, the same function has been considered an attractive attack vector for years: malicious code can be executed during installation via a manipulated installation script. The code can, for example, read environment variables, intercept login credentials, or download further malware.

Approvals via allowlist

An allowlist model replaces automatic execution. Developers will henceforth determine themselves which packages are allowed to execute their installation scripts. npm stores these approvals in the project, allowing teams to version them along with the source code.

Those who want to switch early can already do so: npm 11.16.0 already warns about scripts that the package manager will block in the future. With the command npm approve-scripts --allow-scripts-pending, you can check which dependencies would be affected; with npm approve-scripts, you can then approve the trusted packages.

Git and remote dependencies on hold

npm is also tightening its grip on handling Git dependencies. The package manager will block packages that come directly from a Git repository by default in the future; developers must explicitly allow such sources. GitHub justifies this step with an attack vector through which code could be executed from a Git dependency – even if installation scripts were actually suppressed. In addition, Git dependencies are generally more difficult to control than packages from the regular npm registry.

A similar hurdle will apply to remote dependencies in the future, i.e., packages that come directly from a URL, for example, as a TAR archive via HTTPS. npm will also only install them after explicit approval. Such dependencies bypass the usual registry infrastructure and make it harder to trace their origin. GitHub wants to prevent external sources from entering the dependency chain unnoticed.

What developers should do now

More security initially means more effort for developers and companies. Those who have relied on installation scripts, Git dependencies, or external package sources until now must check their build and CI/CD processes and approve the necessary components. GitHub advises switching to npm 11.16.0 or newer now and evaluating the warnings issued.

However, npm v12 does not solve all JavaScript supply chain problems. Malicious code that is directly in the application code of a package will continue to reach systems. Compromised maintainer accounts, typosquatting, or vulnerable libraries are also not caught by the new approach. Nevertheless, for the security of development and build environments, it is likely to be one of the most far-reaching changes in recent years.

GitHub provides further details in the changelog entry on upcoming breaking changes for npm v12.

(fo)