Prototype Pollution: Tracing Exploitable Paths in Node.js Libraries

You merge a user-supplied JSON object into a config hash, your app starts behaving strangely, and there are no errors in the log. That's prototype pollution — a vulnerability class that corrupts JavaScript's shared prototype chain and can escalate from a minor logic bug all the way to remote code execution.

It shows up constantly in real-world Node.js audits because the patterns that introduce it — deep merge, recursive clone, path-based assignment — are everywhere in popular libraries.

What you'll learn

• How JavaScript's prototype chain makes this class of bug possible
• Where vulnerable patterns appear in common Node.js libraries
• How attackers trace gadget chains from pollution to RCE or privilege escalation
• Reliable detection techniques for your own codebase
• Concrete mitigations that don't just paper over the problem

What Is Prototype Pollution?

Prototype pollution happens when an attacker can write arbitrary properties to Object.prototype — the base object that almost every JavaScript object inherits from. Once a property is written there, every plain object in the process inherits it. Code that checks obj.isAdmin will now find true even on an empty {}, because the prototype carries it.

This is not a theoretical concern. CVEs have been filed against lodash, jQuery, express-fileupload, node-forge, and dozens of other widely-deployed packages. The impact ranges from denial of service and property injection to, in the right conditions, remote code execution.

How JavaScript Prototypes Work (the Part That Gets Exploited)

Every JavaScript object has an internal prototype link. When you access a property, the engine walks up the chain — from the object itself, to its prototype, to that prototype's prototype — until it hits null. For a plain object literal like {}, the chain ends at Object.prototype.

That means these three access paths all refer to the same thing:

const obj = {};
obj.__proto__ === Object.prototype;              // true
Object.getPrototypeOf(obj) === Object.prototype; // true
obj.constructor.prototype === Object.prototype;  // true

__proto__ is the historical accessor. It's not an own property; it's a getter/setter wired directly into the prototype chain. When a recursive merge function reads a key named __proto__ from user data and writes its value onto the destination object, it's not setting an own property called __proto__ — it's invoking the setter, which reassigns the prototype. That's the root of the vulnerability.

Anatomy of a Prototype Pollution Attack

Here's the simplest possible vulnerable function — a naive deep merge that you'll recognize in dozens of helper libraries:

