I got an email from GitHub stating that one of my project's dependencies "hoek" had a known security vulnerability and I should update it. However, hoek itself is not something I installed but is a dependency of one of my other dependencies. Is there anything I can do about this or does the maintainer of the project that uses hoek have to update the version they use?
The package CVE-2018-3728 is vulnerable. The vulnerable versions of hoek are prior to 4.2.1 and 5.0.3 and are vulnerable to prototype pollution.
The affected versions of hoek are until version 5.0.2, The remediation is to update to version 4.2.1, 5.0.3 or later.
For more information, you can view the fix pull request here: https://github.com/hapijs/hoek/pull/231/commits/5aed1a8c4a3d55722d1c799f2368857bf418d6df
Related
We have a legacy app and it's been using Angular 2.4 since the beginning. Currently package.json is having overrides for many packgages and for our build, we are using npm install --force because of multiple conflicting peer dependency, cannot resolve dependency of some packages, etc. I can foresee that we would keep using override for other dependency update and expanding the package.json.
I'd like to understand:
the risks if we don't upgrade Angular version and keep using Angular 2.4?
Is it okay to use npm install --force in build/release pipeline in production?
Short answer is no
Older versions of packages "decay" over time.
Sometimes because a version of a package had dependencies which are no longer maintained
or (the worse) because their n-th level dependency is no longer maintained.
once a version is out of the LTS terms (or deprecated like angular v2 and older are) you also start to loose its documentation.
Then there is the unknowns of having your locked version of a package having to run with newer versions of its dependencies. And you would having to provide some of the fixes yourself.
There are plenty of security issues that the 100's of dependencies a package like angular has and can only be addressed by upgrading.
Your app might still work with forcing dependencies to update. But it would certainly be exposed to a fair bit of know issues which newer versions have already addressed.
Why do I have to care about npm/node version (running on machine/needed by project)?
Why does every project require a specific node/ npm version?
Where in the project is the required version noted (package-lock.json)?
Is something bad about requiring older version of node/npm?
Is it possible/necessary to upgrade project to run with latest versions?
Why do I have to care about npm/ node version ( running on machine /
needed by project )?
This question is very broad, I will try to answer it as precise as possible. Every version has certain addition/modifications/deletions in its modules. If you have a project that runs on Nodev16 it is also important to update the npm version(some minimum version) for compatibility with peer dependencies is important. Similarly, if we have a lower node version like v12, all the dependencies should be compatible with it like npm(to install dependencies with the same version)
Why does every project requires a specific node/ npm version ?
It depends on the project that you create. You can also update the versions of your project. There is a guide on how to update Node.js projects.
Is something bad about requiring an older version of node/ npm ?
Is it possible/ necessary to upgrade the project to run with the latest
versions?
Yes, you need to always update the older version to the current version because your project might be vulnerable to security loopholes or older version compatibility issues with a newer version.
Below are the vulnerabilities that I get:
-You can see that all vulnerabilities depend on node-fetch <=2.6.6 When I look upon how to fix it on GitHub it says that versions lower than 2.6.1 need to be updated. Yet my version is 2.6.6 and I'm still getting a vulnerability message. Are there any possible ways of fixing this? Another issue is that I can't seem to find it in package-lock.json folder either and I'm unable to update/change it manually. I've tried uninstalling the entire package-lock.json and reinstalling it, and I'm still stuck with this vulnerability message. Thanks to anyone who can help!
Severity: high
The `size` option isn't honored after following a redirect in node-fetch - https://github.com/advisories/GHSA-w7rc-rwvf-8q5r
node-fetch is vulnerable to Exposure of Sensitive Information to an Unauthorized Actor - https://github.com/advisories/GHSA-r683-j2x4-v87g
No fix available
node_modules/isomorphic-fetch/node_modules/node-fetch
Depends on vulnerable versions of node-fetch
node_modules/isomorphic-fetch
fbjs 0.7.0 - 1.0.0
Depends on vulnerable versions of isomorphic-fetch
node_modules/fbjs
fbemitter 2.0.3 - 3.0.0-alpha.1
Depends on vulnerable versions of fbjs
node_modules/fbemitter
expo >=14.0.0
Depends on vulnerable versions of fbemitter
node_modules/expo
Depends on vulnerable versions of fbemitter
node_modules/expo-updates```
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>
During docker vulnerability check we found that package minimatch has vulnerabilities. Due to this we have to use minimatch package to latest which is 3.0.4.
I have copied the package-lock.json in the js section of fiddler https://jsfiddle.net/Loecjuy4/1/
"minimatch": "3.0.4" instead of "minimatch": "2.0.10"
If you search the package-lock.json at fiddler link that I provided, you will find minimatch as dependencies in many places sometimes version 3.0.4 is used (line 2022 in eslint) while in other places version 2.0.10 is used (line 3170).
I want to know a way such that package minimatch has the same version 3.0.4 in all the places of package-lock.json. I have tried shrinkwrap but it too shows different version of minimatch.
Update all your dependencies to the latest version. If the old version is still in your package-lock.json, it means that the dependencies you use have a dependency itself on the old version. You should then probably contact the maintainers of these packages to upgrade their dependencies (i.e. by opening an issue on their respective repository).