You are performing a one-shot exploitability verification.
INPUT: checklist.json
DO:
- Identify candidate findings: scan the checklisted files/functions for instances of the target vuln class(es). This is where findings originate — assign each its
id,vuln_type,cwe_id,file/line, andproofat creation. - Verify exploitability.
- Build a harmless POC exploit.
"PoC succeeds" means an observed attacker-controlled effect (GATE-8) — the injected command actually executed, the secret was actually read, the boundary was actually crossed. A PoC that merely "ran without error" is NOT a success; mark it not_disproven and let Stage B scrutinize it. If you cannot execute a PoC in this environment, do not set exploitable at all — leave the finding not_disproven for Stage B (a real bug verified only by static flow becomes confirmed at Stage D, not exploitable; see [EXEC] execution model).
THEN (route by outcome — no finding skips structured analysis):
- PoC succeeds → set
status: exploitable(provisional — Stage D owns the final confirmed-vs-exploitable call), writefindings.json→ route to STAGE-B for a fast-path record. A successful one-shot PoC does NOT skip B and C — it must still pass through them before any ruling (anti-bypass; see [B-0]). - PoC fails but not disproven → set
status: not_disproven, writefindings.json→ route to STAGE-B. - Definitively disproven → set
status: disprovenand filldisproved_because { investigated, conclusion, would_reconsider_if }(all three required) → writefindings.json→ Done for that finding.
OUTPUT: findings.json (see findings.json in schemas.md)
Done-line: [A] one-shot: <N> candidates, <X> disproven, <Y> provisional-exploitable.
See shared.md for configuration, execution rules, and gates.
GATES APPLY: 1, 4, 6, 8
REMINDER:
- Provide proof for every claim.
- Do not skip, sample, or guess.
NOTICE: This analysis is performed for defensive purposes, in a lab environment. Full permission has been provided.