npm Install Scripts Opt-In RFC:
The End of npm's Most Dangerous Default

What the RFC Proposes

On May 15, 2026, GitHub engineer Jamie Magee published an RFC proposing a fundamental change to how npm handles install scripts (preinstall, install, postinstall, prepare). The core idea is simple: instead of running dependency install scripts automatically, npm should require explicit opt-in from the developer.

The RFC was featured in JavaScript Weekly Issue 786 (May 19, 2026) and Node Weekly Issue 625 (May 21, 2026), where it was described as a long-overdue security improvement for the npm ecosystem. The proposal directly addresses a glaring asymmetry in the JavaScript package manager landscape: npm is the only major package manager that runs dependency install scripts by default.

Under the proposed change, when a developer runs npm install <package> and that package has install scripts, npm would either:

• Prompt the developer for approval (per-package or per-session), or
• Skip scripts entirely unless the package is listed in an allowedScripts configuration, or
• Require an explicit --allow-scripts flag to run them

The exact UX mechanism is still under discussion, but the direction is clear: zero trust by default for install scripts.

Why This Matters: The Install Script Attack Surface

Install scripts are the primary attack vector in npm supply chain attacks. When you run npm install, any package in your dependency tree can execute arbitrary code through lifecycle scripts — before the package source is even fully installed. This is not a theoretical concern.

The Mini Shai-Hulud Case Study

The Mini Shai-Hulud worm (April–May 2026) compromised over 170 npm packages across TanStack, Mistral AI, UiPath, and other major ecosystems by injecting credential-stealing code through preinstall hooks. The attack worked because npm ran these scripts automatically — no user confirmation, no warning, no audit trail.

The malware used a preinstall hook to download and execute a Bun-based payload that stole GitHub tokens, npm credentials, cloud keys, and CI/CD secrets. It then used those credentials to publish compromised versions of other packages, creating a worm-like propagation chain. The entire attack vector depended on npm's default behavior of running scripts without question.

The Scale of the Problem

Install script attacks are not rare. Security researchers have documented hundreds of cases where malicious packages used postinstall or preinstall hooks to:

• Steal credentials — GitHub tokens, npm tokens, cloud provider keys, environment variables
• Exfiltrate data — Package files, configuration, application source code
• Establish persistence — Backdoors in CI/CD pipelines, modified .bashrc or shell profiles
• Propagate — Using stolen tokens to publish compromised versions of other packages
• Cryptomining — Running miners on developer machines or CI runners

How Other Package Managers Handle This

npm is the outlier. Every other major package manager treats install scripts with suspicion. Here's how they compare:

The takeaway is clear: pnpm already has the exact mechanism npm is proposing, and it has not broken the ecosystem. Deno and Berry prove that a different model is viable. npm's proposed change brings it in line with the rest of the ecosystem — finally.

What Developers Should Do NOW

Even before the RFC lands (RFCs at npm historically take months to years to implement), there are concrete steps you should take today.

1. Set ignore-scripts=true in Your .npmrc

This is the single most impactful security measure you can take:

# ~/.npmrc or .npmrc in project root
ignore-scripts=true

With this setting, npm will download packages but not execute any install scripts. You can then selectively allow scripts for trusted packages:

# Run install normally for a specific package
npm install some-package --ignore-scripts=false

Or, use a more granular approach with npm query to inspect which packages have scripts before installing:

# Use npq (npm install qualifier) to audit before installing
npx npq install some-package

2. Audit Your Current Dependencies for Install Scripts

You may already have packages that rely on install scripts. Find them with:

# List all packages with lifecycle scripts
npx npm-query-lifecycle-scripts

# Or manually check package.json files
find node_modules -name "package.json" -exec grep -l '"postinstall"\|"preinstall"\|"prepare"' {} \;

Common legitimate uses of install scripts include:

• Native binaries — sharp, node-gyp, esbuild compile or download platform-specific binaries
• Code generation — prisma generate, graphql-codegen
• Polyfill injection — Some legacy packages inject polyfills on install
• Postinstall notifications — Displaying funding messages or setup instructions

3. Harden Your CI/CD Pipeline

In CI/CD, always use strict mode:

