When npm Scripts Turn Into Silent Threats

Node.js powers a staggering amount of modern software, from microservices to front‑end tooling. Yet the very mechanism that makes npm so powerful—its ability to run arbitrary scripts during installation—also opens a door to a host of subtle attacks. A recent analysis from mbullington.net lays out the problem and argues that the only viable fix is to move sandboxing from the runtime to the operating system.

The npm Post‑Install Problem

Every time you run npm install, the package manager executes a post‑install script defined in the package’s package.json. These scripts can run any shell command, install binaries, or even pull code from the internet. The npm documentation warns that these scripts run with the same privileges as the user, meaning they can:

  • Read or modify files in the user’s home directory ($HOME).
  • Add entries to .bashrc or other shell configuration files.
  • Exfiltrate private keys, tokens, or any data stored locally.

“So much of ‘traditional’ security relies on if an application can get root, change your system etc… to say absolutely nothing about what’s sitting in your $HOME directory.” – mbullington.net

Because npm packages are distributed through a public registry, the risk is not theoretical. A malicious maintainer could embed a script that silently copies ~/.ssh/id_ed25519 and sends it to a remote server. Even a benign package could inadvertently expose sensitive data if its script is misconfigured.

Deno’s Permission Model: A Partial Remedy

Deno was designed with security in mind. By default it denies all file system, network, and environment access. Permissions are granted explicitly via command‑line flags:

# Deny by default; allow reading the HOME directory
$ deno run --allow-env --allow-read=HOME runner.ts

The runtime checks an allowlist in Rust; if a requested operation is not on the list, the call is denied. This model forces developers to think about what a script needs before granting access.

However, Deno’s sandbox is application‑level. It relies on the correctness of V8 and its own Rust wrappers. If a memory bug or an escape primitive exists, the sandbox can be bypassed. Moreover, Deno’s --allow-run flag lets a script spawn arbitrary binaries (e.g., esbuild), which can then perform privileged operations outside the sandbox’s control.

“Deno makes the assumption its JavaScript engine, V8, and its application code is perfect—free of memory bugs. If this assumption is violated, then you can break the sandbox.” – mbullington.net

The Case for OS‑Level Sandboxing on macOS

macOS offers sandbox-exec, a deprecated but still effective command that enforces a profile describing what a process may read, write, or network. Profiles are written in a Scheme‑like syntax and can be found under /System/Library/Sandbox/Profiles/.

;; Example profile: bsd.sb
(version 1)
(debug deny)
(import "system.sb")

(allow file-read-metadata)
(allow file-read-data file-write-data
  (regex
    #"/\.CFUserTextEncoding$"
    #"^/usr/share/nls/"
    #"^/usr/share/zoneinfo /var/db/timezone/zoneinfo/"
  ))

Running a Node.js process under this profile is as simple as:

$ sandbox-exec -f /System/Library/Sandbox/Profiles/bsd.sb node index.js

While the example above is minimal, it demonstrates that OS‑level isolation can be applied to any binary, including JavaScript runtimes. By combining this with Deno’s fine‑grained permissions, developers could achieve a double‑layer defense: the runtime denies unwanted operations, and the OS refuses any attempt to circumvent those restrictions.

Why Node and NPM Must Embrace OS‑Level Sandboxing

  • Untrusted Dependencies – The npm ecosystem is vast and open. Even with strict linting, a malicious or compromised package can slip through.
  • Complex Attack Surface – Post‑install scripts can interact with the system in ways that are hard to predict or audit.
  • Limited Runtime Controls – Node’s current permission model is rudimentary; it lacks the granularity of Deno’s flags and does not enforce OS‑level boundaries.

Adopting sandbox-exec (or analogous mechanisms on Linux and Windows) would force every Node process to run within a sandbox defined by the platform. This would mitigate the risk of a compromised package leaking secrets or executing arbitrary binaries.

“Please let me sandbox NPM.” – mbullington.net

The Road Ahead

  • Node.js Core – Integrate sandbox flags into the runtime, allowing developers to opt‑in to OS‑level isolation.
  • Package Manager – npm could offer a --sandbox flag that automatically wraps installation scripts in a sandbox profile.
  • Community Tools – Projects like npx sandbox could provide a drop‑in replacement for npm install that enforces isolation.

Until such measures are in place, developers should treat every package as potentially malicious and consider running critical workloads inside containers or dedicated VMs. The security of the JavaScript ecosystem hinges on acknowledging that trust is a privilege, not a default.

Source: https://mbullington.net/weblog/please-let-me-sandbox-npm/