What is proof of exploit?
Proof of exploit (sometimes called proof of exploitability) is reproducible evidence that a specific vulnerability was not just detected, but successfully triggered against the live application under controlled, authorized conditions. Instead of a severity score and a guess, you get the concrete artifact: the exact input that was sent, the response that came back, and the observable effect it caused.
The point is to close the gap between theoretical risk and real-world danger. A finding with proof is no longer a backlog ticket someone has to investigate — it is a confirmed problem with the evidence already attached.
Proof of exploit vs a scanner finding
Traditional application security tools detect patterns. A static scanner sees a query built from string concatenation and flags possible SQL injection. That is useful, but it cannot tell you whether the code path is reachable, whether input is sanitized upstream, or whether the database even responds. So you get volume — and a large share of it is noise.
| Scanner finding | Proof of exploit | |
|---|---|---|
| What it tells you | This pattern looks risky | This weakness was triggered |
| Evidence | A rule matched + CVSS score | Request/response chain + observed effect |
| Reachability | Unknown | Confirmed (the exploit ran) |
| False positives | Common | Filtered out — no fire, no finding |
| Developer action | Investigate, then maybe fix | Fix — it is already proven |
This is also the difference between a proof of concept and a proof of exploit. A proof of concept argues a bug could be exploited in principle. A proof of exploit demonstrates it was exploited against the real target. (See proof of exploit vs proof of concept for the full breakdown.)
How a proof of exploit is produced
Crafting a working exploit by hand is slow and expensive — it is exactly the part of a penetration test that eats hours. The shift in 2026 is doing it automatically inside a sandbox: an agent drives the running application like an attacker, decides what to probe next based on what it sees, and only records a finding when the payload produces a measurable effect.
- Map the target — crawl the app, collect forms, parameters and API endpoints.
- Probe with safe payloads — neutered inputs that demonstrate impact without doing damage (a harmless echo, never
rm). - Confirm the effect — JavaScript actually executing, a canary value reflected from the server, a system-file signature returned, a database error proving injection.
- Record the evidence — capture the request, the response and a screenshot of the effect.
Because step 3 is the gate, anything that does not actually fire never becomes a finding. That is the mechanism that collapses the false-positive pile most teams drown in.
Which vulnerabilities can be proven
Not every class proves equally well — reflected effects (XSS, redirects, path traversal) are clean to demonstrate, while blind classes need extra signal. Today Sintropyc proves real effect for:
- Reflected XSS — JavaScript execution confirmed in a real browser session.
- SQL injection — proven against a live database response.
- Command injection — a safe command run in the sandbox with output captured.
- SSRF — server-side request tracked from source to destination.
- Path traversal — out-of-scope file read demonstrated against the running app.
- Leaked live API keys — a found secret validated against the live provider, confirming real exposure.
Prove → fix → prove again
Proof is only half the loop. The finding ships with a root-cause fix, the fix is applied, then the original exploit is replayed to confirm it no longer fires. You keep the before-and-after as evidence the patch actually held — not a hope that it did.
Frequently asked questions
What is proof of exploit?
Reproducible evidence that a detected weakness was actually triggered in the running application — a recorded request/response chain or a captured payload effect — rather than a theoretical finding from pattern matching.
What is the difference between proof of concept and proof of exploit?
A proof of concept shows a vulnerability could be exploited in principle. A proof of exploit shows it was exploited against the live target under controlled conditions, with captured evidence of real impact.
Why does proof of exploit reduce false positives?
A finding only ships if the exploit actually fires against the running app, so issues that look risky in source but are not reachable or exploitable are filtered out before they reach you.