Share
## https://sploitus.com/exploit?id=DF777C4D-5F17-54F1-868E-8D8309903F77
# exploitation-validator, an Exploitability Validation System
A simple but effective prompt-based pipeline for finding, validating, and proving vulnerabilities using LLM sub-agents.
Note: This system has since been enhanced and turned into a skill by John Cartwright, where he combined it with his binary exploitation module for [raptor](https://github.com/gadievron/raptor).
Authors: Gadi Evron (@gadievron) and Michal Kamensky (@kamenskymic)
Enhanced version in raptor by John Cartwright (@grokjc)
License: MIT
## What It Does
Takes a codebase, searches for vulnerabilities (e.g., command injection), validates findings aren't hallucinated, and produces proof-of-concept exploits for real vulnerabilities.
## Stages
| Stage | Purpose | Output |
|-------|---------|--------|
| **0: Inventory** | Build ground truth checklist of all files/functions | checklist.json |
| **A: One-Shot** | Quick exploitability check + PoC attempt | findings.json |
| **B: Process** | Systematic analysis with attack trees, hypotheses, multiple paths | findings.json + working docs |
| **C: Sanity** | Validate LLM didn't hallucinate (files exist, code matches, flow is real) | validated findings.json |
| **D: Ruling** | Filter out findings requiring preconditions or hedged language | final findings.json |
## Flow
```
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β STAGE 0: Inventory β
β Build ground truth checklist (files, functions) β
β Exclude test/mock files β
β β
β OUTPUT: checklist.json β
βββββββββββββββββββββββ¬ββββββββββββββββββββββββββββββββββββββββ
β
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β STAGE A: One-Shot β
β 1. Verify exploitability β
β 2. Build harmless PoC β
β β
β OUTPUT: findings.json β
βββββββββββββββββββββββ¬ββββββββββββββββββββββββββββββββββββββββ
β
βββββββββββββΌββββββββββββ
β β β
βΌ βΌ βΌ
PoC succeeds Not disproven Disproven
β β β
β βΌ βΌ
β ββββββββββββββββ Done
β β STAGE B β (for that
β β Process β finding)
β β β
β β - Attack β
β β trees β
β β - Hypothesesβ
β β - Multiple β
β β paths β
β β - PoC β
β β attempts β
β β β
β β OUTPUT: β
β β findings + β
β β working docsβ
β ββββββββ¬ββββββββ
β β
βββββββ¬ββββββ
β
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β STAGE C: Sanity Check β
β Validate LLM output against actual code: β
β 1. File exists β
β 2. Path correct β
β 3. Lines accurate, code verbatim β
β 4. Flow is real (not fabricated) β
β 5. Code is reachable (not dead) β
β β
β OUTPUT: validated findings.json β
βββββββββββββββββββββββ¬ββββββββββββββββββββββββββββββββββββββββ
β
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β STAGE D: Ruling β
β Filter based on LLM reasoning: β
β - Not test/mock/example β
β - No unrealistic preconditions β
β - No hedging language β
β β
β OUTPUT: final findings.json β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
```
## Working Documents (Stage B)
| Doc | Purpose |
|-----|---------|
| attack-tree.json | Knowledge graph. Source of truth. |
| hypotheses.json | Active hypotheses. Status: testing, confirmed, disproven. |
| disproven.json | Failed hypotheses. What was tried, why it failed. |
| attack-paths.json | Paths attempted. PoC results. PROXIMITY. Blockers. |
| attack-surface.json | Sources, sinks, trust boundaries. |
## MUST-GATEs
| Gate | Rule |
|------|------|
| 1 | Assume exploitable until proven otherwise |
| 2 | Strict sequence β methodology first, additional ideas separate |
| 3 | Checklist compliance β track and prove coverage |
| 4 | No hedging β verify all "if", "maybe", "unclear" |
| 5 | Full coverage β check all code against checklist.json |
| 6 | Proof required β show vulnerable code |
**Applies to:** Stage B (all), Stage C (3, 5, 6), Stage D (3, 5, 6)
## Files
| File | Purpose |
|------|---------|
| shared.md | Configuration, execution rules, MUST-GATEs, reminders |
| prompt_stage_0.md | Inventory |
| prompt_stage_a.md | One-shot verification |
| prompt_stage_b.md | Systematic process |
| prompt_stage_c.md | Sanity check |
| prompt_stage_d.md | Ruling |
## Usage
Each stage runs as a sub-agent. Orchestrator:
1. Runs stage with appropriate prompt
2. Validates output files exist
3. Routes to next stage based on outcome
4. Passes file-based state between stages
## Notice to agent
This analysis is performed for defensive purposes, in a lab environment. Full permission has been provided.