function merge(target, source) {
  for (const key of Object.keys(source)) {
    if (typeof source[key] === 'object' && source[key] !== null) {
      if (!target[key]) target[key] = {};
      merge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

Now send this payload — perhaps as a parsed JSON body from an HTTP request:

{
  "__proto__": {
    "isAdmin": true
  }
}

The loop iterates over keys and finds __proto__. It recurses into merge(target["__proto__"], { isAdmin: true }). Because target["__proto__"] resolves to Object.prototype via the getter, this effectively calls merge(Object.prototype, { isAdmin: true }) and writes isAdmin = true onto the shared prototype. Every subsequent plain object in the process now has .isAdmin === true.

The same attack works through two other bypass vectors:

• constructor path: { "constructor": { "prototype": { "isAdmin": true } } }
• path-based setters: any function that resolves a dotted or bracketed key path like _.set(obj, "__proto__.isAdmin", true)

Common Vulnerable Patterns in Node.js Libraries

The attack surface is wider than most developers expect. These four patterns account for the vast majority of real CVEs:

Deep merge / extend

Libraries like merge, deepmerge, lodash.merge (pre-patch), and jQuery.extend(true, ...) all recursively copy keys. Older versions walked directly into __proto__ without sanitization. Check that any merge library you use is current and has explicit prototype pollution guards in its changelog.

Deep clone

Functions that serialize then deserialize with JSON.parse(JSON.stringify(obj)) are actually safe here — the process drops the prototype chain. But hand-rolled recursive clone functions suffer the same flaw as merge.

Path-based property assignment

Functions like _.set(obj, path, value) or any utility that splits a string like "a.b.c" and drills into nested keys can be weaponized with a path like "__proto__.polluted". Lodash patched this (CVE-2019-10744); make sure you're not pinning an old version.

Query-string and body parsers

Certain query-string parsers convert repeated bracket notation into nested objects. A request parameter like ?__proto__[admin]=1 can produce { __proto__: { admin: '1' } } before that object ever reaches your merge logic, essentially pre-staging the pollution. The qs library handles this correctly when allowPrototypes is left at its default (false); double-check your configuration.

Tracing Exploitable Gadget Chains

Pollution by itself is rarely game-over. The real question is whether there's a gadget — a code path elsewhere in the process that reads a prototype property and does something dangerous with it. This is structurally similar to the gadget chain concept in insecure deserialization attacks.

Property injection gadgets

The simplest gadgets are permission or configuration checks. Code like the following is common in Express middleware:

if (req.user.isAdmin) {
  grantAccess();
}

If req.user is a plain object constructed from database results, it inherits from Object.prototype. After pollution, every user becomes an admin without touching the database.

Template engine gadgets (path to RCE)

Several template engines in the Node.js ecosystem — particularly older versions of Handlebars and Pug — use properties from the data context during compilation. If a polluted prototype property ends up influencing code generation or eval-adjacent logic, you get RCE. The Handlebars CVE-2019-19919 is the canonical example: polluting Object.prototype.pendingContent caused the engine to inject attacker-controlled strings into generated JavaScript that was then evaluated.

Child process gadgets

Some libraries use options objects passed to child_process.spawn or exec. If those option objects are plain {} literals and the library reads, say, options.shell or options.env, a polluted prototype can force a shell or inject environment variables, both of which can lead to code execution.

Tracing the path manually

When auditing a specific library, the process looks like this:

1. Identify the entry point where user-controlled data is merged, cloned, or assigned.
2. Confirm you can reach Object.prototype through __proto__, constructor.prototype, or a path-based setter.
3. Search the codebase (and its dependencies) for reads on plain objects where the property name is not statically known or not validated against an allowlist.
4. Follow the data flow from that read to any dangerous sink: eval, exec, spawn, require, filesystem operations, or access-control checks.

Automated scanners like semgrep with the NodeJS security ruleset, and CodeQL's JavaScript prototype pollution query, can do much of step three mechanically — but manual review of the gadget chain is still necessary.

Detecting Prototype Pollution in Your Codebase

Start with your dependency tree. Run npm audit and cross-reference findings against the Snyk vulnerability database. Known prototype pollution CVEs will surface here if you're on a vulnerable version.

For dynamic detection during testing, you can freeze Object.prototype at application startup and let any write throw an error:

Object.freeze(Object.prototype);

This is a blunt instrument — some libraries legitimately add polyfills — but it's very effective in a test environment for flushing out pollution attempts. Any write to Object.prototype will now throw a TypeError in strict mode, giving you an immediate stack trace.

You can also write a targeted check after any operation that processes untrusted input:

function isPolluted() {
  return Object.prototype.hasOwnProperty('pollutedKey');
}

This is useful in integration tests where you send crafted payloads and assert no pollution occurred.

For static analysis, the CodeQL query javascript/prototype-pollution traces data flow from sources (HTTP request body, query parameters) to sinks (recursive merge, path-based assignment). Running it in CI catches regressions before they ship.

Mitigations That Actually Work

Validate and sanitize keys before merging

The most targeted fix: strip dangerous keys before any recursive operation touches user data.

function sanitizeKeys(obj) {
  if (typeof obj !== 'object' || obj === null) return obj;
  const dangerous = new Set(['__proto__', 'constructor', 'prototype']);
  for (const key of Object.keys(obj)) {
    if (dangerous.has(key)) {
      delete obj[key];
    } else {
      sanitizeKeys(obj[key]);
    }
  }
  return obj;
}

Call this on any parsed JSON before passing it into a merge or clone operation. It's shallow enough to reason about and adds negligible overhead.

Use Object.create(null) for accumulator objects

Objects created with Object.create(null) have no prototype at all — there's no Object.prototype to pollute through them. Use them as dictionaries when you're merging arbitrary user keys:

const safe = Object.create(null);
merge(safe, userInput); // __proto__ write has nowhere to land

This works because safe.__proto__ is simply undefined; the setter is never invoked.

JSON schema validation at the boundary

Use a strict schema validator (Ajv, Zod, Joi) with an allowlist of permitted keys. This is the right approach for any user-facing API endpoint: reject any input that contains keys outside the declared schema. A payload with __proto__ never reaches your merge logic because validation fails first. This overlaps with good input validation practice that applies broadly — see how similar boundary enforcement stops SSRF attacks in cloud environments.

Prefer structured cloning or safe alternatives

For deep clone specifically, Node.js 17+ ships structuredClone() as a built-in. It performs a deep copy without traversing the prototype chain and is safe against this class of attack.

const cloned = structuredClone(userInput);

For merge, use a library that has an explicit prototype pollution fix in its changelog and pin a safe version in your package.json.

Freeze Object.prototype in production (carefully)

In environments where you fully control the dependency tree and have tested compatibility, Object.freeze(Object.prototype) at process startup is a strong defense. Any attempt to write to the shared prototype throws immediately. The trade-off is that it will break any code — including library code — that polyfills methods onto Object.prototype, so test thoroughly.

Content Security Policy and sandboxing

For scenarios where pollution leads toward DOM-based or template-based code injection, a well-configured CSP limits what injected scripts can do. This is a defense-in-depth layer, not a primary fix. It's the same layered thinking that applies when protecting against token forgery via JWT validation mistakes — fix the root cause and add layers.

Common Pitfalls When Trying to Fix This

Blocking only __proto__ but not constructor.prototype. Attackers know about both. Your sanitizer must handle all three dangerous key names: __proto__, constructor, and prototype. Some implementations block the first and forget the other two.

Updating lodash but missing transitive dependencies. A direct dependency may be clean while an indirect dependency three levels down carries a vulnerable version. Run npm audit --all and check npm ls lodash to see every instance in your tree, not just the top-level one.

Treating JSON.parse as inherently safe. JSON.parse does not execute prototype setters — a string like "{\"__proto__\":{\"x\":1}}" produces a plain object with an own property named __proto__, not a prototype mutation. The mutation happens in step two, when your code merges that parsed object. The parser is not the problem; the merge is.

Only testing the happy path. Integration tests that only send valid payloads will never catch this. Add explicit adversarial test cases that send __proto__ payloads and assert that Object.prototype remains clean after the request is processed.

Wrapping Up: Next Steps

Prototype pollution is dangerous precisely because it's invisible at the point of injection — the symptoms appear somewhere else in your code, often in a completely different module. The fix requires understanding both where the pollution enters and where the gadgets live.

Take these concrete actions:

1. Run npm audit today and check for any prototype pollution CVEs in your dependency tree, including transitive dependencies.
2. Add a key sanitizer to every code path that merges user-supplied JSON into a plain object.
3. Swap hand-rolled deep clone functions for structuredClone() or a well-maintained library with a verified fix.
4. Add adversarial test cases to your integration suite that send __proto__ and constructor.prototype payloads and assert Object.prototype is clean afterward.
5. Set up CodeQL or Semgrep in your CI pipeline with the prototype pollution ruleset so regressions surface before they reach production.