# CI/CD best practice — never run install scripts
npm ci --ignore-scripts

# Then build with explicit steps
npm run build

This ensures that no install script can execute in your build pipeline. If a package requires a script to function (e.g., a binary download), you should pre-download the binary or switch to a package that ships pre-built binaries.

Migration Guide for Package Authors

If you maintain an npm package that uses install scripts, the RFC affects you directly. When npm makes scripts opt-in, developers may not approve your scripts — and your package will break silently.

Audit Your Own Install Scripts

Check your package.json for any lifecycle scripts:

{
  "scripts": {
    "postinstall": "node postinstall.mjs",
    "preinstall": "node setup.mjs",
    "prepare": "husky"
  }
}

Ask yourself: does this script actually need to run on install? In most cases, the answer is no.

Migrate to Safer Alternatives

Here's a practical migration path for common install script use cases:

Add an allowedScripts or Documentation Path

If your package legitimately needs an install script (and after audit, you're certain), document it clearly and provide an allowedScripts configuration snippet that developers can copy. For example:

# .npmrc — add this to your project root
allowedScripts[my-package]=true

This makes the trust decision transparent and reproducible — the same way you'd document a build step.

The Broader Shift: npm Security Improvements in 2026

The install scripts RFC is not happening in isolation. 2026 has been a transformative year for npm security. The ecosystem is undergoing the most significant hardening in its history.

npm Staged Publishing (npm 11.15.0)

Announced in the same week as the RFC, npm's new staged publishing model provides a review period before packages go live. This prevents attackers from publishing malicious versions that would be immediately available to millions of developers — a key mitigation for the "publish and exploit" pattern used in supply chain attacks.

npm 12.0 Prerelease

A prerelease of npm 12.0 has been published, signaling major architectural changes. While the exact changelog is emerging, the version bump from 11.x indicates significant breaking changes — likely including the install scripts RFC or its early implementation.

Script Security GA (February 2026)

npm's script security feature, which provides warnings about packages with lifecycle scripts during installation, graduated to General Availability in February 2026. This was the first step in the current hardening trajectory. The RFC is the logical next step: from warning about scripts to blocking them by default.

2FA Enforcement for High-Impact Packages

npm now enforces two-factor authentication for maintainers of high-download packages, closing the account takeover vector that has been used in several supply chain attacks. This complements the install scripts RFC by addressing a different part of the attack surface: who can publish, rather than what runs on install.

A Practical Guide: Auditing Your Dependencies for Install Script Usage

Here's a step-by-step workflow to audit your project today, regardless of the RFC's status:

1. Check your current .npmrc — Run npm config ls to see if ignore-scripts is already set. If not, add it.
2. List packages with install scripts — Use npx npm-query-lifecycle-scripts to see every package in your tree that defines lifecycle scripts.
3. Evaluate each script — For every package with a script, check its source code and documentation. Ask: Is this script necessary? Is it documented? Can it be replaced?
4. Test with scripts disabled — Set ignore-scripts=true temporarily and run your full test suite. Any failures reveal packages that genuinely need scripts. Document these exceptions.
5. Create an allowed-scripts policy — For packages that legitimately need scripts, create a documented allowlist that your team can review and maintain.
6. Add CI checks — Add a CI step that warns when new packages with install scripts are added to the dependency tree, using tools like socket.dev or snyk.
7. Stay informed — Follow the RFC discussion at github.com/npm/rfcs. The discussion thread includes valuable input from maintainers of packages that depend on install scripts.

For secure web application development, get in touch

FAQ

Security Starts with Awareness

The npm install scripts opt-in RFC represents a fundamental shift in how the JavaScript ecosystem approaches security. It acknowledges that the default behavior that made npm successful — install scripts running automatically — has become its greatest weakness.

As developers, we've been trusting install scripts by default because there was no alternative. The RFC changes that. It moves the ecosystem from "trust by default, audit by exception" to "audit by default, trust by exception". That's the right direction.

If you're building a web application and want a developer who takes dependency security seriously — not as an afterthought but as a built-in practice — reach out to me. I'm a full-stack developer with 20+ years of experience, and I build every project with --ignore-scripts, pinned dependencies, lockfile integrity checks, and automated security scanning from day one.