> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# NPM 12 Will Change Script Execution Behavior to Prevent Supply Chain Attacks
- URL: https://f4n6.co.uk/security-feed/npm-12-will-change-script-execution-behavior-to-prevent-supply-chain-attacks/
- Published: 2026-06-14T01:25:00.000Z
- Updated: 2026-06-14T01:25:00.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

GitHub has announced that npm v12 (expected July 2026) will change three security-focused defaults to disrupt the supply-chain attack pattern repeatedly abused in the npm ecosystem: lifecycle scripts (`preinstall`, `install`, `postinstall`) from dependencies will no longer execute by default; the `--allow-git` flag will default to off, closing the path where a malicious `.npmrc` overrides the Git executable; and `--allow-remote` will default to `none`, blocking dependency downloads from remote URLs. The change is a direct response to recent incidents attributed to **TeamPCP** and the **Shai-Hulud** self-replicating worm, which abused automatic script execution during `npm install` to compromise developer machines and CI runners. For EMEA financial services firms running JavaScript/Node.js workloads, this is a forced breaking change requiring proactive allowlist curation before upgrade — not a passive patch — and it materially reduces the largest code-execution surface in the npm ecosystem.

## 2\. Regulatory framing

| Article                                                         | Trigger (the fact in this item)                                                                                                                                                                                      | Practical impact                                                                                                                                                                        |
| --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 28 — ICT third-party risk — general principles        | npm is a critical third-party ICT service provider for any in-house JavaScript/Node.js development; the change alters the threat surface of that dependency.                                                         | Firms must reassess their ICT third-party risk treatment of npm and document the new default-deny script execution posture in their third-party risk register.                          |
| DORA Art. 29 — Preliminary assessment of ICT concentration risk | npm is a single-vendor concentration point for the JavaScript ecosystem; the change affects how that concentration risk is technically mitigated.                                                                    | The new defaults reduce concentration risk by removing the automatic code-execution surface; firms should record this as a compensating control in their concentration-risk assessment. |
| NIS2 Art. 21(2)(d) — supply chain security measures             | The change is a supply-chain security control applied at the package-manager layer, addressing the same attack class (transitive dependency script execution) that NIS2 supply-chain duties require firms to manage. | Firms must incorporate the new defaults into their supply-chain security policy and ensure developer/CI pipelines are configured to use the allowlist mechanism before upgrade.         |

## 3\. Technical analysis & attack chain

This advisory describes a defensive control change, not an active incident. The "attack chain" below is the historical pattern the change is designed to disrupt.

### Attack chain (historical pattern being mitigated)

1. **Initial access — malicious package publication.** Attacker publishes a malicious package (or compromises a legitimate maintainer account) and waits for victims to `npm install` it directly or as a transitive dependency.
2. **Code execution via lifecycle script.** During `npm install`, npm automatically executes `preinstall`, `install`, or `postinstall` scripts declared in the dependency's `package.json`. The attacker's payload runs with the privileges of the developer or CI runner.
3. **Native-build abuse via `binding.gyp`.** Packages containing a `binding.gyp` file with no explicit install script trigger a native node-gyp build at install time. The Shai-Hulud Miasma attacks weaponised this exact mechanism — a malicious `binding.gyp` was used to achieve code execution even when an explicit install script was absent.
4. **Git-binary override via `.npmrc`.** A malicious `.npmrc` shipped with a Git-sourced dependency could override the Git executable path, achieving arbitrary code execution even when `--ignore-scripts` was set.
5. **Remote-URL dependency fetch.** HTTPS tarball dependencies (direct or transitive) were resolved at install time, providing an additional code-execution surface.
6. **Persistence and propagation.** The Shai-Hulud worm is described as self-replicating — once executed on a developer machine or CI runner, it propagates to additional packages and repositories, as seen in the recent incidents involving over 5,500 GitHub repositories and 32 Red Hat npm packages.

### Technical specifics relevant to defenders

- **Affected versions and rollout.** The three defaults change in npm v12 (expected July 2026). The same controls have been available as opt-in flags since npm v11.10.0 (February). The current stable release is npm v11.16.
- **Lifecycle scripts blocked by default.** `preinstall`, `install`, and `postinstall` scripts from dependencies will not run unless explicitly permitted. The allowlist is written to `package.json` and is pinned to the installed version of each package by default.
- **Git dependency resolution blocked.** Git dependencies (direct or transitive) will no longer be resolved at `npm install` unless explicitly allowed. This closes the `.npmrc`\-override-Git path even when `--ignore-scripts` is set.
- **Remote URL dependency fetch blocked.** HTTPS tarball dependencies (direct or transitive) will no longer be resolved. The `--allow-remote` flag (available since v11.15.0) can re-enable this.
- **Native node-gyp builds affected.** Packages with a `binding.gyp` and no explicit install script will be blocked from compiling at install time. This is the specific vector used by Shai-Hulud Miasma.
- **Prepare scripts affected.** `prepare` scripts from git, file, and link dependencies are also blocked.
- **Pre-upgrade workflow.** Developers should run `npm approve-scripts --allow-scripts-pending` to enumerate scripts, approve trusted packages, and commit the resulting `package.json` allowlist. On npm v11.16.0+, warnings will fire when an install routine executes scripts.
- **Configuration gotchas.** The existing `ignore-scripts` flag does not support an allowlist and will override `allow-scripts` if set to `true` — it must be removed to enable approved scripts. `allowScripts` exists in npm v11 but is advisory only and does not enforce.
- **Native modules requiring script approval.** Native modules that compile on install, testing tools that fetch binaries via postinstall (Playwright, Puppeteer), and Electron (Chromium wrapper) all require explicit script approval to function.
- **Ecosystem context.** pnpm v10+, Yarn Berry, Bun, and Deno already block dependency install scripts by default; npm is the last major package manager to do so.

