DEV Community

Fixing NPM Dependencies Vulnerabilities

Brandon Benefield on June 13, 2019

TLDR; Run the npm audit command Scroll until you find a line of text separating two issues Manually run the command given in the text t...

Read full post

Ryan Cole • Sep 12 '19

Any tips for how to update old deps inside of other packages? Most of my warnings come from larger packages that I don't have access to the internals of without significant hassle. If I update them in my repo, will the newer version I installed override the old version inside the library? Thanks!

Brandon Benefield • Sep 12 '19 • Edited

@askdesigners Yup, that's exactly what this post is about. Just like in this post, I was using jest@23.x.x and it had 62 vulnerabilities coming from multiple internal packages that jest uses.

When running the suggested command that came from NPM, run npm install --save-dev jest@24.8.0, it will then grab that specific version of jest that fixes the vulnerabilities. This means that the maintaner(s) of your package have fixed the vulnerabilities and pushed a new version of their package for you to use.

Another option, that I wouldn't recommend, is to install the vulnerabilities of the internal packages into your own project. For example, if one of your packages is reporting a vulnerability from an internal package, braces like in my example in the post, you could install the fixed version of that package yourself using npm i --save-dev braces but this could cause breaking changes.

Scott Martin 🛠️ • Mar 2 '20

Hi Brandon, thanks for your post. I'm trying to fix the same vulnerability in your example, braces, which I have as a four-level-deep dependency, without any success. npm audit reports it as having the path cpx > chokidar > anymatch > micromatch > braces and I've specifically installed the latest version of all of those packages:

  "devDependencies": {
    "anymatch": "^3.1.1",
    "braces": "^3.0.2",
    "chokidar": "^3.3.1",
    "cpx": "^1.5.0",
    "micromatch": "^4.0.2"
  }

Even so, npm audit continues to report the vulnerability. I've deleted node_modules and package-lock.json and run npm install again, but it still doesn't resolve the issue. Is there something else that I need to do? I'm pretty much at my wits' end at this point.

Scott Martin 🛠️ • Mar 2 '20

Typically, I found a workaround after writing the above. It turns out that cpx is unmaintained. There's a fork called cpx2 that works as a drop-in replacement and resolves the vulnerability. Would the solution to this problem otherwise have been to get cpx to update its dependencies, though?

Chad Collins • Oct 7 '19

I'm not getting the fix to display when running npm audit. Here is my entire output after running npm audit. Any help is appreciated and thank you for the article.

                   === npm audit security report ===

┌──────────────────────────────────────────────────────────────────────────────┐
│ Manual Review │
│ Some vulnerabilities require your attention to resolve │
│ │
│ Visit go.npm.me/audit-guide for additional guidance │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low │ Incorrect Handling of Non-Boolean Comparisons During │
│ │ Minification │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ uglify-js │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >= 2.4.24 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ jade │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ jade > transformers > uglify-js │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ npmjs.com/advisories/39 │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ uglify-js │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=2.6.0 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ jade │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ jade > transformers > uglify-js │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ npmjs.com/advisories/48 │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Critical │ Sandbox Bypass Leading to Arbitrary Code Execution │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ constantinople │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=3.1.1 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ jade │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ jade > constantinople │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ npmjs.com/advisories/568 │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low │ Regular Expression Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ clean-css │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=4.1.11 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ jade │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ jade > clean-css │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ npmjs.com/advisories/785 │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 4 vulnerabilities (3 low, 1 critical) in 2463 scanned packages
4 vulnerabilities require manual review. See the full report for details.

bsastregx • Sep 5 '19

Thanks!!

"The only difference is that manually upgrading our packages will allow us to upgrade a single package, test for a breaking change"

Then what do we do if we find a breaking change? How do we fix it?

Brandon Benefield • Sep 12 '19

@bsastregx If you run into a breaking change after upgrading a package then I would suggest you try and figure out what is causing breaking change. It could be as simple as the argument(s) to a method have changed or a simple environment variable needs to be set. If you can't figure out the issue then my suggestion is to either:

Choose a different package and remove the vulnerable package
Revert back to the vulnerable package (at your own risk)

Michael Freidgeim • Dec 5 '19 • Edited

Is it ok to ignore vulnerabilities in dev dependencies? In your particular example jest is used for tests, how the vulnerabilities in jest could cause the risks in production site? Should we spend time to fix vulnerabilities in dev packages?

waligorar • Oct 1 '19

Is there an option to ignore the vulnerabilities.

Brandon Benefield • Oct 2 '19

There is an option to ignore vulnerabilities and that's the --no-audit flag when installing packages. I would like to say that I wouldn't recommend this at all but if your use case permits it then do what you will. If you don't mind, I'm interested in knowing why you would like to ignore the vulnerabilities?

Turning off npm audit on package installation

To turn off npm audit when installing a single package, use the --no-audit flag:

npm install example-package-name --no-audit

waligorar • Oct 3 '19

I work on a large team and this is handled by the frontend development team. My team works on backend development. So, I want to install the frontend with defects and all, so I can work on my back end development. The frontend team will work to fix their code, but why should I be blocked? Does that make sense?

Brandon Benefield • Oct 3 '19

Yup, this definitely makes sense but I do want to point out that having vulnerabilities in your packages does not prevent you from working. NPM is just providing the warnings to you so that you are aware of the problems.

I can also see, in your situation, why you would want to prevent the messages. If it's not your place to fix it then why even bother with the messages, right?

Thanks for sharing.

ankit singh • Dec 17 '21

Hi Brandon,

with #npm audit command i am getting below response related to vulnerability.

Low Regular Expression Denial of Service in clean-css

Package clean-css

Patched in >=4.1.11

Dependency of gulp-minify-css [dev]

Path gulp-minify-css > clean-css

More info nodesecurity.io/advisories/1006346

Is there any way to get only severity level and Package detail?

Thanks in advance.

bsastregx • Sep 5 '19

Algo, running npm audit does not show me the suggested command to update. Please, see image : imgur.com/mhnHoq4

Brandon Benefield • Sep 12 '19

@bsastregx I believe the command is there but you may have glossed over it. Perhaps, you could leave the entire result of npm audit as a reply to this?

Bill Wright • Feb 5 '20

Hi Brandon,

I have this same problem (no command to fix things). Using the --force doesn't fix things either. I tried to post my complete output but got an error saying there was a problem with my post, but no other information. I'm running npm version 6.4.1. At the end of my output I get this message: "See the full report for details." But where would I find the full report? There is no mention of where this report is.

Also, my problem is generally with grunt-* modules that use a vulnerable version of lodash. But I have the latest version of the grunt-modules. In that case, is there nothing that can be done? Short of not using the grunt-modules?

Thanks,
Bill