Prototype Pollution Bug Bounty — Client-Side, Server-Side & RCE Escalation | BB Day 28

This article teaches prototype pollution vulnerability detection and exploitation across client-side and server-side JavaScript contexts, with emphasis on escalating proof-of-concept pollution to high-impact chains like DOM XSS or remote code execution. The article argues that prototype pollution remains consistently high-value in bug bounties because automated scanners reliably find the vulnerability entry point but almost never identify the gadget chains that escalate it to exploitable impact. Understanding both detection methodology and escalation technique is critical for converting prototype pollution findings into substantial payouts.

• Prototype pollution mechanism via unsafe mergePrototype pollution occurs when a recursive merge function iterates over object keys without checking hasOwnProperty, treating __proto__ as a normal property and writing attacker input to Object.prototype. Once polluted, every object in the application inherits the malicious property, making it accessible to any code that reads from that property path. The vulnerable pattern shows merge({}, {"__proto__":{"polluted":"yes"}}) results in ({}).polluted === "yes" being true on all objects.
• Three injection vectors for prototype pollutionAttackers can inject pollution via URL query parameters (?__proto__[polluted]=yes), JSON request bodies ({"__proto__":{"polluted":"yes"}}), or alternative prototype paths like constructor.prototype. Client-side confirmation happens in browser DevTools console by checking if ({}).testprop returns the injected value. Server-side confirmation uses a status code gadget probe sending {"__proto__":{"status":555}} and checking if subsequent error responses return 555 instead of expected error codes.
• Client-side pollution escalates to DOM XSSStandalone client-side prototype pollution rates as Medium severity, but escalates to High or Critical when chained to a gadget—code that reads from polluted prototype properties into DOM sinks like innerHTML, document.write, or eval without sanitization. The chain requires first confirming pollution, then searching application JavaScript files for patterns where undefined properties fall through to Object.prototype, then crafting XSS payloads via pollution URLs like ?__proto__[template]=.
• Server-side Node.js pollution reaches RCEServer-side prototype pollution in Node.js applications becomes Critical-level when escalated via the child_process module's shell or execArgv properties. A vulnerable endpoint merges user-controlled JSON into application state, then code elsewhere spawns child processes reading from Object.prototype—allowing attackers to inject {"__proto__":{"shell":"node","NODE_OPTIONS":"--require /path/to/payload"}} or similar to achieve arbitrary command execution on the server. The status code gadget safely confirms pollution before attempting RCE escalation.
• Discovery requires three complementary techniquesThe article describes a PP hunting methodology combining URL parameter fuzzing (?__proto__[testprop]=pptest and constructor[prototype][testprop]=pptest variants), JSON body injection in API endpoints (POST with prototype pollution payloads), and static analysis of JavaScript source code searching for vulnerable merge, extend, deepClone, or Object.assign patterns lacking hasOwnProperty checks. Automated tools like ppmap assist initial detection; manual gadget hunting is essential for escalation.
• Payout hierarchy reflects escalation impactThe article reports from disclosed HackerOne data that standalone prototype pollution with no demonstrated impact typically earns $200–$500, pollution chained to XSS earns $1,000–$3,000, and pollution escalated to RCE in server-side Node.js applications earns $5,000–$25,000+. This payout structure reveals that gadget chain discovery—not pollution detection itself—is where financial reward concentrates, incentivizing thorough escalation attempts before submission.
• Safe server-side confirmation avoids code executionThe article emphasizes using non-dangerous gadgets for initial server-side confirmation: injecting {"__proto__":{"status":555}} and checking if subsequent 404 or 500 responses return 555 instead, proving Express inherits the polluted status code from Object.prototype without triggering RCE. This technique allows bug bounty researchers to prove the vulnerability exists before escalating, and crucially, to never attempt RCE on live targets without explicit written permission in the scope document.
• Automated scanners miss gadget chains entirelyThe article repeatedly emphasizes that PPScan, ppmap, and other automated tools reliably detect prototype pollution entry points but almost never identify the gadget chains that make findings exploitable and high-severity. The author's experience shows that even widely-used libraries with known PP vulnerabilities (like lodash 4.17.4) go unescalated by automation because finding the gadget requires understanding the specific application's JavaScript architecture and tracing property reads through multiple source files.

Bottom line: Prototype pollution is high-value in bug bounties not because detection is difficult—automated scanners find it consistently—but because escalation to demonstrable impact (DOM XSS or RCE) via gadget chain discovery is manual, application-specific, and rare. A researcher who confirms prototype pollution and then systematically searches the application's JavaScript for DOM sinks or child_process calls that read from polluted properties will reliably convert Medium findings into High or Critical pa