Lodash: The Delete Button for the Universe (CVE-2025-13465)

Lodash is the duct tape of the JavaScript ecosystem. It is the library you reach for when you realize JavaScript's standard library is missing the tools you actually need to do your job. It handles deep cloning, debouncing, and, crucially for this story, object manipulation. We trust it implicitly. We feed it our user input, our JSON blobs, and our complex state objects, expecting it to behave deterministically.

But here is the thing about utility belts: if you pull the wrong lever, you might just detach the floor you are standing on. CVE-2025-13465 isn't your standard 'injection' vulnerability where we sneak in a script tag. It is a Prototype Pollution flaw, but with a nihilistic twist.

Usually, hackers use prototype pollution to add properties—polluting the water supply, so to speak. This vulnerability allows us to delete properties. We aren't adding poison to the well; we are evaporating the water entirely. By targeting _.unset or _.omit, we can reach into the very soul of the JavaScript runtime—Object.prototype—and rip out methods that the application needs to breathe.

The root of this vulnerability lies in how Lodash interprets 'paths'. When you tell Lodash to unset a property at a.b.c, it has to traverse the object graph to find c. It does this by splitting the string into segments or accepting an array of keys. The underlying engine for this is a function called baseUnset.

In vulnerable versions (pre-4.17.23), baseUnset was entirely too trusting. It would happily accept path segments like __proto__ or constructor and prototype. It treated them as valid keys to traverse. It didn't pause to ask, "Wait, should I really be climbing up the inheritance chain into the global scope?"

Because JavaScript objects are mutable by default, and because almost everything in JavaScript inherits from Object, traversing up to Object.prototype gives you write access to the blueprint of every object in the system. The flaw isn't just that it traverses; it's that after traversing, it executes the delete operator. While delete cannot remove non-configurable properties, many vital methods on the prototype chain are, in fact, configurable.

Let's look at the smoking gun. The fix was applied in baseUnset. The developers had to introduce a strict validation loop that runs before any traversal happens. They couldn't just check the final key; they had to check every step of the path.

Here is the logic introduced in commit edadd452146f7e4bad4ea684e955708931d84d81:

// The Fix Logic
while (++index < length) {
  var key = path[index];
  // ... checks for non-string keys ...
 
  // BLOCK 1: The Classic Proto
  if (key === '__proto__' && !hasOwnProperty.call(object, '__proto__')) {
    return false;
  }
 
  // BLOCK 2: The Constructor Bypass
  if (key === 'constructor' &&
      (index + 1) < length &&
      path[index + 1] === 'prototype') {
    // ... strict checks for primitive roots ...
    return false;
  }
}

Analysis:

1. __proto__ Check: It explicitly looks for __proto__. If found, it ensures it's an "own" property (a real key on the object) rather than the inherited accessor. If it's the accessor, it bails.
2. constructor.prototype Check: Attackers often bypass __proto__ filters by going through constructor.prototype. The patch explicitly looks for this sequence. If it sees constructor followed immediately by prototype, it hard-stops the operation.

This creates a whitelist of sorts—you can traverse anywhere except the forbidden zones of the prototype chain.

How do we weaponize this? We don't need RCE to ruin a sysadmin's day. A Denial of Service (DoS) via prototype deletion is often harder to debug than a crash. The application enters a "zombie state" where basic language features stop working.

Imagine a backend service that accepts a JSON payload to update user preferences. The code uses _.unset to remove restricted keys before saving.

The Setup:

const _ = require('lodash');
// The victim code
app.post('/update', (req, res) => {
   let userInput = req.body;
   // Developer tries to be safe by unsetting a specific field
   // But 'userInput.fieldToRemove' is controlled by the attacker
   _.unset(userInput.data, userInput.fieldToRemove);
});

The Attack: We send a payload where fieldToRemove is constructor.prototype.toString.

The Execution Flow:

1. Lodash receives the path ['constructor', 'prototype', 'toString'].
2. It traverses userInput.data.constructor, which is Object.
3. It traverses .prototype, which is Object.prototype.
4. It executes delete Object.prototype['toString'].

The Aftermath: The next time any part of that Node.js process tries to cast an object to a string (e.g., inside a logging library, an error handler, or a template engine), it will fail. [object Object] is gone. The application throws TypeError: ... is not a function and crashes. If you have an auto-restarter, it creates a crash loop until the malicious payload is flushed.

You might think, "So it crashes, big deal." But consider the subtlety. You can delete hasOwnProperty.

Many security mechanisms rely on obj.hasOwnProperty('isAdmin') to verify data integrity. If you delete hasOwnProperty from the prototype, the check might throw an error (DoS) or, depending on the implementation (e.g., try/catch blocks that swallow errors), it might fail open.

Furthermore, this vulnerability impacts _.omit as well. If an application uses _.omit(req.body, blocklist), an attacker can craft a request that pollutes the prototype during the omission process. Since Lodash is the backbone of thousands of high-traffic enterprise applications, the blast radius is massive. It turns a simple data processing utility into a remote kill switch.

The remediation is straightforward but urgent. You must upgrade Lodash.

Primary Fix: Update to version 4.17.23 or later.

npm install lodash@latest

Defense in Depth: Even with the patch, you should stop trusting objects. JavaScript provides tools to harden your environment against this class of bugs entirely:

1. Object.freeze(Object.prototype): At the very start of your application, freeze the prototype. This prevents any library from modifying or deleting core methods.
2. Use Map instead of Objects: For hash maps where keys are user-controlled, use the Map structure. It doesn't have a prototype chain to pollute.
3. Input Validation: Never allow users to define paths for property access. Validate that keys are alphanumeric and do not contain special property names.