npm 12 Disables Install Scripts by Default to Reduce Supply Chain Risk

# npm 12 Disables Install Scripts by Default to Strengthen Supply Chain Security

GitHub has taken a significant step to reduce supply chain attack surface by releasing npm version 12 with automatic script execution disabled by default. The new package manager version represents a fundamental shift in how Node.js dependencies are handled, requiring developers to explicitly approve and allow scripts before they run during installation—a move designed to combat the growing wave of software supply chain compromises.

The announcement also includes restrictions on granular access tokens (GATs), eliminating their ability to bypass two-factor authentication (2FA) for sensitive operations. Combined with similar security hardening in the broader JavaScript ecosystem, these changes signal that npm is moving away from a "trust by default" model that has enabled numerous attacks over the past several years.

## The Threat Landscape

Software supply chain attacks have become increasingly sophisticated and impactful. Malicious actors inject malicious code into open-source packages or compromise maintainer accounts to distribute trojans to millions of developers. Once compromised packages are installed, the install scripts (preinstall, install, postinstall) provide a convenient execution vector to drop backdoors, steal credentials, or establish persistent access.

The attack pattern is straightforward:

Notable precedents include:

By making script execution opt-in, npm 12 fundamentally changes this calculus. Attackers can still try to distribute malicious packages, but the scripts won't execute silently.

## What Changed in npm 12

npm 12 introduces three major behavioral changes that flip the default security stance:

### Install Scripts Disabled by Default

The allowScripts setting now defaults to off. This means:

Previously, developers had to explicitly disable scripts. Now they must explicitly enable them. This reverses the risk calculation entirely—a developer who adds a dependency now sees a warning about pending scripts and must take deliberate action to approve them.

### Git Dependencies Require Explicit Approval

The --allow-git flag now defaults to none. Remote Git dependencies—either direct or transitive—are no longer resolved automatically. Developers must explicitly approve Git-based dependencies using the flag or configuration.

### Remote URL Dependencies Blocked

The --allow-remote flag also defaults to none. Dependencies served as remote HTTP(S) tarballs are now blocked unless explicitly permitted. This prevents scenarios where a compromised registry or man-in-the-middle attacker redirects package fetches to malicious sources.

### The Approval Workflow

To review and approve trusted scripts, developers must run:

npm approve-scripts --allow-scripts-pending

This command generates an allowlist that gets committed to package.json, creating an auditable record of which scripts a project permits. The approach mirrors how supply chain security is handled in more cautious environments: explicit approval, commit to version control, and human review.

## Granular Access Tokens Restrictions

Parallel to the install script changes, npm is imposing strict limits on granular access tokens (GATs)—API tokens designed for specific, narrow permissions.

### The 2FA Bypass Problem

GATs were originally intended to provide fine-grained access control. However, they contained a critical security flaw: they could bypass two-factor authentication (2FA) for sensitive operations. This defeated the purpose of 2FA, allowing attackers who compromised a token to perform account takeover actions without the second factor.

### New Restrictions

Starting early August 2026, GATs configured to bypass 2FA will no longer permit:

### Publishing Token Changes

The second phase, effective January 2027, restricts direct package publishing via GATs. Instead:

The rationale is sound: publishing is a high-impact action. Requiring a human in the loop—even for automated pipelines—ensures that no token compromise can unilaterally push malicious code to the registry.

## Broader Ecosystem Context

npm's changes align with hardening efforts across the JavaScript ecosystem. pnpm 11.10 introduced a complementary security feature: a new _auth setting for registry authentication that travels with its host.

The security benefit:** Credentials and the registry they belong to are bundled together. pnpm reads `_auth` only from environment variables or global configuration—never from project files like `pnpm-workspace.yaml` or `.npmrc`. This closes a common attack vector: **tampering with a repository's configuration files to redirect a valid token to a malicious registry.

This layered approach—authenticating to the correct host by design—removes a direct path to credential theft that attackers have exploited in real incidents.

## Implications for Organizations

### Immediate Actions Required

For teams upgrading to npm 12:

1. Run a test installation with the new version

2. Review warnings about pending scripts

3. Audit each script to determine if it's legitimate

4. Generate and commit the allowlist

5. Test the build pipeline end-to-end

Projects with dozens of dependencies may discover hundreds of pending scripts. This is intentional—visibility precedes informed decision-making.

For maintainers using automated publishing:

### Long-Term Security Posture

These changes represent a maturation of supply chain security in the npm ecosystem. Organizations should:

| Action | Benefit |

|--------|---------|

| Audit all active tokens for unnecessary permissions | Reduce blast radius of token compromise |

| Enable 2FA on all npm accounts with publish rights | Prevent account takeover via compromised tokens |

| Require approval workflows for production publishes | Human review gates malicious releases |

| Use allowlists for install scripts | Visibility into automatic code execution |

| Migrate to OIDC where possible | Eliminate long-lived secrets entirely |

## Recommendations

For Developers:

For Security Teams:

For Open-Source Maintainers:

---

## HackWire Analysis

npm 12's move toward opt-in script execution is an overdue acknowledgment that install-time code execution is fundamentally risky. For years, the package manager ecosystem has operated under a "trust by default" model that prioritized convenience over security. Attackers exploited this ruthlessly.

What makes these changes significant is not that they introduce new technical capabilities—developers could already disable scripts—but that they change the default posture for the 99% of developers who don't explicitly configure anything. Every developer upgrading to npm 12 will immediately see what automatic code runs in their projects. Many will be surprised.

The GAT restrictions deserve equal attention. 2FA-bypass tokens were a security theater failure: they made accounts *look* more secure (users enable 2FA) while actually undermining it (tokens can bypass 2FA). Removing this escape hatch is pragmatic, though it forces organizations to rethink automation architectures. This is good—it should be uncomfortable to move highly-privileged publishing off of long-lived secrets.

The question now is adoption velocity. Enterprises with legacy CI/CD pipelines may resist upgrading immediately, and npm's staged rollout (August 2026 for GATs, January 2027 for publish restrictions) gives organizations time to migrate. But this also means supply chain risk remains non-zero during the transition window. Attackers will likely target older npm versions where these protections don't apply.

Organizations should treat the January 2027 deadline as genuine and begin OIDC migration planning now. Waiting until Q4 2026 to start will only create last-minute panic. — *HackWire Editorial*

---

## Related Coverage