Recently, a malicious actor gained access to the github repository of popular nodejs package
event-stream modifying the package to include a malicious library. The attacker was then able to publish the malicious version (
3.3.6) to NPM, from where it was downloaded several million times by unwitting users. This package is also published as an RPM
nodejs-event-stream for Fedora, Software Collections, and Openshift Enterprise, but the malicious version was never published as an RPM by Red Hat or Fedora.
The malicious version included code to steal bitcoin (more information in snyk.io blog). It remained in the NPM repository for around 2 weeks until a user noticed the suspicious change and opened a github issue, which resulted in the malicious version being un-published from NPM. This was possible because NPM is a community-driven repository of almost a million packages, with negligible resources for oversight and review, which must trust the integrity of its contributors. The original author of
event-stream, in good faith, granted access to a new volunteer offering to maintain the software. This volunteer later turned out to be a bad actor. The code in question was not obviously malicious - it took examination of a new, obfuscated dependency for someone to discover anything wrong.
Fedora, Red Hat Software Collections, and Openshift Enterprise carry this package under the name
nodejs-event-stream, but the malicious version was never packaged as an RPM by Red Hat or Fedora. Users are only at risk if they deployed packages from the NPM public repository, and happened to have an un-versioned, or major version (3), dependency on
This incident highlights again the risk of using packages from an uncontrolled, public repository with many contributors. Effective review and controlling for malicious packages is very difficult at the scale of NPM, so the risk is always present. Malicious versions of popular packages have been discovered in the past and "typosquatting" continues to be a problem. Those who use NPM for dependency management must remain alert to the risks and carefully examine their dependencies. Where a package specifies a dependency, without pinning a particular version, be aware that a bad actor gaining access to that dependency's repository could potentially upload a malicious version that you will then automatically consume.