[depthfirst-2536] Upgrade lodash to 4.18.0

[depthfirst-app]

Overview

• Repair Link

Upgrade lodash to 4.18.1 in packages/xrpl

Upgrade

• Upgraded the lodash dependency from ^4.17.4 to ^4.18.0 in packages/xrpl/package.json.
• Updated package-lock.json to resolve and install version 4.18.1. This version satisfies the new constraint, resolving high-severity security vulnerabilities while remaining compatible with previous 4.x versions.

Changes

• Updated the semantic version constraint for lodash in packages/xrpl/package.json.
• Regenerated package-lock.json to properly lock the new 4.18.1 version and its integrity hash globally.
• No other code modifications were necessary since the upgrade was verified safely without breaking existing tests.

Warnings

• The 4.18.x release introduces stricter validations to patch previous exploits:
  • constructor and prototype are now unconditionally blocked as non-terminal path keys in _.unset and _.omit.
  • Untrusted string inputs or forbidden identifiers in _.template imports will now throw an "Invalid imports option passed into _.template" error.
• Reviewers should double-check that the application does not rely on these specific legacy behaviors or mutating built-in prototypes.

Next Steps

• Verify the build and tests in the CI pipeline.
• Review and merge the pull request to deploy the security patches.

Vulnerabilities Fixed

• lodash vulnerable to Prototype Pollution via array path bypass in _.unset and _.omit

  • Summary: lodash vulnerable to Prototype Pollution via array path bypass in _.unset and _.omit
  • ID: CVE-2026-2950
  • Details: Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the _.unset and _.omit functions. The fix for CVE-2025-13465 only guarded against string key members, allowing an attacker to bypass the check by passing array-wrapped path segments. This allows the deletion of properties from built-in prototypes such as Object.prototype, Number.prototype, and String.prototype. The issue permits deletion of prototype properties but does not allow overwriting their original behavior.
  • References:
    • GHSA-f23m-r3pf-42rh
    • GHSA-xxjr-mmjv-4gpg
    • NVD Advisory
    • lodash Package

• lodash vulnerable to Code Injection via _.template imports key names

  • Summary: lodash vulnerable to Code Injection via _.template imports key names
  • ID: CVE-2026-4800
  • Details: The fix for CVE-2021-23337 added validation for the variable option in _.template but did not apply the same validation to options.imports key names. Both paths flow into the same Function() constructor sink. When an application passes untrusted input as options.imports key names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time. Additionally, _.template used assignInWith to merge imports, which enumerated inherited properties via for..in. If Object.prototype had been polluted, the polluted keys were copied into the imports object and passed to Function().
  • References:
    • GHSA-r5fr-rjxr-66jc
    • NVD Advisory
    • Commit 3469357
    • GHSA-35jh-r3h4-6jhm
    • OpenJSF Security Advisories
    • lodash Package

[kuan121]

Close as lodash has been upgraded in #3271