### Unconfirmed / single-sourced claims

Attribution to **TeamPCP** and the **Shai-Hulud** worm is reported by SecurityWeek and The Register but no MITRE threat-actor profile is available in the verified reference data for this item; treat the attribution as **unconfirmed**. The claim that "all the malware can move from the install script to the module itself where it will inevitably still be run" is a single-developer opinion quoted by The Register and is not a confirmed technical outcome.

## 4\. Mitigation & containment

### P1 — within 24 hours (preparation before npm v12 lands)

1. **Inventory npm usage.** Identify all developer machines, CI runners, and build pipelines that invoke `npm install` against JavaScript/Node.js projects. Document the npm version currently in use.
2. **Upgrade to npm v11.16.0 or later** on all developer machines and CI runners. This enables warnings when install routines execute scripts and unlocks the `npm approve-scripts` workflow.
3. **Run `npm approve-scripts --allow-scripts-pending`** in each project to enumerate which packages declare lifecycle scripts. Review the list, approve trusted packages, and commit the resulting `package.json` allowlist to source control.
4. **Remove `ignore-scripts: true`** from `.npmrc` and any environment-variable configuration if `allow-scripts` is to be used — `ignore-scripts` overrides `allow-scripts`.

### P2 — within 72 hours (harden defaults ahead of upgrade)

1. **Set the new defaults in `.npmrc` or via environment variables** on npm v11.16 to prepare projects for v12: - `allow-scripts=true` (with allowlist in `package.json`) - `allow-git=false` \- `allow-remote=none` \- `min-release-age=<N days>` (introduced in v11.10.0; blocks newly published malicious packages)
2. **Document the allowlist policy** in the project's supply-chain security policy: which packages are trusted, who approves additions, and how exceptions are recorded.
3. **Update CI/CD pipeline configuration** to ensure the new defaults are applied at runner level (e.g., via `.npmrc` in the build image or environment variables in the pipeline definition).

### P3 — within 7 days (upgrade and validate)

1. **Upgrade to npm v12** when released (expected July 2026). Validate that all native modules (node-gyp builds), Playwright, Puppeteer, Electron, and any other tool that fetches binaries via postinstall are present in the allowlist.
2. **Re-test CI pipelines** end-to-end to confirm no unexpected script execution warnings or failures.
3. **Update the third-party risk register** (per DORA Art. 28) and concentration-risk assessment (per DORA Art. 29) to record the new default-deny posture as a compensating control.

## 5\. Indicators of compromise

No indicators of compromise available in the source material.

## 6\. Detection

Insufficient indicators to author detection rules.

## 7\. Sources

- SecurityWeek — *NPM 12 Will Change Script Execution Behavior to Prevent Supply Chain Attacks* — https://www.securityweek.com/npm-12-will-change-script-execution-behavior-to-prevent-supply-chain-attacks/ — 2026-06-13
- The Register — *GitHub pulls pin on npm's auto-run scripts* — https://www.theregister.com/devops/2026/06/10/github-pulls-pin-on-npms-auto-run-scripts/5253453 — 2026-06-10
- BleepingComputer — *GitHub announces npm security changes to tackle supply-chain attacks* — https://www.bleepingcomputer.com/news/security/github-announces-npm-security-changes-to-tackle-supply-chain-attacks/ — 2026-06-13

## 8\. Adverse Trace position

**Severity: Informational / Pre-emptive Control Change.** This is not an active threat but a forced breaking change to a critical third-party dependency manager. The bottom-line risk for EMEA financial services firms is operational, not adversarial: any project that has not curated an allowlist before the npm v12 rollout will fail to build or deploy, and any project that does not remove `ignore-scripts: true` will silently lose the ability to run approved scripts. Firms running JavaScript/Node.js workloads in production or CI should treat the v12 upgrade as a planned change with a defined cutover date, not a routine patch. Adverse Trace will monitor the npm v12 release and update this advisory with concrete migration guidance and any post-release incidents.

---

[Read the original source →](https://www.securityweek.com/npm-12-will-change-script-execution-behavior-to-prevent-supply-chain-attacks/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*