hunting-server-side-prototype-pollution

Hunting server-side prototype pollution: when one request changes every object

In JavaScript, every plain object inherits from Object.prototype, so writing to that shared prototype changes the default value of a property on every object in the process. Server-side prototype pollution happens when untrusted input carries a __proto__, constructor, or prototype key into a recursive merge, a deep clone, or a path-based set that follows the key down to the prototype. The write by itself is a primitive; the impact comes later, when some other code reads a property that was never set and now returns the attacker's injected default. That gadget read can flip an authorization flag, inject an argument into a spawned command, or change a template or query. You find it by locating the pollution primitives and then the gadget reads they enable.

When to use

• A Node.js or server-side TypeScript service merges, clones, or path-assigns untrusted structured input.
• A parser or utility recurses into keys from a request body, query string, or JSON document.
• Later code reads object properties that may be unset, where an injected default would change behavior.

Scope check

Test prototype pollution only against services you own or are authorized to assess, on non-production infrastructure. Pollution is process-wide and can affect concurrent requests, so treat every confirming write as a change to shared state within the authorized scope, and prefer an isolated instance. If you can't name the authorization, stop.

The loop

1. Establish the pollution primitives first. Inventory every operation that could write an attacker-controlled key down to the prototype: recursive or deep merges, deep clones, path-based setters that split a dotted or bracketed path, and body or query parsers that build nested objects. This is the false-positive killer: without a primitive that reaches __proto__ or constructor.prototype, an isolated gadget read is not exploitable. Name the primitives first.