What is a proof of concept exploit

01. by attack surface

What a PoC looks like across different surfaces.

The format varies by surface. The requirement is the same: the PoC must be reproducible by the engineering team verifying the fix.

Web application

An HTTP request (method, URL, headers, body, payload) and the response demonstrating exploitation. For IDOR: the request to /api/users/12345 from account 67890 and the response showing account 12345's data. For SQLi: the injected payload and the database rows returned. Captured in Burp Suite or equivalent.

API

A curl command or Postman collection showing the exact call sequence. For BOLA/IDOR: the API call that returns another user's records using a valid but unprivileged token. For mass assignment: the request including protected fields and the response confirming they were applied.

Cloud infrastructure

The sequence of AWS CLI or API calls demonstrating the IAM privilege escalation path. Example: starting with a read-only role, assuming a cross-account role, accessing an S3 bucket containing production data. Each step documented with the exact command and response.

Mobile application

Frida script output, Burp-intercepted traffic, or instrumentation data. For certificate pinning bypass: the Frida script and the resulting plaintext traffic visible in the proxy. For insecure local storage: the extracted database file and the plaintext credentials or tokens it contains.

PoC vs scanner output — the practical difference

A scanner finds a potential SQL injection by detecting a timing difference in the response. It flags the parameter. A PoC actually extracts a row from the database using that parameter. One is "this might be vulnerable." The other is "here is the data we pulled out."

The triage consequence is significant. A finding without a PoC requires your engineering team to reproduce and confirm the issue before they can assess its actual risk — is this exploitable in our configuration? What does the attacker actually get? With a working PoC, they run it once to confirm, then move to the patch. Without one, they may spend days determining whether the finding is real before the remediation sprint starts. In environments with long change management cycles, that delay compounds.

False positive rates are also a real operational problem. Enterprise-grade vulnerability scanners produce significant false positive rates on web applications — 20 to 40 percent is common across engagements where we have validated scanner output manually. Every false positive is engineering time spent chasing a finding that does not exist. A pentest report with working PoCs has a false positive rate near zero, because every finding in the report was manually confirmed before it was written. If the tester could not reproduce it with a working PoC, it did not make it into the report.

Risk assessment accuracy is a third dimension where PoCs matter. A CVSS score without a PoC is a theoretical score applied to a theoretical vulnerability. CVSS v4.0 separates exploitability metrics (does a working exploit exist? is it publicly available?) from impact metrics (what does exploitation yield?). A finding with a working PoC informs both axes with actual data from your environment: the exploit exists, it works in your specific configuration, and here is what it produces. Without the PoC, the exploitability assessment is the tester's judgment about a pattern they observed, not a demonstrated outcome. The scores will look similar on paper; the accuracy is different.

There is also a communication benefit that shows up later in the process. When an engineering manager asks why a critical-severity finding is actually critical, the PoC is the answer. Not "the scanner assigned it a CVSS 9.8" — "here is the request, and here is what we got back." That conversation is faster and produces less friction in prioritization.

Using the PoC during remediation

A working PoC is not just evidence of the finding — it is the test case for the fix. When your developer applies a patch, the right first check is to run the PoC against the patched version and see whether it still succeeds. If it does, the fix is incomplete or applied to the wrong layer. If the PoC fails as expected — the payload returns a 403, the injected value is escaped, the over-privileged role no longer exists — that is a positive signal the patch is in the right direction.

Running the PoC yourself is a useful sanity check before the formal retest. Developers who verify their own patches against the PoC before submitting for retest find incomplete fixes faster and reduce the number of round trips in the retest cycle. The PoC is specific enough to test precisely: it is not "try to access someone else's data," it is "send this exact request with these exact parameters and check whether this exact response comes back."

During the formal retest, the pentest.systems engineer runs the original PoC plus variations — different accounts, different parameter values, the same technique applied to adjacent endpoints — to confirm the fix is not just patching the specific instance but addressing the underlying issue. A fix that blocks the original PoC but leaves similar endpoints unpatched is a partial fix. The retest is designed to catch that distinction. See what every engagement includes for how the retest is structured as a standard deliverable, not an add-on.

03. common questions

Frequently asked questions.

What does a working PoC look like in a penetration test report?

For a web application finding: an HTTP request (method, headers, body, payload) and the response showing the exploit worked — data returned that should not be, an error that reveals internal state, or a state change that should require higher privileges. For a network finding: a packet capture or tool output showing the exploitation sequence. For a cloud finding: the sequence of API calls that demonstrate the IAM privilege escalation. For mobile: a Frida script or instrumentation output. The format varies by surface; the requirement is reproducibility.

Why does a working PoC matter more than a scanner report?

Automated scanners identify potential vulnerabilities based on patterns — response times, error messages, version numbers. They generate false positives regularly. A working PoC proves the vulnerability is real in your specific system and configuration, not theoretical. This matters for triage: your engineering team should not spend a week patching a finding that does not exist. It also matters for risk assessment: a vulnerability that is difficult to exploit in your configuration carries different risk than one with a one-line exploit.

What happens to PoC code after the engagement?

PoC code and working exploits from the engagement are included in the report delivered to you. Pentest.systems does not retain copies of client-specific exploits after delivery. Engagement artifacts — including PoC code, screenshots, and tool output — are deleted from our systems 30 days after report delivery. You retain the only copy. This is documented in the engagement agreement before testing begins.

→ related

Want PoCs for every finding, not scanner output?

Every pentest.systems finding is manually confirmed with a working proof of concept. 30-minute scoping call. Free.

Book a 30-min scoping call See deliverables

What is a proof of concept exploit?

What a PoC looks like across different surfaces.

Web application

API

Cloud infrastructure

Mobile application

PoC vs scanner output — the practical difference

Using the PoC during remediation

Frequently asked questions.

More on deliverables and findings.

Engagement deliverables

Penetration testing

What is a penetration test report?

What is an attestation letter?

Want PoCs for every finding, not scanner output?