---
title: "Proof of Concept"
description: "Learn how Paladin generates proof-of-concept exploits, how the reproduction field lets you confirm a finding, and how re-running the pentest verifies your fixes."
canonical: https://turbopentest.com/learn/running-pentests/proof-of-concept
source: "TurboPentest Learn"
---

# Proof of Concept

## What is a Proof of Concept?

A proof of concept (PoC) is a demonstration that a vulnerability is genuinely exploitable, not just a theoretical possibility. In traditional scanning, most findings are unvalidated - the scanner detected a pattern that might indicate a vulnerability but never confirmed it actually works. This is the root cause of the false-positive problem that plagues security teams.

TurboPentest's agentic approach eliminates this gap. When Paladin's agents discover a potential vulnerability, they do not just flag it. They craft exploit payloads, execute them against the target, observe the response, and document exactly what happened. The finding's `proofOfExploit` field contains the complete evidence: the request sent, the response received, and an explanation of why this confirms the vulnerability.

## How Agents Generate PoCs

Each Paladin specialist agent follows a validate-then-report workflow:

**1. Discovery** - The agent identifies a potential vulnerability through reconnaissance data analysis or its own testing. For example, the Web App Agent might notice that user input in a search parameter is reflected in the HTML response without encoding.

**2. Payload Crafting** - The agent crafts multiple exploit payloads designed to confirm the vulnerability. For XSS, this might include basic script tags, event handler injections, and filter bypass variants. The agent reasons about what sanitization might be in place and designs payloads accordingly.

**3. Exploitation** - The agent sends the payloads to the target and analyzes the responses. It checks whether the payload was reflected verbatim, filtered, encoded, or blocked. If a payload executes successfully, the agent documents the exact request and response.

**4. Impact Assessment** - After confirming exploitability, the agent evaluates the real-world impact. Can the XSS steal session cookies? Is the HttpOnly flag set? Can it be chained with other findings? This assessment directly influences the CVSS score and severity level.

**5. Documentation** - The agent writes a clear proof-of-concept description including the vulnerable endpoint, the working payload, the raw HTTP request and response, and the demonstrated impact.

This workflow means that every finding in your report has been actually exploited, not just theoretically identified. When a developer asks "Is this real?" the answer is documented in the PoC.

## The Reproduction Field

Every finding includes a `reproduction` field containing the steps to reproduce the exploit yourself. This is one of the most practically useful parts of the report because it lets you verify the finding independently, without taking Paladin's word for it.

Reproduction steps are deliberately **read-only and non-destructive**, and scoped to the exact target that was tested. They take one of two forms:

- **A single-command probe** using a standard tool you already have - `curl`, `dig`, `nslookup`, or `openssl s_client`. These issue one safe request against the specific endpoint documented in the finding. They never launch broad scans, mutate data, or test anything beyond the one vulnerability they demonstrate.
- **Precise browser steps** - an ordered list of exactly what to click, type, and observe in a browser when the finding is easier to show interactively than with a shell command.

A typical `reproduction` value looks like:

```bash
curl -s "https://example.com/search?q=<script>alert(1)</script>"
```

You run the reproduction step, compare what you see against the proof of exploit documented in the finding, and confirm for yourself that the vulnerability is real. Because the steps only ever read from the target, they are safe to run against production.

## Verifying a Fix by Re-Running the Pentest

The `reproduction` field proves a finding is real; it is not how you prove a fix landed. To verify remediation, you **re-run the pentest**. A repeat run triggers a live **fresh-oracle retest pass**: Paladin re-tests each previously reported finding against the current state of the target and assigns a per-finding verdict.

The retest returns one of three verdicts for every finding:

- **still_present** - the vulnerability was reproduced again; the fix did not land. Surfaced in the report as **not_confirmed** (the fix is not confirmed).
- **fixed** - the vulnerability could no longer be reproduced; the fix worked. Surfaced as **confirmed**.
- **unsure** - the retest could not reach a definitive verdict (for example, the endpoint behaved ambiguously or was unreachable). Surfaced as **unsure**, prompting a manual look.

Because the retest is a fresh, live re-test rather than a cached comparison, it reflects the target exactly as it stands at the moment you re-run - there are no stale results.

## Reading the Proof-of-Concept

A well-structured PoC in a TurboPentest report contains these elements:

**Vulnerable endpoint** - The exact URL and HTTP method where the vulnerability exists.

**Payload** - The specific input that triggers the vulnerability. For injection findings, this is the crafted query. For authentication issues, this is the bypass technique. For SSRF, this is the forged request target.

**Request** - The full HTTP request including headers, cookies, and body that demonstrates the exploit.

**Response evidence** - The relevant portion of the server's response that confirms exploitation. For XSS, this shows the unencoded payload in the HTML. For SQL injection, this shows the extracted data or error messages revealing database structure.

**Impact statement** - What an attacker could achieve with this vulnerability. A reflected XSS PoC might note: "Attacker can execute arbitrary JavaScript in authenticated user sessions. HttpOnly flag is not set on session cookie, enabling session hijacking."

## Verification Workflow

The recommended workflow for handling a finding:

1. **Reproduce** - Follow the finding's `reproduction` step (a curl/dig/openssl probe or browser steps) to confirm the finding in your own environment against the exact target.
2. **Analyze** - Read the PoC details to understand the root cause. Determine whether the fix belongs in input validation, output encoding, configuration, or architecture.
3. **Fix** - Implement your remediation following the finding's `remediation` guidance.
4. **Verify** - Re-run the pentest. The fresh-oracle retest pass re-tests the finding live and returns a verdict: **confirmed** (fixed), **not_confirmed** (still present), or **unsure**.
5. **Document** - Record the retest verdict. Across repeat pentests, finding continuity tracking carries the status forward so you can see at a glance which findings have been remediated.

This workflow transforms findings from "things to argue about" into "things to fix and verify." The live retest is the objective arbiter of whether a vulnerability still exists.