I had to look up what prototype pollution is. This post has a good explanation [1].
The attacker construct an object on your server which contains an own-property '__proto__'. This is straightforward to do if you decode user-supplied JSON (e.g. a REST API) but this alone is not a vulnerability.
The vulnerability occurs when you iterate over this object's own-properties and use the resulting keys on another object. If the attacker can arrange for `obj2[key].value =...`, where 'key' is taken from the first object, then they have modified Object.prototype, which affects all other objects.
If an attacker is in a position to exploit prototype pollution then you’re already screwed. They can already execute any code they want. Seems like this research is just an overly complicated way of saying water is wet.
This vulnerability does not require the attacker to have execute permissions. It relies on the server decoding user-supplied JSON (which should be safe), and then having a code path which assigns "through" those keys. Any sort of object-merge library is a candidate for being vulnerable.
Even if you could initialize the prototype of an object from JSON deserialisation (which I’m not sure you can), JSON very explicitly lacks the ability to set accessor properties. So any injected property is still a normal property for which regular read and write rules apply
The attacker construct an object on your server which contains an own-property '__proto__'. This is straightforward to do if you decode user-supplied JSON (e.g. a REST API) but this alone is not a vulnerability.
The vulnerability occurs when you iterate over this object's own-properties and use the resulting keys on another object. If the attacker can arrange for `obj2[key].value =...`, where 'key' is taken from the first object, then they have modified Object.prototype, which affects all other objects.
1: https://research.securitum.com/prototype-pollution-and-bypas...