Proof of concept exploit (PoC)

What is a proof of concept exploit?

A PoC is evidence. It proves a vulnerability exists by triggering it once, in the least harmful way that still shows the effect: reading one record the tester should not see, returning a marker string, or causing a measurable delay. It deliberately stops before the damage a real attacker would go on to do.

The term is used in two contexts that behave differently:

• In a penetration test finding, the PoC is the tester's reproduction: the exact requests and responses that show the flaw on the client's system. It is private, written for the engineers who will fix it.
• As public code for a CVE, a PoC is a script or write-up released by a researcher or vendor, usually on GitHub, Exploit-DB or Packet Storm. The real CVE record for Citrix Bleed (CVE-2023-4966) includes a reference to a Packet Storm entry titled as a session token leakage proof of concept.

PoC vs exploit vs weaponized exploit

Moving down the table takes real work. A PoC often only works against one version, one configuration, or with debugging help. That gap is why a public PoC raises risk without meaning exploitation is imminent.

What does a good finding PoC contain?

A good finding lets an engineer who was not on the test reproduce the flaw in minutes and confirm the fix later. The OWASP Web Security Testing Guide lists the elements each finding should carry: a reference ID, a title, likelihood (including whether working exploit code exists), impact, risk, a description of how to exploit it, remediation steps, and references, with sensitive data masked.

Here is the shape of one, with plainly fake data:

ID:          FIND-007
Title:       Project records readable across tenants via ID substitution
Severity:    High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, 6.5)
Affected:    GET /api/v1/projects/{id} on api.example (build 2026.09.1)
Accounts:    user_a (tenant_a, role member), user_b (tenant_b, role member)
Precondition: any authenticated account

Steps to reproduce
  1. Sign in as user_b and note own project ID: project_2210.
  2. Sign in as user_a. Request GET /api/v1/projects/1043 (own project): 200.
  3. As user_a, request GET /api/v1/projects/2210 (user_b's project).
  4. Observe 200 OK with tenant_b's project body (exchange below).

Scope of proof
  One record read, belonging to a test account created for this engagement.
  No enumeration performed, no write requests attempted.

Remediation
  Scope the lookup to the caller's tenant in the data layer; return 404 on mismatch.

Retest
  Repeat step 3. Expected after fix: 404 Not Found, no body.

The evidence block is the raw exchange:

GET /api/v1/projects/2210 HTTP/1.1
Host: api.example
Authorization: Bearer <user_a token>

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 2210, "name": "demo-project", "plan": "free", "tenant": "tenant_b"}

What makes this useful:

1. Two accounts the tester controls. Proving cross-tenant access with test accounts on both sides avoids touching real customer data.
2. A control request. Step 2 shows the normal case, so step 3's response is clearly abnormal.
3. A stated scope of proof. Saying what was not done matters as much as what was: one record, no enumeration, no writes.
4. A CVSS vector, not just a label. The vector shows how the severity was reached and can be recomputed in a CVSS calculator.
5. A retest step with an expected result. The same PoC becomes the acceptance test for the fix, which is what a pentest retest runs.

Why do validated findings matter?

A validated finding is one a tester actually exploited, and the PoC is the proof. Scanner output is a list of possibilities: a version string matched, a response looked unusual. Each one costs engineering time to investigate, and many turn out not to apply to the running configuration. A finding with a working PoC removes that step. The engineer does not have to decide whether the issue is real, only how to fix it.

This is the practical line between vulnerability scanning and penetration testing. It also makes prioritization honest. A reproduced, low-privilege, cross-tenant read on the production API is a different conversation from a "possible IDOR" flagged by a tool.

Public PoC availability as a risk signal

Public exploit code changes a vulnerability's risk, but less than people assume.

• It raises likelihood. The Exploit Prediction Scoring System treats newly public exploit code as one of the signals that can move a CVE's score overnight. CVSS v4.0's Exploit Maturity metric has a dedicated value, POC, for when proof-of-concept code is public but no exploitation attempts are known, sitting between Unreported and Attacked.
• It is not proof of exploitation. CISA's KEV catalog explicitly does not count a public PoC as active exploitation, and does not require one for listing.
• Most vulnerabilities with public PoCs are not known to be exploited. Mandiant's analysis of 2023 time-to-exploit data found that 72 percent of vulnerabilities with public PoCs or exploits were not known to be exploited in the wild, and saw no correlation between exploit availability and when exploitation happened.

Treat a new public PoC as a reason to re-check exposure and move a patch up the queue, and treat KEV listing as the stronger signal.

Running public PoC code safely

Public PoCs are untrusted code, and some are traps aimed at the people who download them. A study of 47,285 GitHub repositories containing CVE PoCs found 899 (about 1.9 percent) with indicators of malicious intent, including code that tried to exfiltrate data, install malware, or open a reverse shell on the machine running it.

1. Read the code before you run it. Look for encoded blobs, bundled binaries and outbound connections to hosts that are not the target.
2. Run it in an isolated, disposable lab with no credentials or production network access.
3. Test only systems you are authorized to test, and prefer the vendor's advisory and patch diff over an unknown repository when you only need to confirm exposure.

Written by Parameter · Last reviewed September 27, 2026