166

Github is telling me that a dependency in my package-lock.json file is vulnerable and outdated. The problem is that if I do npm install or npm update, neither of them update the dependency in the package-lock.json file.

I've done a lot of googling on this, as well as deleted the file and done npm install.

If anyone can help resolve this I'd hugely appreciate it. The package in question is Hoek, which I don't actually have in my package.json file.

starball
  • 20,030
  • 7
  • 43
  • 238
Raph117
  • 3,441
  • 7
  • 29
  • 50

10 Answers10

76

It sounds like Hoek is a dependency of one of your dependencies (so, a package you have in your package.json is requiring it from it's own package.json).

You've already tried deleting/reinstalling and updating your project dependencies without success, so it seems that the package dependency in question has an explicit or max version specified.

Without seeing the package.json for each of your dependencies, it would be difficult to advise further on how to force an update.

Edit: To help you identify which packages are using which dependencies, you can use NPM's ls command: https://docs.npmjs.com/cli/ls

For example, to see which packages are using Hoek: npm ls hoek

Edit 2: As Ulysse BN correctly points out, if you have NPM version 6 or later, you can use npm audit fix to ask NPM to attempt to fix the vulnerabilities for you.

Edit 3: Those reading this should also check out JBallin's answer below. It expands on information I have given here, and is (in my opinion) a more structured answer that addresses OP's question better. However - if you want a quick fix - this answer should suffice.

Alex Mulchinock
  • 2,119
  • 1
  • 18
  • 25
  • 4
    I'm having a similar problem with a different package (Growl). I'm guessing it's some version of something in my `package.json` that depends on the specific (vulnerable) version of Growl. Your answer is on the right track and you could perhaps nail it if you could share the command that will show which package(s) in `package.json` that depend on the vulnerable one showing in `package-lock.json`. – Fuhrmanator Jun 08 '18 at 15:09
  • Are you sure that an additional question was warranted? They seem like duplicates. – JBallin Nov 27 '18 at 19:42
  • @JBallin my answer has been updated several times since. It may not have qualified as a duplicate originally. – Alex Mulchinock Nov 27 '18 at 19:47
47

TLDR: Update the parent package using npm i $PARENT_PKG_NAME.


Note

When updating dependencies, you should review the CHANGELOG for any breaking changes.

Diagnosis

npm audit will reveal both the vulnerable package (note that you'll need a package-lock.json file for this, so you'll need to run npm i), as well as the package that it is a dependency of (if applicable). Note that you can also use npm ls $CHILD_PKG_NAME to see its parent dependencies.

Quick Fix Attempt

npm audit fix and npm audit fix --force are worth a try, but sometimes the fix will need to be done manually (see below).

Manual Fix

Most likely the parent package will have already fixed their dependencies (you can verify this by going to their GitHub and reviewing the recent commits--or just seeing if this fixes it), so you can just run npm i $PARENT_PKG_NAME @$NEW_VERSION and it will update your package-lock.json.

If parent has not fixed the vulnerability

If the maintainer doesn't seem to be responsive, you may consider using an alternative package that accomplishes the same thing or forking the package and updating the vulnerability yourself.

Verify Fix

You can now verify that it worked by running npm audit and ensuring that no vulnerabilities are showing up. Commit your changes, push them to GitHub, refresh your notifications/alerts and they should be gone!

JBallin
  • 8,481
  • 4
  • 46
  • 51
  • What about as in my case the Quick Fix does not work neither the manual in this answer as the parent is a framework that in the update changed completely API and get even rid of that library? This because the parent fraemwork still use the old library. Indeed the old is still mantenained but not updated, I mean how I could proceed? – Carmine Tambascia Jan 16 '20 at 13:00
  • 1
    @CarmineTambascia if the package you’re using isn’t fixing its vulnerabilities (I would open an issue/PR in hopes it would get fixed) - I would consider making your own fork of the package(s), fix the vulns, in place of the affected package. – JBallin Jan 16 '20 at 16:49
  • is there a way to update child package? In case where the parent package has not been corrected for vulnerabilities? – Harshita Jul 15 '20 at 13:23
  • @Harshita see section titled "If parent has not fixed the vulnerability" – JBallin Jul 15 '20 at 15:30
  • @JBallin This is one of the most useful answers I've come across but the dependencies we are using are not opensource and are maintained by closed teams. – Harshita Jul 15 '20 at 16:41
  • 1
    @Harshita have you reached out to them? It's in their interest to fix those vulnerabilities as well. – JBallin Jul 15 '20 at 16:56
14

Step 1: Install Peer Dependencies

npm i --legacy-peer-deps

Step 2: Change package manually

Edit package-lock.json manually and update the vulnerable package version to the fixed one.

npm ci

That will install the packages according to package-lock.json by ignoring package.json first.

Step 3: Control it again

Run

npm audit fix

to be sure if it's properly done. If it does not help so, then use other given solutions.

More Information here:

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

or here: https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities

  • An additional solution could be: https://www.npmjs.com/package/npm-check-updates –  Oct 24 '20 at 18:53
  • 2
    This is a good alternative solution. If this is done inside a package that's meant to be published, then it won't work because the package-lock.json file does not get published, but for using a package locally, this might be the best solution of `npm audit fix` is not an option. – rpivovar Jan 06 '21 at 23:58
  • I would always add package-lock.json in a production environment. (better safe than sorry) –  Apr 26 '22 at 12:27
8

If you have npm@6 or later, you can use npm audit fix for your security issues.

Ulysse BN
  • 10,116
  • 7
  • 54
  • 82
3

Use:

npm i hoek

npm will install the latest version of hoek and your package.lock.json become updated.

scorpion
  • 671
  • 1
  • 9
  • 16
2

Since NPM v8.3.0 (2021-12-09), package.json has a property overrides which might help you on fixing vulnerabilities on dependants dependencies. Without touching package-lock.json file.

{
  "overrides": {
    "foo": "1.0.0"
  }
}

Docs: https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides

Note: Do not forget to check if there are Breaking Changes on the packages you are trying to override.

jbarradas
  • 2,031
  • 3
  • 17
  • 22
1

To check vulnerable npm packages, just use following commands:

npm audit

To fix vulnerable npm packages, just use following commands which will fix package-lock.json too:

npm audit fix
Jerry Chong
  • 7,954
  • 4
  • 45
  • 40
0

I had this issue and found that it was because the server on which I was running npm had an old version of npm on it- package-lock.json is only supported by newer versions.

jvvw
  • 506
  • 5
  • 6
-1

did you try this: go to your project root, delete the package-lock.json file, node_modules and .cache folders, and then npm install.

CakeL
  • 554
  • 3
  • 7
  • 1
    This is very risky in practice. Even a patch release can hide some major bugs or breaking changes or even worse (a hacker publishing a new version of a lib on npmjs.org for example). You don't have any guarantee that updating all your dependencies will keep your project working normally. The safe way is to update dependencies step by step, create pull requests for each with automated testing/build to ensure everything keeps working. – Ricovitch Mar 29 '21 at 09:55
-5

After installing new dependencies run the following command to update the package-lock.json file:

npm update package-lock.json
James Skemp
  • 8,018
  • 9
  • 64
  • 107
SA911
  • 7