Exploitation Validator

exploitation-validator, an Exploitability Validation Skill / System

A prompt-based pipeline for finding, validating, and proving vulnerabilities using LLM sub-agents — structured to resist false positives.

Authors: Gadi Evron ([@gadievron](https://github.com/gadievron)) and Michal Kamensky ([@kamenskymic](https://github.com/kamenskymic))

Note: This system has since been enhanced and turned into a skill by John Cartwright ([@grokjc](https://github.com/grokjc)), where he combined it with his binary exploitation module for [raptor](https://github.com/gadievron/raptor).

**And if you like what I do**, check out my startup [Knostic](https://knostic.ai) where we protect coding agents/MCP/extensions/skills, etc.

What It Does

Takes a codebase, searches for vulnerabilities (e.g., command injection), validates findings aren't hallucinated, known, or by-design, and — where the environment allows executing a harmless PoC — proves real ones. A finding verified only by static dataflow is reported as `confirmed`; `exploitable` requires an observed effect (see the execution model in `shared.md`).

Stages

This pipeline is packaged as a skill — **`SKILL.md`** is the operational entry point and the source of truth for the stage table. The copies below are a human-readable mirror; if they ever diverge, `SKILL.md` wins.

Stage	Purpose	Output
0: Inventory	Build ground truth checklist of all files/functions	checklist.json
A: One-Shot	Quick exploitability check + PoC attempt (a success does not skip B/C)	findings.json
B: Process	Systematic analysis with attack trees, hypotheses, multiple paths	findings.json + working docs
C: Sanity	Validate LLM didn't hallucinate — mechanical fact-check only (files exist, code matches, flow is real)	validated findings.json
C-bis: Semantic	Is it actually a vuln? Rule out algorithm tautologies, spec-required behavior, documented design	findings.js