Wrong version in lodash.pick vulnerability report CVE-2020-8203

[boosterAFK]

Hi,

It appears that a vulnerability with High severity has been reported with wrong patching version.

Currently latest release is 4.4.0 but for CVE-2020-8203 the patched version is 4.17.19.

For us pnpm audit is failing because of this

[bursache]

Same for lodash.set and probably some more

[boosterAFK]

Okay, as workaround if you are using pnpm, add this to the package.json

"pnpm": {
    "overrides": {
      "lodash.pick@>=3.7.0 <4.17.19": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"
    }
  }

The solution above is in case lodash is being referenced as a sub-dependecy.

If you are referencing directly any of the affected packages through dependencies or devDependencies, simply reference the commit as following:

"lodash.pick": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"

or:

"lodash.pick": "https://github.com/lodash/lodash/archive/refs/tags/4.17.21.tar.gz"

[arochedy]

Okay, as workaround if you are using pnpm, add this to the package.json

"pnpm": {
    "overrides": {
      "lodash.pick@>=3.7.0 <4.17.19": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"
    }
  }

The solution above is in case lodash is being referenced as a sub-dependecy.

If you are referencing directly any of the affected packages through dependencies or devDependencies, simply reference the commit as following:

"lodash.pick": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"

It's working thank you

for npm I just add

 "overrides": {
      "lodash.pick@>=3.7.0 <4.17.19": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"
    }

in package.json

[causaly-mark]

Okay, as workaround if you are using pnpm, add this to the package.json

"pnpm": {
    "overrides": {
      "lodash.pick@>=3.7.0 <4.17.19": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"
    }
  }

The solution above is in case lodash is being referenced as a sub-dependecy.

If you are referencing directly any of the affected packages through dependencies or devDependencies, simply reference the commit as following:

"lodash.pick": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"

or:

"lodash.pick": "https://github.com/lodash/lodash/archive/refs/tags/4.17.21.tar.gz"

Do I understand correctly that the workaround for this is to replace [email protected] with... the current version of the whole of lodash?

[causaly-mark]

Okay, as workaround if you are using pnpm, add this to the package.json

"pnpm": {
    "overrides": {
      "lodash.pick@>=3.7.0 <4.17.19": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"
    }
  }

The solution above is in case lodash is being referenced as a sub-dependecy.
If you are referencing directly any of the affected packages through dependencies or devDependencies, simply reference the commit as following:
"lodash.pick": "https://github.com/lodash/lodash/archive/f299b52f39486275a9e6483b60a410e06520c538.tar.gz"
or:
"lodash.pick": "https://github.com/lodash/lodash/archive/refs/tags/4.17.21.tar.gz"

Do I understand correctly that the workaround for this is to replace [email protected] with... the current version of the whole of lodash?

Please, if you have any better solution to this workaround feel free to share it instead of complaining.

I'n not complaining; I'm asking for clarification. I'm trying to understand the nature of the problem - and whether the workaround fixes the underlying issue.

The reason I ask is that the fix that went into 4.17.19 doesn't actually affect the pick utlilty at all. I don't want to apply a fix if it doesn't actually address the problem.

I'm currently trying to see what I can learn from the other fixed modules (e.g. lodash-es). Will update when I have more concrete information.

[nclavaud]

@causaly-mark I think this is because the per-method packages are not maintained/released anymore.

See this other, similar issue about another method package: #5808
and https://lodash.com/per-method-packages for the official documentation discouraging their use.

[causaly-mark]

So to follow up on my previous comment:

1. When the modularized versions of lodash.pick etc. were created, they duplicated code rather than using e.g. the set functionality from other parts of lodash. That has since changed, but it probably means that the mistake fixed in lodash itself, while it doesn't apply directly, is pertinent to lodash.pick (and others) since the naive copying of object properties was duplicated... Therefore an update is wise.
2. As @nclavaud notes, the modularised packages are now essentially deprecated. Thus, If you use lodash.pick or another modularised lodash subset as a direct dependency in your projects, drop it and replace it with lodash. If you're able to apply it to transitive uses, the solution suggested by @Pfahlf makes sense.

[ebickle]

Apologies in advance for hopping onto this issue from a few months back. I've noticed a few issues created over the years regarding security alerts in the modularized lodash.<module> packages that were published to NPM. Our own developers frequently trip up over these and incorrectly assume there's no fix or path forward.

I'm not sure if this is the right venue for the request, but would it be possible for the Lodash team to mark these modular packages as deprecated in NPM with a message that users should use the NPM lodash package instead? It would be a huge help and probably close out the issue once and for all. 😊

[jdalton]

Closing as nothing actionable on our end I believe. Thanks ya'll for finding workarounds!

[ebickle]

@jdalton I believe we're waiting for action from Lodash - can the Lodash team please mark all of the modular packages as deprecated in NPM?

For example, https://www.npmjs.com/package/lodash.pick still shows as non-deprecated despite Lodash no longer maintaining it. That's the source of the confusion 😊

[jdalton]

The issue is that if I mark them as deprecated they return an exit code 1 for CLI's and that would cause mass disruptions for folks.

[ebickle]

I've seen quite a few build pipelines in GitHub actions that continue with deprecated packages; it might be NPM CLI version dependent but in the versions I've seen it returns exit code 0.

For example:

npm install @hapi/[email protected]
echo $?

rm -rf node_modules
npm ci
echo $?

Echoes 0 both times for NPM 10.5.0. I could completely see how it would be a significant pain if an older version of NPM had different behavior though! Just figured I'd double check since I've had a lot of developers stumble over the pain point of these packages. "I have a critical vulnerability and there's no newer version, we'll just have to wait for Lodash to fix the vulnerability one of these years!". Whoops 😎