In npm CLI versions before 6.13.3, a package could use the bin field of its manifest to create symlinks pointing to files outside node_modules during installation. That bypassed the ignore-scripts setting. The fix is to run a current npm and to treat installing any package as running someone else's code.
What was the vulnerability?
The GitHub Advisory Database records CVE-2019-16776 as an npm symlink reference outside of node_modules. Versions of the npm CLI prior to 6.13.3 were affected. According to the advisory, a package could create symlinks to files outside the node_modules folder through the bin field upon installation. A properly constructed bin entry would let a publisher create a symlink pointing at arbitrary files on the user's system.
Only files that the user running the install could access were at risk. That still covers a lot: a developer's home directory, shell startup files and credentials stored with user permissions. On a CI runner, it covers the workspace and anything the job token can reach.
The advisory also notes that the same effect remains possible through install scripts, but this flaw bypassed a user who had turned on the ignore-scripts option, which many people use as a safety measure.
Why is this a "filesystem takeover" class of bug?
The common thread is path confusion. Package managers unpack archives and create links and files under a directory they consider theirs. If the manager trusts names, paths or link targets from the package, then a package can reach outside its folder and write or point to files elsewhere.
The general lesson goes beyond npm. Any tool that extracts untrusted archives or follows links from untrusted metadata needs to confirm the final resolved path remains inside the intended directory.
What does ignore-scripts really give you?
It stops lifecycle scripts such as preinstall and postinstall from running. That removes one big route to code execution at install time, and it is worth using. But the advisory shows it is not a complete shield. A bug in the manager itself can do harm without any script running, and a package you install usually executes when you import it anyway.
So think of ignore-scripts as one layer. Others include a current package manager, a lockfile, and an install environment with little to steal.
A constructed example
A developer installs a utility package on a laptop running an old npm release bundled with a long out of date Node.js. The package's bin entry points a link at a file in the developer's home folder. The next time a command is run through that link, content chosen by the publisher is used. The developer had set ignore-scripts and felt safe. The root cause was neither the setting nor the developer, but an unpatched tool.
How do you reduce the risk?
Update the toolchain. Check the npm version in developer images and CI. Anything below 6.13.3 is affected by this specific flaw, and current releases carry later fixes.
Use ignore-scripts, then allow the exceptions you need. Keep it as default in CI.
Install in a throwaway environment. Use a container or an ephemeral runner with no secrets mounted during install. Pass credentials only to later steps that need them.
Run as a low privilege user. The advisory notes only files accessible to the installing user are affected, so smaller access means smaller damage.
Use a lockfile and npm ci. It does not stop a flawed package manager, but it stops surprise versions.
Scan what you install. Dependency scanning with reachability analysis tells you which flagged packages your code uses.
How to check or apply this
- Run
npm -von developer machines and in CI images. - Upgrade anything old, along with the Node.js release that bundles it.
- Set ignore-scripts in project and CI configuration.
- Run installs without secrets in the environment.
- Commit the lockfile and install with
npm ci. - Review new packages with bin entries or install scripts before adding them.
Quick check
Which npm version fixed CVE-2019-16776?
According to the GitHub advisory, 6.13.3.
Is it safe to install a package if scripts are disabled?
Safer, not safe. Package manager bugs and the package code itself can still cause harm, so use layers.
Sources
- GitHub Advisory: npm symlink reference outside of node_modules (CVE-2019-16776)
- NVD: CVE-2019-16776
- npm Docs: npm install
- npm Docs: npm ci
Last reviewed: 18 October 2026.