Thanks for the link, this is a much clearer example of how prototype pollution can be an important vector.As another commenter noted, if one can directly inject literal JS code that writes to __proto__, you&#x27;ve already got RCE.The case where prototype pollution happens without arbitrary RCE looks like:- User input can set arbitrary fields of an object and its properties, allowing the user to add or alter a field on a `__proto__` that references a widely-shared prototype;- The existence or value of that field non-locally affects other code which assumes that the prototype is not under user control.

This article is not very good in convincing that prototype pollution is a problem.There was a write up about the kibana rce that really shows it&#x27;s a problem:<a href="https:&#x2F;&#x2F;research.securitum.com&#x2F;prototype-pollution-rce-kibana-cve-2019-7609&#x2F;" rel="nofollow">https:&#x2F;&#x2F;research.securitum.com&#x2F;prototype-pollution-rce-kiban...</a>

One I can think of:AFAIK An arbitraty JavaScript cannot access values declared out of its scope. Prototype pollution add a capability of an attacker introduce a hook-like mechanism to intercept values passed via an object&#x27;s method.

I have seen a lot of attacks using it on the server side, like:-innocuous looking code merges user supplied input from a json object (&quot;we just use this to render a view or write it to an object store&quot;)-attacker throws in a __proto__ property which means every object in the _entire_ node runtime has that value for that key until it&#x27;s overwritten in script-random templating engine has a config option that would _never_ be controlled by an attacker, right?-oops, RCE!

In some specific scenarios an attacker can perform prototype manipulation without being able to inject arbitrary code, in this jquery bug you can see one such case due faulty parsing of a json object (json that may come from untrusted sources) <a href="https:&#x2F;&#x2F;snyk.io&#x2F;blog&#x2F;after-three-years-of-silence-a-new-jquery-prototype-pollution-vulnerability-emerges-once-again&#x2F;" rel="nofollow">https:&#x2F;&#x2F;snyk.io&#x2F;blog&#x2F;after-three-years-of-silence-a-new-jque...</a>

Imagine you have a game with attacker controlled (x, y):<pre><code> var { x, y } = JSON.parse(input);
 board[x][y] = true;

 &#x2F;&#x2F; ...

 if (user.admin) ...
</code></pre>
If the attacker puts:<pre><code> {x: &quot;__proto__&quot;, y: &quot;admin&quot;}
</code></pre>
Then board[&quot;__proto__&quot;] might be `object` and then object[&quot;admin&quot;] = trueNow `&lt;any object&gt;.admin` is true !

The most common vulnerability that grants RCE has the attacker exploiting poorly designed deserialization code. Those are high impact but not too common since deserialization is hopefully closely scrutinised.There are other problems that naturally fall out of the fact that by default all objects, including those from JSON.parse, inherit the Object prototype though. For example -- If you store user membership or permission as an object with some user controlled identifier (eg. a username) as key, then check if a user is permitted at all with `username in permissions`, a user can name themselves hasOwnProperty to bypass the check since it is part of the Object prototype- If you deserialize some JSON then try to check membership with `o.hasOwnProperty(someKey)`, a malicious user can pass in JSON with hasOwnProperty as key. This will crash since hasOwnProperty is no longer a function on the object.These are not necessarily common, but it’s annoying how easy it is for these to slip through. The object prototype in general is just a massive footgun

You can also easily cause DOS by overwriting toString to return something unexpected like an int

I remember &quot;prototype pollution&quot; as the annoying result of monkeypatching a la prototype.js way back when. But this article presents prototype pollution as a security issue.If an attacker can perform &quot;prototype pollution&quot;, aren&#x27;t they already injecting arbitrary JavaScript into the page? If they already have script injection, why would they choose &quot;prototype pollution&quot; over anything else they could do with arbitrary code?

&gt; How is this different from monkeypatching in e.g. Python, Ruby?It’s not monkeypatching, its a class of vilnerabilities that allow an attacker to do the monkeypatching, and to do so to the root Object.Key things about JavaScript that differ from Ruby&#x2F;Python relevant to it are:(1) Prototype-based inheritance, 
(2) Syntax and common idioms thar support and encourage use of plain objects where Ruby&#x2F;Python would use string-keyed Hash&#x2F;dict instances (equivalent to JS Map), including when objects are constructed from untrusted JSON (which, again, Ruby&#x2F;Python would serialize to Hash&#x2F;dict, not exposing member properties ot manipulation).What would be reading a Hash&#x2F;dict keyvalue pair from an untrusted source in Ruby or Python (not, generally, risky) can easily be, in JavaScript, opening a gateway to potentiallt inject data members to the shared prototype of all objects.

How is this different from monkeypatching in e.g. Python, Ruby?

Prototype Pollution (2020)