130

When I run npm install it says found 33 vulnerabilities (2 low, 31 moderate) run `npm audit fix` to fix them, or `npm audit` for details.

However, npm audit fix outputs up to date in 11s fixed 0 of 33 vulnerabilities in 24653 scanned packages 33 vulnerabilities required manual review and could not be updated

Does that review mean it is not supposed to be fixed by user?

When I run npm audit it gives me list of tables, similar to this:

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ lodash                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.17.5                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ browser-sync [dev]                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ browser-sync > easy-extender > lodash                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/577                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

In this example remediation section of linked page says Update to version 4.17.5 or later.. However, in /node_modules/browser-sync/package.json there are lines:

"devDependencies": {
    "lodash-cli": "4.17.5",
}

and no more lodash dependencies. So it should already be v4.17.5. I also checked /node_modules/lodash/lodash.json which has var VERSION = '4.17.10'; line. In /node_modules/lodash/package.json there are these lines:

  "_from": "lodash@^4.17.4",
  "_id": "lodash@4.17.10",

I believe that version shown in "_id", not in "_from", so versions are correct but vulnerability still appear in audit list.

I'm still new in node.js and those messages confuses me a lot. Is there any way to fix it manually or get rid of those messages, I can't do anything with?

Calder White
  • 1,195
  • 6
  • 19
Jakupov
  • 1,526
  • 2
  • 7
  • 14
  • Does this answer your question? [How do I fix a vulnerable npm package in my package-lock.json that isn't listed in the package.json?](https://stackoverflow.com/questions/50328324/how-do-i-fix-a-vulnerable-npm-package-in-my-package-lock-json-that-isnt-listed) – JBallin Feb 01 '20 at 00:29

7 Answers7

48

lodash-cli in devDependencies doesn't affect how browser-sync works in your project, devDependencies are ignored when a package is installed as a dependency.

What audit report says is that it's easy-extender that has lodash dependency:

browser-sync > easy-extender > lodash        

It depends on Lodash 3, while the problem was fixed in Lodash 4. The problem could be fixed by forking easy-extender, updating it and installing it instead of the package from NPM public registry. But there is no real problem with this dependency.

audit report importance should be evaluated manually. Even if nested dependency has security risk, this doesn't mean that a feature that introduces this risk was used. This also doesn't mean that even if it's used, it introduces real risk due to how it's used.

browser-sync is development tool that isn't used in production, there are not so many scenarios where its vulnerabilities could be exploited. And Prototype Pollution isn't a vulnerability at all, just a notice that a package doesn't follow good practices, it can be ignored.

Generally, this is the way to fix reported vulnerabilities:

  • Do a sanity check
  • In case it's a real problem, check the repository of vulnerable package for existing issues and PRs
  • In case there's none, submit an issue
  • Fork a repository or use use existing PR as git dependency until it's fixed in NPM release
  • In case of nested dependencies, do this at several levels of nesting

Most times it's expected that you won't advance beyond a sanity check, and the only problem is that a "vulnerability" clutters audit report and conceals real vulnerabilities.

patch-package can help to patch nested dependencies in-place but this won't affect the report.

It's possible to force specific dependency version in nested dependency in Yarn 1 and 2 with resolutions field, this will affect audit report. It may be possible to do this natively in NPM in future. Currently the alternative in NPM is third-party npm-force-resolutions utility that gives less control, currently it forces a resolution for all dependencies, not a specific one.

Notice that by forcing a dependency to use nested dependencies it wasn't designed to work with, it can become broken at any moment. This especially applies to npm-force-resolutions, which is a blunt tool and can affect many nested dependencies at once.

Estus Flask
  • 179,509
  • 61
  • 360
  • 499
  • I didn't pay attention to Path section, and it really uses lodash v3.10.1, thanks. But browser-sync is just example, last one of list. So, I can ignore 2 low vulnerabilities, but can I ignore 31 moderate ones? I suppose I shouldn't modify anything in `node_modules`, so is forking and fixing is only way to get rid of them? And as new user I haven't capability to do that? Should I issue package developers about them? – Jakupov Jul 17 '18 at 12:23
  • 5
    *but can I ignore 31 moderate ones?* - this is what 'sanity check' is about, use your judgement. The more attention you pay to what these reports actually say, the better developer you can become, security-wise. *Should I issue package developers about them?* - you likely should (at least to shut `audit` up), the answer answers that. People lived without `npm audit` somehow. Chances that they cause real security problems to the app are very low, yet without knowing what they are and how they are used in your app, I cannot guarantee that. – Estus Flask Jul 17 '18 at 12:43
  • Thanks! Took time to write comment, so didn't see edited part before commenting. – Jakupov Jul 17 '18 at 12:53
15

If you are absolutely certain you'd like to skip the audit, you can do so by appending --no-audit

 npm install --no-audit
Tjad Clark
  • 410
  • 3
  • 13
10

'npm audit fix' will increment the version of dependency in package.json which might lead to breaking of code. So better way is to open package-lock.json and updated the dependency/subdependency versions to required version. Maintain the package-lock.json in repository.

Sometimes vulnerabilities are from dev packages, In that case ignore those vulnerabilities as those are not getting picked up in the production.

nik
  • 200
  • 3
  • 11
  • What about adding/updating dev packages from the package.json file itself? Any inconvenient with this approach? https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file – carloswm85 Dec 13 '21 at 22:42
4

use this

npm audit fix --force --production

may be solve your problem

code chan
  • 41
  • 1
1

You can you use force also like npm audit fix --force.

40Sherrin
  • 111
  • 3
  • However this will include breaking changes – Monstar Mar 02 '22 at 14:11
  • Also not always working. For example I get: "added 555 packages from 172 contributors, removed 350 packages and updated 1500 packages in 52.021s fixed 0 of 22 vulnerabilities in 2057 scanned packages 22 vulnerabilities required manual review and could not be updated" – Konstantinos May 31 '22 at 17:00
-3

I tried this and it worked for me, run the following commands:

> npm audit fix    
> npm set audit false
Anya
  • 11
  • 1
  • 1
    Please add further details to expand on your answer, such as working code or documentation citations. – Community Sep 10 '21 at 08:25
-22

The most of the problem occurred in my system was due to npm package. I tried,

npm un npm

You don't have to install again.

Just run program again. It worked for me.

  • 1
    This just uninstalls the local npm installation, which causes the global npm installation to be used instead. – Minding Jul 02 '21 at 17:50