Prototype Pollution in lodash.set

[Jessegerard]

Github Advisory: GHSA-p6mc-m468-83gw
High Severity Issue

Looks like this issue was patched in lodash@4.17.19
Is it possible to patch the lodash.set package?

[falsyvalues]

Hi @Jessegerard There packages are no longer supported it's unlikely they will receive any update.

[Jessegerard]

@falsyvalues Thanks for your response.

I had no idea the "dot" micro packages were no longer receiving security updates. There's no warning on the npm page.

Do you know if there has been a discussion about marking them as deprecated in npm? Or adding instructions for migrating to a supported version of lodash? Those packages are still downloaded millions of times a week, seems like they should be properly sunset.

[ferdnyc]

@Jessegerard The Lodash Per-Method Packages document already notes,

Per Method Packages

Lodash methods are available in standalone per method packages like lodash.mapvalues, lodash.pickby, etc. These packages contain only the code the method depends on.

However, use of these packages is discouraged and they will be removed in v5.

Although they may seem more lightweight, they will usually increase the size of node_modules and webpack/rollup bundles in a project that transitively depends on multiple per method packages and/or the main lodash package. Whereas many methods in the main lodash package share code, the per method packages internally bundle copies of any code they depend on.

In #3838 @jdalton mentions,

I can't deprecate them with the npm deprecate method since that sends a log to stderr and causes some build scripts to fail. So I will simply let it fade away without a v5 update.

[jdalton]

@Jessegerard Depending on the context specifying __proto__ may be what the user intended. I try to only block property path access if the behavior is unintentional.