The npm blog has been discontinued.
Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog.
Package install scripts vulnerability
Disclaimer: we had been told this vulnerability would be disclosed on Monday, not Friday, so this post is a little rushed and may be edited later.
As disclosed to us in January and formally discussed in CERT vulnerability note VU#319816, it is possible for a maliciously-written npm package, when installed, to execute a script that includes itself into a new package that it then publishes to the registry, and to other packages owned by that user.
npm cannot guarantee that packages available on the registry are safe. If you see malicious code on the registry, report it to support@npmjs.com and it will be taken down.
How to protect yourself
If you are installing a package that you do not trust, you can avoid this vulnerability by running
npm install
If you wish to never run scripts at install time, you can instead run
npm config set ignore-scripts true
Either or both of these steps will prevent you from spreading a worm at install time.
If you install a package that contains malicious code and then execute it (e.g. by require()ing it into your code) it could still perform malicious actions. You should not execute any software downloaded from the Internet if you do not trust it, including software downloaded from npm.
Why does this vulnerability exist?
Installation and other lifecycle scripts are a useful tool that allows package authors to set up configuration, compile binary dependencies, and perform other actions that make using npm packages convenient.
On balance, it’s npm’s belief that the utility of having installation scripts is greater than the risk of worms. This is a tradeoff that we will continue to evaluate.
Is this new?
Package scripts have been a feature of npm since the very beginning. The implications of this feature were clear from the start, but not everyone in the ever-expanding npm community is fully aware of them. Disclosures of this kind are helpful for that reason.
What happens if a worm is published?
You should report malicious packages to support@npmjs.com. Per our terms of service, they will be taken down. Authors publishing malicious code to the registry may be banned from the registry.
npm monitors publish frequency. A spreading worm would set off alarms within npm, and if a spreading worm were identified we could halt all publishing while infected packages were identified and taken down.
Can npm scan packages for worms?
npm is working with security vendors to introduce enhanced security vulnerability scanning and mitigation services. This work is underway but not yet ready.
At root, it is impossible to guarantee that any new piece of software is benign short of manually inspecting it, as mobile app stores do. The work required to do this would be prohibitively expensive. Instead, we rely on users to flag suspicious packages and act quickly to remove them from the registry.
What else can be done?
Other potential steps can be taken to make publishing without an author’s knowledge harder, including implementing 2-factor authentication on publishing. This functionality is already available via integrations in npm On-Site, and npm is working to make various 2-factor solutions available to the public registry. This work is also not yet complete.
What if I…
Ultimately, if a large number of users make a concerted effort to publish malicious packages to npm, malicious packages will be available on npm. npm is largely a community of benevolent, helpful people, and so the overwhelming majority of software in the registry is safe and often useful. We hope the npm community continues to help us to keep things that way, and we will do our best to continuously improve the reliability and security of the registry.