The npm package 'everything' sparked some controversy slowly after its publication over the holidays this year.
Understand what all the npm package 'everything' does, why it's a noteworthy incident, and how can you safeguard yourself against such packages.
Last week, npm account gdi2290 began flooding the npm registry with upwards of 3,000 packages: named "everything" and a variation of it. While "everything" was apparently published as a prank package, combined with thousands of scoped packages under the "@everything-registry/" scope, it had a serious consequence for all authors who have ever published a package to the npmjs.com registry.
Sonatype is tracking this campaign and the "everything" package under sonatype-2024-0036, after Cody Nash, our data scientist and engineer, noticed an anomalous spike on the npm software registry involving these packages.
Although the chances of a developer installing "everything," are slim, it's possible that a malicious actor ends up including this package as a dependency in their typosquat or a dependency confusion exploit, which is why we are treating it as a Potentially Unwanted Application (PUA).
A DoS in disguise; transitive dependencies at play
Essentially, when installed, "everything" attempts to download every single npm package that's ever been published to the registry to your machine, by resolving what is referred to as transitive dependencies.
If we observe, "everything" lists just five packages published by the same author under the "@everything-registry/" scope as its "dependencies."
Each of these "chunk" packages, further list these similarly named packages as a dependency. Diving a few levels deep in this chain, it becomes clear that each of these "chunk" packages further end up pulling in hundreds of legitimate npm packages — which are published by all other authors on the npm registry and bear no relation to "everything" or its author in any manner.
As an example, take a look at "@everything-registry/sub-chunk-1623" being pulled in by "@everything-registry/chunk-2" as a dependency. This package further has 800 dependencies that are all valid npm projects.
An obvious danger of installing "everything," and that effectively means everything that's been published to the registry, is to cause a Denial of Service (DoS) for yourself, as your computer slowly runs out of storage space while fetching millions of npm packages.
Blocks other devs from removing their packages
Another subtle but bigger roadblock created by this campaign is it blocks all npm developers from removing their own packages from npmjs.com registry!
This is a side effect of a well-intentioned npm policy that lets authors delete their packages only if no other package on the registry is listing them as a dependency. This policy was introduced post left-pad incident of 2016 that entailed left-pad's author removing his package from the registry in protest and breaking thousands of projects that depended on it. But, in this case, since "everything" uses every package as a dependency, npm authors would not be able to unpublish their own packages until further action is taken by npm.
The author behind "everything" issued an apology for the problems this and his 3,000+ packages have caused, and reached out to npm for assistance. Interestingly, since thousands of "chunk" packages published by the author depend on "everything," it became extremely difficult to remove the very package for the author himself!
As of this morning, although "everything" remains on the npm registry, its "chunk" packages published under the "@everything-registry" scope seem to have been made private, or in some way restricted from being accessed on npmjs.com.
Sonatype's products such as Sonatype Repository Firewall and Sonatype Lifecycle stay on top of nascent attacks and vulnerabilities and provide you with detailed insights to thwart Potentially Unwanted Applications (PUAs), malware, and vulnerable components from reaching your builds:
Users of Sonatype Repository Firewall can rest easy knowing that whether or not these types of packages are just a prank or actually malicious, they would automatically be blocked from reaching their development builds. Either way, you don't want them in your software development life cycle.
