Testing for unpublished packages

Guy Podjarny's avatar Guy Podjarny

Yesterday, Azer Koçulu unpublished nearly 300 packages, notably including left-pad, which is used by top projects like Node & Babel. The npm team un-unpublished left-pad, but the remaining packages remained exposed for malicious actors to grab.

When a package is completely unpublished, npm (currently) allows anyone to publish a new version for that package’s name. When Azer’s popular packages disappeared, several npm users jumped in to do just that, presumably focusing on making their build work. However, there’s no telling whether some packages were grabbed by malicious actors - or will be in the future.

Such a malicious user can then publish a patch release to each major and minor stream, incrementing the version number by 0.0.1. Most consumers of this package will likely use a semver range to pull it in, e.g. pkg@^1.2.1, intending to take in bug fixes as they come. As a result, they will pull in the new version blindly, running the malicious code without even knowing it.

It’s important to find out whether you are exposed to this risk or not. To help you identify whether your dependency tree includes these now-risky packages, we enhanced Snyk to support a new test-unpublished command. To use it, run the following:

1
2
3
cd ~/myproj/
npm install -g snyk
snyk test-unpublished

Snyk will iterate your project’s dependencies, and print out only the ones that have been unpublished. Note that this is currently limited only to the packages Azer just unpublished, as opposed to all unpublished packages.

The output will look roughly like this:

These packages are risky, as they may be (or may have been) republished by a malicious actor. We recommend you inspect them to ensure their content is what you expect. You can also compare them to the contents of the equivalent repository on Azer’s GitHub account. If you’re using the dependency directly, you can also switch to pulling it directly from that GitHub repo.

Note that, while risky, these dependencies are not necessarily vulnerable. Therefore, we’ve decided not to include them in the standard snyk test command, which focuses on finding more guaranteed security holes in your dependencies.

We’ve created snyk test-unpublished quickly, to help npm users deal with the current emergency. We expect to iterate on it, please let us now over Twitter (@snyksec) if you have any feedback or suggestions regarding it.

How to prevent malicious packages

March 27, 2016

Last week, CERT alerted users to the risk of publishing or consuming a malicious npm package. This important risk is not unique to npm, but it is more likely to happen in this ecosystem. This post explains the risk and how you can protect yourself.

Tackling the new npm@3 dependency tree

February 25, 2016

Until recently Snyk's CLI tool only supported npm@2. That all changed when we released snyk@1.9.0 and added full support for the new npm@3 directory structures. In this post, Remy shares some of the technical challenges involved and the new tooling that came out of the process.

Subscribe to The Secure Developer Podcast

A podcast about security for developers, covering tools and best practices.

Find out more

Interested in web security?

Subscribe to our newsletter:

Get realtime updates and fixes for JavaScript, Ruby and Java vulnerabilities that affect your applications