Testing for unpublished packages

Guy Podjarny
March 22, 2016 | in Application Security
| By 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:

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.