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 P4L4D1N'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 P4L4D1N 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.

Retest Commands

Every finding includes a retestCommand field containing a command that reproduces the exploit. This is one of the most practically useful parts of the report because it serves two purposes: it lets you verify the finding independently, and it lets you confirm your fix works.

Retest commands are designed to be self-contained and runnable from any machine with Docker installed. They use Docker one-liners that package the necessary tools, payloads, and target configuration into a single command. You do not need to install curl, sqlmap, or any other security tools on your workstation.

A typical retest command looks like:

docker run --rm turbopentest/retest:latest \
  curl -s -o /dev/null -w "%{http_code}" \
  "https://example.com/search?q=<script>alert(1)</script>"

The retestExpectedOutput field tells you what a vulnerable response looks like. When you run the retest command before fixing the vulnerability, the output should match the expected output, confirming the finding is reproducible. After you apply your fix, running the same command should produce different output, confirming the vulnerability is resolved.

Docker One-Liners

TurboPentest uses Docker-based retest commands for several important reasons:

Reproducibility — Docker containers provide a consistent execution environment. The retest command produces the same results whether you run it from a developer's MacBook, a CI/CD pipeline, or a Linux server. There are no "it works on my machine" issues.

No local tool installation — Security tools like sqlmap, nikto, and custom exploit scripts are pre-packaged in the retest container. Developers do not need to install security tools on their workstations.

Safety — Retest commands target only the specific endpoint and payload documented in the finding. They do not run broad scans or test anything beyond the single vulnerability they are designed to verify.

CI/CD integration — Docker one-liners can be integrated directly into CI/CD pipelines. After deploying a fix, you can automatically run the retest command as a verification step. If the output still matches the vulnerable pattern, the pipeline can fail, preventing the deployment.

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 findings with retest commands:

1. Reproduce — Run the retest command to confirm you can reproduce the finding in your environment. If the output matches retestExpectedOutput, the finding is confirmed.
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 — Run the retest command again. The output should now differ from the expected vulnerable pattern.
5. Document — Record that the fix was verified. In repeat pentests, finding continuity tracking will automatically confirm the fix.

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