npm vulnerabilities requiring manual review – unsolvable?

WARNING: There is no happy ending to this post. After spending almost a day and a half on this, I wasn’t able to resolve my particular dependencies. If you still want to give this a try, please go ahead. Doesn’t take that long anyways …

I am learning React these days (by completing the freecodecamp Front-End Certification) and from time to time, I have received the following message:

found 65 low severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details
C02N696MG3QD:fccdrummachine kalyan.chatterjee$ npm audit fix
up to date in 8.939s
fixed 0 of 65 vulnerabilities in 45068 scanned packages
  65 vulnerabilities required manual review and could not be updated

How do you resolve these? Should you even bother? The answer to the latter question is, yes, definitely you should bother. npm is a great tool in my opinion and gives you a lot of actionable information. So why incur technical debt?

Why can’t “npm audit fix” fix these issues?

The npm audit command submits a description of the dependencies configured in your package to your default registry and asks for a report of known vulnerabilities. npm audit checks direct dependencies, devDependencies, bundledDependencies, and optionalDependencies, but does not check peerDependencies [ref]. The vulnerabilities you are getting are peer dependencies.

What’s a peer dependency?

They are “dependencies” between plugins and their host package. Some way of saying, “I only work when plugged in to version 1.2.x of my host package, so if you install me, be sure that it’s alongside a compatible host.” We call this relationship a peer dependency.

[source]

An example of a plugin package would be jQuery.

Step 1 – View the audit report

npm audit

In my case, it seemed like most of these vulnerabilities stemmed from a package called braces, which is a peer dependency of popper (not popper.js).

Step 2 – Visit the URL listed in “More info”

In this case the vulnerability was fixed as of version 2.3.1.

Step 3 – Check the Path entry ( see image above)

I looked under ./node_modules > popper. The package.json for popper does not list braces in the dependency hash. It not popper where the dependency is. It is the micromatch package.

What’s the ^ in a version number? If you want to know what the caret means in the version number, you need to learn about semver (semantic versioning: pkg_x@major.minor.patch). In short, (just like tilde) it expresses a range: a range of ~1.2.3 will only permit versions up to, but not including 1.3.0. However, the caret version, ^1.2.3 permits versions from 1.2.3 all the way up to, but not including, the next major version, 2.0.0.

Should I manually update the package with the vulnerability?

My gut instinct was “no” and I was right. If you read the definition of a peer dependency (above), it seems like it might break the dependent package. Also, if you read at the official npm documentation on resolving dependencies, it says the same thing … you can’t just update the package with the vulnerability because then the dependent package might break.

Step 4 – Update the dependent package(s)

The current version of micromatch I have installed is ^2.3.11, that is, I cannot get version 3.0.0. And seems like the current version on npm registry is 3.1.10.

So…

Now I have micromatch 3.1.10

At this point, if you run “npm install” it should be resolved but it didn’t. I seeked help from SO but didn’t receive any good answer. Seems like peer dependencies are just silently brushed under the carpet … 🙁

If you have an answer to this, please comment below.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.