X-PPM
ppmap
Go scanner that detects client-side prototype pollution and turns known gadgets into a working XSS payload.
OVERVIEW
ppmap (github.com/kleiton0x00/ppmap), written in Go, automates the two-step process behind most client-side prototype-pollution findings: it first runs a heuristic scan — via a headless Chromium instance, so it needs Chromium installed — to check whether a URL's parameters can pollute Object.prototype, then fingerprints a set of known gadgets, application code paths that read an attacker-controllable property off the polluted prototype in a dangerous way, to see which ones are actually present.
It only exploits the gadgets it already knows about rather than doing general code analysis to discover custom ones, so a clean scan against ppmap's own gadget list doesn't rule out prototype pollution being exploitable through app-specific logic a human reviewer would still need to trace by reading the client-side JavaScript.
USE CASES
Practical use cases
- 01
Scanning URL parameters of a single-page app for client-side prototype pollution before manual gadget-hunting.
- 02
Fingerprinting known gadgets (jQuery, common frameworks) to get a working XSS payload without writing one by hand.
- 03
Mass-checking a list of in-scope URLs for the vulnerability pattern as an early triage step.
- 04
Demonstrating impact from a prototype-pollution finding that would otherwise stay a theoretical DOM oddity in the report.
QUICK START
When a single-page app is worth checking for client-side prototype pollution, to go from a heuristic finding straight to a working XSS payload.
- Install Chromium (or run the included setup script) since ppmap drives a real headless browser.
- Install ppmap with go install, or by cloning and building the repo.
- Pipe a single in-scope URL, or a file of URLs, into ppmap.
- Review flagged URLs and the gadget/payload it reports for each one.
- Manually confirm the generated XSS payload actually fires in a real browser before reporting it.
cat urls.txt | ppmapBEFORE YOU RUN IT
What to check before running it
It only covers gadgets already known to the tool — a clean result does not rule out prototype pollution exploitable through app-specific code.
It runs a real headless browser against every URL tested, so treat it like active scanning traffic and confirm volume/rate against scope, not as passive reconnaissance.
A generated XSS payload is live exploit code — handle and store it per the engagement's evidence rules rather than leaving it in shell history or scratch files.