How to fix npm vulnerabilities manually? - node.js

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.

Related

Json dependencies NPM update- How fix vulnerabilities manually

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

is there a yarn alternative for npm audit?

need pinned resolution feature of yarn, but also want to audit with npm audit? Is there a yarn alternative to npm audit? Or, alternately, will pinning resolutions of dependencies of dependencies work in npm?
Yarn doesn't have npm audit fix.
But here's how to do it by using npm – temporarily.
Generate a package-lock.json file without installing node modules
npm i --package-lock-only
Fix the packages and update the package-lock.json file
npm audit fix
Delete the yarn.lock file and convert package-lock.json file into yarn.lock
rm yarn.lock
yarn import
Delete the package-lock.json file
rm package-lock.json
For example:
yarn audit
38363 vulnerabilities found - Packages audited: 908342
Severity: 38352 Low | 11 Moderate
(I know. react-scripts is crazy...)
npm audit
npm ERR! code EAUDITNOLOCK
npm ERR! audit Neither npm-shrinkwrap.json nor package-lock.json found: Cannot audit a project without a lockfile
npm ERR! audit Try creating one first with: npm i --package-lock-only
npm i --package-lock-only
...
added 266 packages, removed 354 packages, updated 1653 packages, moved 1 package and audited 913793 packages in 54.304s
found 495 low severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details
npm audit fix
...
added 267 packages from 152 contributors, removed 355 packages and updated 1712 packages in 92.849s
50 packages are looking for funding
run `npm fund` for details
fixed 211 of 495 vulnerabilities in 913793 scanned packages
284 vulnerabilities required manual review and could not be updated
git status -s
?? package-lock.json
yarn import
yarn import v1.21.1
info found npm package-lock.json, converting to yarn.lock
...
success Saved lockfile.
✨ Done in 25.61s
rm package-lock.json
yarn audit / yarn install --audit has been available since yarn#1.12.0
https://github.com/yarnpkg/yarn/releases/tag/v1.12.0
Unfortunately no --fix option yet, but as workaround you can use https://www.npmjs.com/package/yarn-audit-fix
Yes, you can use yarn audit to audit for vulnerability but you can't fix the Vulnerabilities by using yarn audit fix as you can do in npm audit fix.
To fix the Vulnerabilities in yarn.lock file you have to reinstall the package(which is carrying the Vulnerability) to its newer version by using yarn add package_name
you can read the issue here => https://github.com/yarnpkg/yarn/issues/7075
I thinks that it's not ready on yarn. You can refer to the following issue.
https://github.com/yarnpkg/yarn/issues/5808
do a yarn audit and find the package(s) with vulnerabilities,
if they are in your package.json file
fix their version from there
else
they are dependencies of your packages so add this to package.json file
"resolutions": {
"**/package-name": "known-good-version",
"**/**/package-name": "known-good-version"
}
1st
Always use source control and check in your package.json as well as your yarn.lock and/or package-lock.json first and start with all committed files, so you can roll back if needed with ease.
How about a solution that does not add dependencies to your project (nor installing a third party library)?
yarn outdated # view
yarn audit # view
yarn install --audit # install
Prefer an interactive way to upgrade selectively with ease?
yarn upgrade-interactive
That might do all you require.
Oddly, you might find with a yarn audit following that command you still have some vulnerabilities not mentioned from the command yarn upgrade-interactive. In this case I'd first consider this:
yarn upgrade-interactive --latest
where that can be found
Still not quite good enough?
```
yarn upgrade --latest
```
I've seen a lot of other potential solutions, previously I'd just switch to npm from yarn temporarily as some users have suggested, then switch back to yarn. This has worked fine for me too. (Though annoying and not elegant)
There are packages out there that don't require install to run.
I haven't tried this one, it might be good too:
npm_config_yes=true npx yarn-audit-fix
ref
The key here is you are using npx to avoid installing as a dependency.
Many more solutions are possible. npm and yarn both are package managers, dependency management is a very difficult thing to do, automagically fixing these dependencies will always be a difficult problem to solve. Thus I recommend a little research on how they are actually solving these problems if you have the time. You might find yourself not liking how they do things.
Ultimately, as long as you can roll back you can try a lot of these out and see for yourself. Some packages severity might not need fixing, sometimes libraries do not have solutions available yet, then you need to consider removing their usage in your codebase. In theory, less is more, less dependency on libraries, which use libraries, which use libraries.... becomes a much smaller surface for attackers to target. Also, it's not advisable to use libraries from untrusted sources, npm, yarn and more cannot know everything, nor right away, so keep that in consideration too.
I created a script command into the package.json file to fix it. It creates a copy of yarn.lock as package-lock.json, removes the issues and then re-creates yarn.lock.
"resolve:security": "npm i --package-lock-only && npm audit fix && rm yarn.lock && yarn import && rm package-lock.json",
I hope it helps :)
You can use yarn audit as mentioned in the other answers, however, there is a different way to solve them...
You will need to add the resolution instruction to specify the version of the library that the vunerability was solved and the path of the dependency (because the library can be a dependency of another dependency, for example:
Considering part of some package.json below
{
"name": "project",
"version": "1.0.0",
"dependencies": {
"left-pad": "1.0.0",
"c": "file:../c-1",
"d2": "file:../d2-1"
},
"resolutions": {
"d2/left-pad": "1.1.1",
"c/**/left-pad": "^1.1.2"
}
}
More details can be checked directly in the documentation: Doc
Yarn doesn't support the fix at the moment,
Workaround
create a package-lock.json file using npm.
fix the packages
remove the package-lock.json.
.
npm i --package-lock-only
npm audit fix
rm package-lock.json
and start
yarn start
Yarn also has yarn audit mechanism, but it doesn't have yarn audit fix mechanism. So in most cases you have to fix these issues manually. This is how it works. For example we'll demonstrate it using minimist package:
Add a resolutions key in your package.json file:
Adding dependency(say minimist) directly as key value .This resolution will override minimist entirely in your project.
{
"resolutions": {
"minimist": "^1.2.5"
}
}
In most cases, there can be multiple dependencies in a project that use the same secondary dependency, however, they might use different versions of those dependencies. Thankfully, yarn/npm allows us to have selective dependency resolutions.
The format to define resolutions is the following:
/* package.json */
{
"resolutions": {
"<package>/**/<dependency>": "<version>"
}
}
Let’s say for example, we have a dependency A and B and both of them depend upon another dependency C.
Then our resolutions field would look like:
/* package.json */
{
"resolutions": {
"A/**/C": "2.0.3", // A works fine with the latest version of C
"B/**/C": "1.9.0" // latest stable version for C for dependency B
}
}
Let's further see how it works with an example of package-merge-lodash-4 package. If audit says that lodash#3.9.3 has vulnerabilities and suggests us to upgrade lodash#3.9.3 -> 4.17.12.
We can write our json file's resolutions only for the concerned package as below:
{
"resolutions": {
"package-merge-lodash-4/**/lodash": "4.17.12"
}
}
How to use Selective dependency resolutions in npm?
add npm-force-resolutions to the preinstall script after you added resolutions key to package.json file, so that it patches the package-lock file before every npm install you run:
"scripts": {
"preinstall": "npx npm-force-resolutions"
}
To confirm that the right version was installed, use the below command
npm ls <vulnerable dependency>
npm ls lodash
Resources:
Selective dependency resolutions
Yarn - How to fix security issues
How to fix security vulnerabilities in NPM/Yarn dependencies
Yarn audit fix: workaround
What's the difference between tilde(~) and caret(^) in package.json?
Semver explained - why is there a caret (^) in my package.json?
Try using,
yarn upgrade-interactive --latest
Will install all the latest dependencies.

NPM Audit fixes

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.

NPM doesn't recognize semvers that end with '*-rc' (i.e. release candidates); causes dependencies to fail to resolve. What's the usual workaround?

Here's a really simple example to illustrate the problem.
I'm trying to use react-native#0.8-rc together with react-native-linear-gradient.
react-native-linear-gradient defines react-native#>=0.4.4 as a peer dependency. Fair enough.
I run npm install.
I get an error saying that
react-native#0.8-rc does not satisfy react-native#>=0.4.4.
This issue makes npm useless, because it's getting in the way of developers and package maintainers. See here for an example.
How does anybody using node do any useful work with release candidates?!?! What is the workaround?
For your reference, the error coming from NPM 3.1.2 (the latest version at the time of writing), looks like this:
MyProject#0.0.1 /path/to/MyProject
├─┬ react-native#0.8.0-rc
│ └── stacktrace-parser#0.1.1 (git://github.com/frantic/stacktrace-parser.git#493c5e5638a79b4d5886171867a06275cc703b00)
└─┬ react-native-linear-gradient#0.3.2
└── UNMET PEER DEPENDENCY react-native#>= 0.4.4
npm WARN EPEERINVALID react-native-linear-gradient#0.3.2 requires a peer of react-native#>= 0.4.4 but none was installed.
OK, so I looked at this and as far as I can tell it's a bug with the version of semver.
Short term: I would suggest forking the semver repository, fixing the bug in your fork, then just referencing your semver fork in package.json for you project.
Long term: submit a bug report with your specific issue, or submit a code fix for it yourself and request to be a contributor.
Point NPM at the github release:
npm install --save https://github.com/facebook/react-native/archive/v0.8.0-rc.tar.gz
Edit: Sorry, nevermind, i misread and thought you had problems installing it. i dont see a way around it other than modifying the peerDependency

How do I find all installed packages that depend on a given package in NPM?

I have a npm package that i want to update. I can update my package.json, but I don't want to break something. Is there a way to list all of the installed packages that depend on it?
You're looking for https://docs.npmjs.com/cli/ls
For example, to see which packages depend on contextify you can run:
npm ls contextify
app-name#0.0.1 /home/zorbash/some-project
└─┬ d3#3.3.6
└─┬ jsdom#0.5.7
└── contextify#0.1.15
You may also find npm explain <package-name> useful as it explains why that package is installed, what depends on it, etc.
e.g. to understand why we have node-sass installed...
$ npm explain node-sass
node-sass#4.14.1 dev
node_modules/node-sass
node-sass#"^4.8.3" from gulp-sass#4.1.1
node_modules/gulp-sass
dev gulp-sass#"^4.1.1" from the root project
You can use https://www.npmjs.com/package/npm-dependents to find dependents that are not installed.
Update: I see the package is broken, but it still may be a good starting point where the author points out a place where it may be breaking: https://github.com/davidmarkclements/npm-dependents/issues/5#issuecomment-451926479
In the meantime, you may want to just use the "Dependents" tab on the individual npm project pages.

Resources