After running npm audit I have (this is just one of) a moderate warning
Moderate │ Prototype pollution
Package │ hoek
Patched in │ > 4.2.0 < 5.0.0 || >= 5.0.3
Dependency of │ karma
Path | karma > log4js > loggly > request > hawk > sntp > hoek
I can see that hoek is a dependency of karma (further down the chain). Looking at the Karma repo on GitHub I can see that this has been raised but no immediate fix has been prioritised.
Is this something that we just have to accept for now until they have updated their dependencies or can we tell our application to use a more recent version of hoek and apply to all packages?
You can npm install the fixed version of the dependency from a pull request or a commit.
E.g.
npm install github:winstonjs/node-loggly#pull/79/head
Then delete the added line in package.json e.g. "loggly": "github:winstonjs/node-loggly#pull/79/head"
In package-lock.json search for loggly and where it shows "version": "<some git url>", delete the url and replace it with the appropriate version number e.g "1.1.1".
The problem is that loggly hasn't be updated for a long time and is hard-coded to request version that uses hoek version with specified vulnerability. There is open issue.
Considering a role of hoek package here, it's unlikely that it causes real security issue.
From a user's perspective, it's possible to fix security issue by using a branch where this dependency is fixed, e.g. this pull request:
"karma": "^2.0.2",
"loggly": "github:winstonjs/node-loggly#pull/79/head"
Since loggly branch version matches constraints in log4js, this replaces original loggly with fixed one (possibly requires to purge node_modules to take effect).
This causes
400 Bad Request - POST https://registry.npmjs.org/-/npm/v1/security/audits
error for npm audit, so it likely should be left as is for now.
Related
In my package.json I have listed gulp as one of my dependencies.
{
"name": "myproject",
"devDependencies": {
"gulp": "^4.0.2"
// other stuff
}
}
When I run npm i I get a message there are moderate security vulnerabilities. So I do npm audit and I get this
=== npm audit security report ===
Manual Review
Some vulnerabilities require your attention to resolve
Visit https://go.npm.me/audit-guide for additional guidance
Moderate Regular expression denial of service
Package glob-parent
Patched in >=5.1.2
Dependency of gulp [dev]
Path gulp > glob-watcher > chokidar > glob-parent
More info https://npmjs.com/advisories/1751
Moderate Regular expression denial of service
Package glob-parent
Patched in >=5.1.2
Dependency of gulp [dev]
Path gulp > vinyl-fs > glob-stream > glob-parent
More info https://npmjs.com/advisories/1751
found 2 moderate severity vulnerabilities in 751 scanned packages
2 vulnerabilities require manual review. See the full report for details.
So then I thought it was all a matter of changing the version of gulp to the highest version where it is (probably) patched. But it seems that this is already the highest version, so what do I do about the vulnerability?
If anyone is curious how I actually "solved" this issue, I started using yarn for all my projects. To me it seems superior to npm.
The following commands will take care of you:
Install yarn
Remove npm's "package-lock" to not mix project package managers
Run yarn
Enjoy
Commands:
npm i --global yarn
rm -rf package-lock.json
yarn
I have lost 1 day in order to try to fix manually fews high vulnerabilities.
It was a waste of time.
I've read many post, blog and suggestion but I was unable to fix the problem.
Basically /css-what require an update to version 5.0.1 and the npm audit is telling that
│ Dependency of │ gulp-imagemin [dev]
│ Path │ gulp-imagemin > imagemin-svgo > svgo > css-select >
| css-what
I've run (on gulp-imagemin) the command npm update, then navigate to the next folder (imagemin-svgo) and again npm update etc etc. When I arrive to the css-what root, I run again npm update but it doesn't do anything;
Then I modified my package.json according
"resolutions": {
"trim-newlines": "^4.0.1",
"css-what": "^5.0.1",
"scripts": {
"preinstall": "npx npm-force-resolutions"
}
}
I went back to the main root to run npm i but it doesn't amended all branches;
Besides when I run npm ls css-what or npm ls trim-newlines I can see that the new version has been installed on the node_modules but older version still unchanged on the tree
root/tree
I was following https://hackernoon.com/how-fix-security-vulnerabilities-in-npm-dependencies-in-3-minutes-rq9g3y7u post but it doesn't worked for some reason, most probably my inexperience.
Thanks for your help
To fix vulnerability you can try :
npm audit -fix
To update you can also use npm-check-updates
npm update css-what worked for me
I recently updated my version of angular using ng update
and when running npm audit it found 1 high severity vulnerability but offered no suggestions on how to resolve it. It usually suggests to upgrade a package from package.json like: "angular-devkit/build-angular" but I am already using their latest version.
=== npm audit security report ===
Manual Review
Some vulnerabilities require your attention to resolve
Visit https://go.npm.me/audit-guide for additional guidance
High Arbitrary File Overwrite
Package tar
Patched in >=4.4.2
Dependency of #angular-devkit/build-angular [dev]
Path #angular-devkit/build-angular > node-sass > node-gyp > tar
More info https://npmjs.com/advisories/803
found 1 high severity vulnerability in 29707 scanned packages
1 vulnerability requires manual review. See the full report for details.
I thought of installing npm i tar but I am not sure.
The following worked for me:
Go to node_modules > node_gyp > package.json, then locate tar under dependencies and replace 2.0.0 with 4.4.8.
Then run:
npm i
npm audit
npm audit fix
npm audit
you should see 0 vulnerabilities.
I've updated a few angular projects and each project had the same issue. Doing the above worked all the time.
angular-cli relies on node-gyp, who have an open issue for this: https://github.com/nodejs/node-gyp/issues/1714
To work around, you can patch node-gyp and then patch angular to use your patched node-gyp. Or wait and hope that they will fix it soon.
You should search in your package-lock.json this:
"tar": {
"version": "2.2.1",
"resolved": "https://registry.npmjs.org/tar/-/tar-2.2.1.tgz",
And reemplace for that:
"tar": {
"version": "4.4.8",
"resolved": "https://registry.npmjs.org/tar/-/tar-4.4.8.tgz",
That worked for me
I got 18 vulnerabilities by giving npm audit , then i went for the one which is labeled as high.
here is its detail,
High Denial-of-Service Memory Exhaustion
Package qs
Patched in >= 1.x
Dependency of google-search-scraper
Path google-search-scraper > request > qs
More info https://nodesecurity.io/advisories/29
it seems like we need to update request package , so by >npm i request
i have installed it.
now what next, the audit command is giving same results again
please help ,
Thank you
EDIT
Moderate Prototype pollution
Package hoek
Patched in > 4.2.0 < 5.0.0 || >= 5.0.3
Dependency of botkit
Path botkit > botbuilder > jsonwebtoken > joi > hoek
More info https://nodesecurity.io/advisories/566
As the report says, qs vulnerability has been fixed in 1.x. It's not a problem for latest request versions. google-search-scraper has request#~2.33.0 dependency that depends on qs#~0.6.0. Regardless of which request version is installed in the project, google-search-scraper will continue to use 2.33.x version that contains vulnerability.
google-search-scraper should be forked and used instead of original package, request dependency version should be updated in a fork, e.g. to request#^2.33.0. Additionally, an issue can be opened in package repository and supplemented with a PR.
A solution that has worked for me is by initially creating JSON file which will be the manifest. Before installing the npm package start with the followingnpm init -y
that way you agree to all the details that will be added by the JSON file, you can edit them afterwards.
Then proceed with npm install <package name>
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?
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.
If you are absolutely certain you'd like to skip the audit, you can do so by appending --no-audit
npm install --no-audit
Source: Documentation
Cases may be
false positives
vulnerabilities that have no effect in your particular environment
vulnerabilities that are present in parts of code you make no use of
False positives further reading
Wrong contexts further reading
Update 2022
Alternatively you could use Better NPM audit to micro-manage the audit
'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.
use this
npm audit fix --force --production
may be solve your problem
You can you use force also like npm audit fix --force.
I tried this and it worked for me, run the following commands:
> npm audit fix
> npm set audit false
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.