Prototype pollution is a JavaScript-specific vulnerability that follows JavaScript wherever it runs, including React Native and other JS-based mobile apps and their Node backends. It exploits the way JavaScript objects inherit from prototypes: if an attacker can get their input merged into an object using special keys like __proto__, they can inject properties into the base object prototype, which then affects every object in the program. The results range from corrupting application logic and denial of service to, with the right conditions, code execution. It usually comes from one careless operation, an unsafe merge of untrusted data. Here is what prototype pollution is, how it happens, and how to prevent it.
Short answer
Prototype pollution is a vulnerability where an attacker injects properties into JavaScript's object prototype, typically Object.prototype, by getting attacker-controlled keys like __proto__, constructor, or prototype merged or assigned into an object, which then affects all objects in the program. Per CWE-1321, the impact ranges from corrupting application behavior and denial of service to, depending on gadgets present, code execution. It affects JavaScript-based mobile apps, such as React Native, and their JavaScript backends, usually through unsafe recursive merges or property assignments of untrusted input. The fix is to avoid merging untrusted data unsafely: reject or strip dangerous keys, use prototype-less objects or Maps for untrusted-keyed data, validate input structure, and keep dependencies updated.
What you should know
- Prototype pollution injects into the object prototype: affecting all objects.
- It uses keys like
__proto__andconstructor: in attacker-controlled input. - The cause is usually an unsafe merge: of untrusted data into an object.
- Impact ranges from logic corruption to code execution: depending on context.
- It affects JS apps and their backends: React Native and Node.
What is prototype pollution?
It is polluting JavaScript's shared prototype through untrusted input. In JavaScript, objects inherit properties from a prototype, and ordinary objects ultimately inherit from Object.prototype, so a property added there is visible on essentially every object. Prototype pollution happens when an attacker can influence the keys used in an operation that writes to an object, and includes a special key, most commonly __proto__, but also paths through constructor and prototype, so that the write lands on the prototype rather than the intended object. Once the prototype is polluted with an attacker-chosen property, every object that does not override it now appears to have that property, which can change how the program behaves anywhere it reads such properties. The vulnerability is not in the prototype mechanism itself but in code that takes untrusted input and merges or assigns it into objects without guarding against these special keys, so a single unsafe operation can taint the global object behavior.
How does it happen, and what is the impact?
Through unsafe property writes, with impact that escalates by context. The table outlines it.
| Step | What happens |
|---|---|
Untrusted input with __proto__ | Attacker-controlled data includes a dangerous key |
| Unsafe merge or assignment | A recursive merge or deep set writes it without guarding |
| Prototype polluted | A property is added to Object.prototype |
| Behavior changes everywhere | All objects appear to have the injected property |
| Escalation | Logic bypass, denial of service, or code execution via gadgets |
The classic trigger is a recursive merge or deep-set function, the kind that copies a source object's nested properties into a target, applied to untrusted JSON without sanitizing keys, so an attacker who controls the JSON includes a __proto__ entry that the merge follows onto the prototype. Once polluted, the impact depends on how the application uses object properties: an injected property can corrupt logic, bypass a check that reads a property, or cause crashes and denial of service when unexpected properties appear everywhere. In some setups, prototype pollution chains with existing code, the gadgets, that uses object properties in sensitive ways, escalating to code execution. So the severity ranges widely, but it always starts from the same place: untrusted input reaching an unsafe object-writing operation.
How do you prevent it?
Guard object writes against dangerous keys, and avoid unsafe merges of untrusted data. The core defense is to never merge or deep-assign untrusted input into objects without protection: reject or strip the dangerous keys __proto__, constructor, and prototype from untrusted data before processing, and use merge, clone, and set utilities that are known to guard against prototype pollution rather than naive recursive ones. For data with untrusted keys, prefer a Map, or objects created without a prototype, so there is no Object.prototype to pollute through them. Validate the structure of incoming data against what you expect, rather than blindly merging arbitrary shapes, which both prevents pollution and is good input hygiene generally. Keep your dependencies updated, since prototype pollution has been found and fixed in many popular libraries, and a vulnerable dependency can introduce the flaw even if your own code is careful. Where appropriate, freezing Object.prototype can harden the runtime against pollution. This applies on both the app side, React Native or other JS, and your Node backend, since both run JavaScript and process untrusted input. The principle is the familiar one: treat untrusted input as untrusted, and in JavaScript that specifically means not letting it write to object prototypes through unsafe merges or dangerous keys.
What to watch out for
The first trap is a naive recursive merge or deep-set of untrusted JSON, the textbook prototype-pollution sink; strip dangerous keys and use safe utilities. The second is a vulnerable dependency introducing the flaw even when your code is careful; keep dependencies updated. The third is using plain objects as maps for untrusted keys, when a Map or prototype-less object avoids the prototype entirely. Prototype pollution is a code-level JavaScript flaw, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS, assesses input handling broadly and can surface dependency and configuration concerns, while the specific guarding of object writes is something you implement and review in your JavaScript.
What to take away
- Prototype pollution injects properties into JavaScript's object prototype through untrusted input using keys like
__proto__, affecting all objects, with impact from logic corruption and denial of service to code execution. - It usually comes from an unsafe recursive merge or deep assignment of untrusted data, and affects JS-based mobile apps like React Native and their Node backends.
- Prevent it by rejecting or stripping dangerous keys, using safe merge utilities and
Mapor prototype-less objects for untrusted keys, validating input structure, and keeping dependencies updated. - Use a pre-submission scan such as PTKD.com to assess input handling and dependency concerns, and guard object writes against prototype pollution in your code.
