Outdated Lodash Library Could Allow Attackers to Disrupt Your Application

Vulnerability Explanation

Lodash versions 4.0.0 through 4.17.22 are vulnerable to prototype pollution in the _.unset and _.omit functions. When an attacker supplies a crafted path containing prototype chain references such as '__proto__' or 'constructor.prototype', the internal baseUnset function follows these paths without validation and deletes properties from global JavaScript prototypes (e.g., Object.prototype). Unlike classic prototype pollution write primitives, this variant is a delete primitive: it cannot overwrite prototype methods with attacker-controlled values, but it can remove them entirely. Removing built-in prototype methods causes any code in the same JavaScript runtime that relies on those methods to throw TypeErrors or behave unexpectedly, which can result in denial of service or unpredictable application state.

Root Cause

The root cause is in Lodash's internal baseUnset function, which resolves and deletes object properties by path. Prior to 4.17.23, this function did not validate or sanitize the provided path, allowing traversal up the prototype chain via '__proto__' or 'constructor.prototype' segments. The fix in 4.17.23 adds path sanitization to block prototype-traversing segments before the delete operation is performed.

Technical Impact

An attacker who can control input passed to _.unset() or _.omit() can delete properties from global prototypes (e.g., Object.prototype.toString, Array.prototype.map). This causes denial of service (application crashes or TypeErrors) for any code in the same runtime that depends on those prototype methods. Confidentiality impact is none; integrity and availability are both limited to moderate depending on which prototype methods are deleted.

Severity Justification

CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L. Exploitability is high (network, no auth, no interaction required), but impact is constrained: attackers can only delete prototype properties, not overwrite them, limiting the blast radius to availability and limited integrity disruption. Exploitability is conditional on user-controlled input reaching _.unset or _.omit.

Affected Components

• lodash >= 4.0.0, <= 4.17.22
• lodash-es >= 4.0.0, <= 4.17.22
• lodash-amd >= 4.0.0, <= 4.17.22
• lodash.unset >= 4.0.0, <= 4.5.2 (no patch available for standalone package)

Remediation Steps

1. Upgrade lodash (or lodash-es / lodash-amd) to version 4.17.23 or later: run `npm install lodash@^4.17.23` and commit the updated package-lock.json.
2. If you use the standalone `lodash.unset` npm package, note that no patched version exists yet. Replace it with the full `lodash` package at 4.17.23 or implement the input sanitization workaround below.
3. If an immediate upgrade is blocked, sanitize all paths passed to _.unset and _.omit by rejecting or stripping segments equal to '__proto__', 'prototype', or 'constructor' before passing them to Lodash.
4. Run your test suite after upgrading to confirm no regressions — the 4.17.23 release is a patch-level update with no breaking API changes.
5. Audit your codebase for any call sites where user-supplied data flows into _.unset or _.omit, and add input validation at those points as a defense-in-depth measure.

Verification Steps

1. Run `npm list lodash` (and `npm list lodash-es`, `npm list lodash-amd`) to confirm the installed version is 4.17.23 or higher.
2. Run `node -e "const _ = require('lodash'); _.unset({}, '__proto__.polluted'); console.log(({}).polluted === undefined ? 'SAFE' : 'VULNERABLE');"` — a safe installation prints 'SAFE'.
3. Check your package-lock.json or yarn.lock to ensure no transitive dependency is pinning an older version of lodash.

Code Examples (javascript)

// Vulnerable: user-controlled path reaches _.unset
const _ = require('lodash'); // version < 4.17.23
app.post('/remove-field', (req, res) => {
  const { obj, path } = req.body;
  _.unset(obj, path); // attacker sends path = '__proto__.toString'
  res.json(obj);
});

// Option 1: Upgrade to lodash 4.17.23+ (preferred)
// package.json: "lodash": "^4.17.23"

// Option 2: Sanitize paths if upgrade is temporarily blocked
const DANGEROUS_SEGMENTS = new Set(['__proto__', 'prototype', 'constructor']);
function safePath(path) {
  return String(path).split('.').filter(seg => !DANGEROUS_SEGMENTS.has(seg)).join('.');
}
app.post('/remove-field', (req, res) => {
  const { obj, path } = req.body;
  _.unset(obj, safePath(path));
  res.json(obj);
});

Best Practices

• Never pass unsanitized user input directly as a path argument to Lodash path-based functions (_.unset, _.omit, _.set, _.get, _.has).
• Pin dependencies to exact or tightly bounded versions in production and use a lock file (package-lock.json / yarn.lock) to prevent silent upgrades to vulnerable versions.
• Integrate automated dependency vulnerability scanning (e.g., `npm audit`, Dependabot, or Snyk) into your CI/CD pipeline to catch issues like this before they reach production.
• Consider using objects without prototypes (Object.create(null)) for data structures that process untrusted input, breaking the prototype chain as a defense-in-depth measure.

References

• github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg
• github.com/advisories/GHSA-xxjr-mmjv-4gpg
• nvd.nist.gov/vuln/detail/CVE-2025-13465
• security.snyk.io/vuln/SNYK-JS-LODASH-15053838