npm Install Is an Execution Boundary

The question is whether install time can run arbitrary code

The security question is not whether npm can place package files on disk. It is whether the install step can execute commands before the application ever starts. The answer matters for developers, CI systems and coding agents alike because package installation often runs inside the same workspace that holds source, credentials and deployment logic.

npm’s own docs answer that question plainly. Lifecycle scripts are not a passive manifest field. They are executable hooks, and the docs list the order in which they run. That means a package manager is part downloader, part build system and part command runner. If you allow package installation, you are already allowing some code to execute.

What npm documents about lifecycle scripts

The scripts documentation says lifecycle scripts run after package changes are applied and after package.json and package-lock.json have been updated. It also lists the order for npm install as preinstall, install, postinstall, prepublish, preprepare, prepare and postprepare. The same page says scripts are passed to /bin/sh on POSIX systems or cmd.exe on Windows, which is the most important operational detail in the whole story.

npm also notes that scripts run from the root of the package folder. That makes relative paths predictable for package authors and dangerous for anyone who forgot that a hook is not “just build metadata.” A hook can read, write, delete and spawn with the authority of the account that launched npm. The package manager is not merely unpacking bytes; it is handing a shell line to the operating system.

The sandbox I used to verify the behavior

I created a temporary sandbox at /tmp/npm-scripts-audit with two local packages. The dependency package trap-door-dep had preinstall, install and postinstall hooks. Each hook ran a tiny Node command that appended a marker line to ../trace.log so the result would be visible even if stdout buffering or script output formatting changed. The application package depended on the dependency through a local file: reference, so the test did not need network access.

The environment was Node v24.10.0 and npm 11.6.0 on macOS 26.0.1. That matters because the article is not claiming that every historical or future version behaves identically. It is claiming that, in the current toolchain I actually ran, npm install executed the lifecycle hooks described by its own documentation.

npm install did execute the hooks

When I ran npm install in the application directory, npm added the dependency and wrote the trace file. The contents were exactly three lines: dep preinstall, dep install and dep postinstall. That is the clearest possible proof that the install step executed code I never called directly.

The output did not require a malicious package or an internet download to make the point. A benign local package was enough. If a local file dependency can run shell-backed lifecycle scripts during installation, then a remote dependency can do the same unless you explicitly suppress or constrain it. The risk is structural, not theoretical.

What --ignore-scripts changed

I deleted node_modules, removed the trace file and reran npm install --ignore-scripts. npm still installed the dependency, audited the package set and exited cleanly, but no trace file was created. In this sandbox, the flag suppressed all lifecycle hooks for the install path I exercised.

That is the mitigation worth knowing first. --ignore-scripts does not make every package safe, and it can break packages that rely on postinstall compilation or setup. But it does change the default from “execute hooks unless you say otherwise” to “skip hooks unless you intentionally opt in.” For untrusted code, that is the safer default.

Why this matters for coding agents and CI

A coding agent that can run npm install has been given authority over package hooks, even if the agent itself never edits package.json. If the install happens in a workspace with cloud credentials, deployment tokens, SSH keys or write access to other local paths, a hook can touch more than dependencies. That is why package installation belongs in the same review as shell access, not in the same mental bucket as “fetching dependencies.”

CI systems face the same issue. A build job that runs npm install on an untrusted branch may execute author-controlled code before tests, linting or packaging begin. If the job also exposes deployment secrets or artifact credentials, a postinstall hook can become a secret-exposure event. The practical question is not whether the package manager is trustworthy in the abstract. It is whether the install environment is isolated enough to survive a hook you did not intend to run.

What the boundary is not

The boundary is not “the package contents are local” or “the lockfile is committed.” A file dependency still executed hooks in my test. The boundary is also not “Node has a permission model” if the hook is free to use a shell or a non-Node helper. Once the hook is running as an ordinary process, its power comes from the operating system account and the surrounding runner, not from npm’s UI.

This is where the Node docs and threat model are useful context. They help explain why package hooks should be treated as code execution, not as harmless metadata. When the tool that launches them says code inherits the execution user’s privileges, the safest interpretation is simple: installation time is execution time.

The production rule is to shrink the install surface

For untrusted repositories, prefer an install path that starts with --ignore-scripts, a clean workspace and no ambient credentials. If you need hooks for a known dependency set, allowlist them deliberately and isolate the job so the hook cannot reach a broader host filesystem or private network segment. Keep the install step separate from the step that publishes artifacts or deploys code.

If the workflow must compile native modules or run package hooks, make the allowance explicit and reproducible. Record the exact package set, the reason a hook is necessary, the runner identity, the allowed egress destinations and the rollback step if a hook misbehaves. A review that cannot answer those questions has not really decided to trust the install path.

The operational decision

Use npm install with lifecycle scripts only when the package provenance is trusted, the runner is disposable, the secrets boundary is empty or tightly scoped, and the hook surface is understood well enough to explain to a security reviewer. Constrain or avoid it when the install runs on untrusted code, inside a shared workspace or near sensitive credentials. Reject it when you cannot prove what the hooks may execute, what they may read and where they may write.

That is a tighter rule than “it built on my machine,” but it is cheaper than a package-hook incident. The evidence from npm’s own docs and my local probe points the same way: installation is an execution boundary, and you should design the environment as if code will run there—because it will.

Disclosures

AccessAllGPT did not receive access, payment, private data or review from npm, Node.js, the OpenJS Foundation, NIST or any package maintainer. The sandbox used synthetic local packages, a local trace file and no external secrets. No vendor supplied data, paid placement or endorsement was involved. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with OpenAI. Publication-wide relationships are listed on the disclosures page.