Update dependency lodash to v4.18.1 [SECURITY]#2859
Update dependency lodash to v4.18.1 [SECURITY]#2859gardener-prow[bot] merged 1 commit intomasterfrom
Conversation
📝 WalkthroughWalkthroughThe Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
LGTM label has been added. DetailsGit tree hash: 862406686d0fead572668d3c46647860540b82f0 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: petersutter The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.pnp.cjs (1)
11347-11350: Ensure Yarn cache is regenerated properly.Since
.pnp.cjsis auto-generated by Yarn PnP, ensure that the Yarn cache (.yarn/cache/) has been properly updated and the new lodash package at the specified location (./.yarn/cache/lodash-npm-4.18.1-a64c3070ac-757228fc68.zip/) is present. If Renovate didn't regenerate the cache, runyarn installto update the PnP state and cache consistently.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.pnp.cjs around lines 11347 - 11350, The .pnp.cjs entry for ["npm:4.18.1", { "packageLocation": "./.yarn/cache/lodash-npm-4.18.1-a64c3070ac-757228fc68.zip/node_modules/lodash/", ... }] indicates the Yarn PnP cache may be out of sync; to fix, regenerate the Yarn PnP cache by running yarn install (or yarn --immutable if CI) locally so .yarn/cache contains the referenced lodash zip, then commit the updated .pnp.cjs and any changed cache artifacts; verify the packageLocation path and lodash version (4.18.1) are present after the install before pushing.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.pnp.cjs:
- Around line 11347-11350: The .pnp.cjs entry for ["npm:4.18.1", {
"packageLocation":
"./.yarn/cache/lodash-npm-4.18.1-a64c3070ac-757228fc68.zip/node_modules/lodash/",
... }] indicates the Yarn PnP cache may be out of sync; to fix, regenerate the
Yarn PnP cache by running yarn install (or yarn --immutable if CI) locally so
.yarn/cache contains the referenced lodash zip, then commit the updated .pnp.cjs
and any changed cache artifacts; verify the packageLocation path and lodash
version (4.18.1) are present after the install before pushing.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 90f71827-301b-4825-bbf3-f48624f3131b
⛔ Files ignored due to path filters (2)
.yarn/cache/lodash-npm-4.18.1-a64c3070ac-757228fc68.zipis excluded by!**/.yarn/**,!**/*.zipyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (1)
.pnp.cjs
This PR contains the following updates:
4.17.23→4.18.1GitHub Vulnerability Alerts
CVE-2026-2950
Impact
Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the
_.unsetand_.omitfunctions. The fix for CVE-2025-13465 only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such asObject.prototype,Number.prototype, andString.prototype.The issue permits deletion of prototype properties but does not allow overwriting their original behavior.
Patches
This issue is patched in 4.18.0.
Workarounds
None. Upgrade to the patched version.
CVE-2026-4800
Impact
The fix for CVE-2021-23337 added validation for the
variableoption in_.templatebut did not apply the same validation tooptions.importskey names. Both paths flow into the sameFunction()constructor sink.When an application passes untrusted input as
options.importskey names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time.Additionally,
_.templateusesassignInWithto merge imports, which enumerates inherited properties viafor..in. IfObject.prototypehas been polluted by any other vector, the polluted keys are copied into the imports object and passed toFunction().Patches
Users should upgrade to version 4.18.0.
The fix applies two changes:
importsKeysagainst the existingreForbiddenIdentifierCharsregex (same check already used for thevariableoption)assignInWithwithassignWithwhen merging imports, so only own properties are enumeratedWorkarounds
Do not pass untrusted input as key names in
options.imports. Only use developer-controlled, static key names.Release Notes
lodash/lodash (lodash)
v4.18.1Compare Source
Bugs
Fixes a
ReferenceErrorissue inlodashlodash-eslodash-amdandlodash.templatewhen using thetemplateandfromPairsfunctions from the modular builds. See #6167 (comment)These defects were related to how lodash distributions are built from the main branch using https://github.com/lodash-archive/lodash-cli. When internal dependencies change inside lodash functions, equivalent updates need to be made to a mapping in the lodash-cli. (hey, it was ahead of its time once upon a time!). We know this, but we missed it in the last release. It's the kind of thing that passes in CI, but fails bc the build is not the same thing you tested.
There is no diff on main for this, but you can see the diffs for each of the npm packages on their respective branches:
lodash: lodash/lodash@4.18.0-npm...4.18.1-npmlodash-es: lodash/lodash@4.18.0-es...4.18.1-eslodash-amd: lodash/lodash@4.18.0-amd...4.18.1-amdlodash.templatelodash/lodash@4.18.0-npm-packages...4.18.1-npm-packagesv4.18.0Compare Source
v4.18.0
Full Changelog: lodash/lodash@4.17.23...4.18.0
Security
_.unset/_.omit: Fixed prototype pollution viaconstructor/prototypepath traversal (GHSA-f23m-r3pf-42rh, fe8d32e). Previously, array-wrapped path segments and primitive roots could bypass the existing guards, allowing deletion of properties from built-in prototypes. Nowconstructorandprototypeare blocked unconditionally as non-terminal path keys, matchingbaseSet. Calls that previously returnedtrueand deleted the property now returnfalseand leave the target untouched._.template: Fixed code injection viaimportskeys (GHSA-r5fr-rjxr-66jc, CVE-2026-4800, 879aaa9). Fixes an incomplete patch for CVE-2021-23337. Thevariableoption was validated againstreForbiddenIdentifierCharsbutimportsKeyswas left unguarded, allowing code injection via the sameFunction()constructor sink.importskeys containing forbidden identifier characters now throw"Invalid imports option passed into _.template".Docs
_.templatein threat model and API docs (#6099)lower > upperbehavior in_.random(#6115)_.compactjsdoc (#6090)lodash.*modular packagesDiff
We have also regenerated and published a select number of the
lodash.*modular packages.These modular packages had fallen out of sync significantly from the minor/patch updates to lodash. Specifically, we have brought the following packages up to parity w/ the latest lodash release because they have had CVEs on them in the past:
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Renovate Bot.
Summary by CodeRabbit