Prototype pollution

The point to grasp: prototype pollution is not itself RCE or XSS — it is an amplifier that turns a seemingly harmless merge bug into almost any other vulnerability, depending on where the app reads the polluted property.

The amplification mechanism: after Object.prototype.x = "evil", EVERY object without its own x returns "evil" when you read obj.x. So depending on what property the code reads, the outcome is:

• RCE in Node.js — if a library reads an option (like shell, NODE_OPTIONS) from a polluted object and passes it to child_process.
• XSS — if a template/framework reads a polluted property and puts it into HTML.
• Authorisation bypass — if the code checks if (user.isAdmin) and isAdmin is polluted to true on every object that does not set it explicitly.
• DoS — corrupting a property the runtime relies on.

Three things that make it hard:

• It lives in a dependency, not your code. Many library merge/clone functions (old lodash, old jQuery, hand-written deep-merge functions) are the entry point — you did not write them.
• It acts at a distance. The object is poisoned in one place, the consequence fires elsewhere reading that property, so it is hard to trace.
• The gadget depends on the classpath, like deserialization: the same harmless prototype pollution on one app is RCE on another because it has a library reading the exact polluted property.

The mechanism rests on JavaScript's prototype chain: reading obj.x where obj has no x makes JS climb to obj.__proto__ (i.e. Object.prototype). Writing there writes to the prototype shared by every object.

flowchart TD    P["User JSON:<br/>{ \"__proto__\": { \"isAdmin\": true } }"] --> M{Recursive merge function}    M -->|"Recurses into the __proto__ key<br/>without filtering"| W["Object.prototype.isAdmin = true"]    W --> A["EVERY object without its own isAdmin<br/>now returns true when reading .isAdmin"]    A --> B1["if (user.isAdmin) → authorisation bypass"]    A --> B2["opts.shell → RCE if it reaches child_process"]    A --> B3["a polluted property → XSS/DoS"]    M -->|"Blocks __proto__, constructor,<br/>prototype"| G["Merges only own keys → safe"]

The key point: the object is poisoned at the merge layer, but the consequence fires elsewhere reading the property. This "action at a distance" is what makes it hard to trace — and why prototype pollution is an amplifier, not a target vulnerability on its own.

A table of entry points and poison keys:

A subtle point: JSON.parse('{"__proto__":{"x":1}}') does NOT pollute on its own — it creates an own property literally named __proto__. Pollution happens when a later merge/set-path function recurses into that key and assigns. So the fix is in the merge function, not in JSON.parse.

A settings-update endpoint using a hand-written deep-merge function.

# The poisoning payload. __proto__ enters the merge function and writes to Object.prototype.POST /api/settings HTTP/1.1Content-Type: application/json {"theme":"dark","__proto__":{"isAdmin":true}}

// The merge function recurses into the "__proto__" key and assigns → Object.prototype.isAdmin = true.// From now on, EVERY object that does not set its own isAdmin returns true:({}).isAdmin            // → true  (!!)someUser.isAdmin        // → true, though someUser has no such field

The object is poisoned at the merge layer, but the consequence fires EVERYWHERE that reads .isAdmin — including an authorisation check in a completely different request from a different user. This is "action at a distance".

// RCE variant (Node.js): if a library reads an option from a polluted object.// Payload: {"__proto__":{"shell":"/bin/sh","argv0":"..."}}// then somewhere: child_process.spawn("ls", [], opts)  ← opts.shell is now "/bin/sh"// → turns a harmless spawn into shell execution (intersects the command-injection topic).

// The subtle point: JSON.parse does NOT pollute on its own.const o = JSON.parse('{"__proto__":{"x":1}}');  // o has an OWN property named "__proto__"({}).x   // → undefined  (not polluted yet!)// Pollution happens only when a later MERGE function recurses into that key and assigns. The fix is in the merge.

# After the fix: the merge function blocks __proto__/constructor/prototype, and uses a Map/null-proto# object for user-controlled data.

Lodash CVE-2019-10744 (_.defaultsDeep) and the family of lodash prototype-pollution CVEs. One of the most-used libraries on npm had several merge/set functions vulnerable to prototype pollution, so hundreds of thousands of projects inherited the flaw without writing a line of related code. Memorable because it illustrates block 2's point: the entry point is in a DEPENDENCY, not your code.

Prototype pollution → RCE in Node tooling (many CVEs). Research (notably by Michał Bentkowski and Posix) showed the chain from prototype pollution to RCE via gadgets like child_process options, template engines, and require. It is the source of the "gadget depends on the classpath" concept in block 2 — exactly like deserialization.

Client-side prototype pollution → XSS (many reports). In the browser, a prototype pollution via the query string (?__proto__[...]) plus a gadget in a client library (a sink reading a polluted property and writing it to the DOM) is XSS. It illustrates the amplifier nature: the same pollution, different consequences depending on which gadget is present.

1. A unit test: the poisoning payload does NOT pollute the prototype. This is the core check, and the assertion must be right: after calling the merge function with {"__proto__":{"polluted":1}}, assert ({}).polluted is still undefined. See the typescript / test tab.

2. Grep for merge/set-by-path functions and JSON feeding them:

# Hand-written deep merge and pollution-prone APIs.grep -rnE '_\.(merge|mergeWith|defaultsDeep|set|setWith)\(|Object\.assign\(.*JSON\.parse' \  --include='*.ts' --include='*.tsx' --include='*.js' src/ \  && echo "WARNING: a merge/set may take user input — check the version and data source"# A hand-written deep merge (recursively assigning by key) is the most common entry point.grep -rnE 'for .* in .*\)[^{]*{[^}]*\[key\] *=' --include='*.ts' src/ \  && echo "WARNING: possibly a hand-written deep merge — check it blocks __proto__"

3. An end-to-end test through a JSON-accepting endpoint — a real body payload:

B=https://staging.example.comcurl -s -X POST "$B/api/settings" -H 'Content-Type: application/json' \  -d '{"theme":"dark","__proto__":{"isAdmin":true}}' > /dev/null# Then check an authorisation-gated endpoint — an ordinary user must NOT have become admin.curl -s "$B/api/admin/users" -b "session=$ORDINARY_USER" -o /dev/null -w '%{http_code}\n'# Must be 403. If 200 → prototype pollution bypassed authorisation.

4. Check Object.freeze(Object.prototype) is called at startup:

grep -rn "Object.freeze(Object.prototype)" --include='*.ts' src/ \  || echo "WARNING: no Object.freeze(Object.prototype) found — the one-line control is missing"

5. Check dependencies have no known prototype pollution (intersects the dependencies-sbom topic):

npm audit --audit-level=high 2>&1 | grep -i 'prototype pollution' \  && { echo "a dependency with known prototype pollution is present"; exit 1; }exit 0

The classification mistake, and it is the central one: treating prototype pollution as "dirties an object, low risk". It is an AMPLIFIER — like deserialization, the consequence depends on the gadgets in the classpath, and on an app with the right gadget it is RCE. Rate it by the worst possible gadget, not by the dirtying itself.

The location mistake: looking for the fix at JSON.parse. JSON.parse does not pollute (block 3). The entry point is the MERGE/SET-BY-PATH function — usually in a dependency — so the way to find it is to grep those functions and check they block the three poison keys, not to filter the JSON string.