DEV Community

Cover image for How to deal with the event-stream vulnerability
Alex Barashkov
Alex Barashkov

Posted on

How to deal with the event-stream vulnerability

For the last couple of days in the internet, you probably have seen a lot of news about event-stream npm package vulnerability and that package steals bitcoins. I was disappointed that I had to read tons on articles before actually get the answers on the following questions:

  • Does it affect my projects?
  • What should I do?

So I decided to put here my today research and a short overview as possible to help you find and fix the problem for your projects.

  • existing information tells that targeted package which only affected by the vulnerability of the event-stream package is copay-dash. If you don’t have copay-dash, relax and continue read calmly;
  • event-stream@3.3.6 had a vulnerability in the dependency package flatmap-stream@0.1.1;
  • the vulnerable version of that package already removed from the npm registry;
  • removing the package from the npm registry caused the issue that on npm install(fresh install, without cache) and npm audit you will get an error;
npm ERR! code ENOAUDIT
Enter fullscreen mode Exit fullscreen mode


npm ERR! code E404
npm ERR! 404 Not Found: flatmap-stream@0.1.1
Enter fullscreen mode Exit fullscreen mode
  • if you have that error, your project has vulnerable package;
  • a lot of popular packages were affected, for example, nodemon;
  • search through your yarn.lock or package-lock.json and find the root package which installs flatmap-stream@0.1.1;
  • visit github pages of packages which were affected and maybe there is already new version with a fix. So just install new version with a command like npm install nodemon@latest -D;
  • for more information about the situation read that article

Top comments (5)

tiguchi profile image
Thomas Werner • Edited

I think the real issue with npm might be that dependencies are typically not locked to a specific tested and trusted full version number right in package.json. We always default to a lax definition of "give me the latest patch or minor release" using ^. That requires that we can trust all sources. Which is obviously not the case.
Maybe npm and yarn should stop prefixing version numbers with the caret symbol when we add new dependencies to a project.

ondrejs profile image

Paying the open-source devs maintaining your dependencies would be the good solution at the first we're only dealing with consequences.

richremer profile image
Rich Remer

Not worth it. Easier to just not allow tranfers.

ondrejs profile image

C'mon! I'm trying to be nice on FOSS devs and you are ruining it.

maxmelodia profile image
Maxwell Duarte