--- name: sast-exploit description: "SAST Round 4: Exploit PoC Generation — Generate safe proof-of-concept tests for CRITICAL and HIGH severity findings." context: fork agent: general-purpose model: opus user-invocable: true --- # SAST Round 4: Exploit PoC Generation You are performing Round 4 of a 5-round SAST analysis. Your job is to generate safe, non-destructive proof-of-concept tests for confirmed CRITICAL and HIGH severity vulnerabilities, and document theoretical exploits for MEDIUM findings. ## Target Path The target codebase path is passed as an argument (e.g., `\/sast-exploit \/path\/to\/repo`). If no argument is provided, ask the user for the target path. All file searches and reads should be scoped to the target path. All output goes to `\/.sast\/`. ## Prerequisites Round 3 output must exist at `\/.sast\/dataflow.md`. Read it first to get the confirmed vulnerabilities. If `\/.sast\/dataflow.md` does not exist, output an error message to `\/.sast\/exploits.md`: ``` # ERROR: Missing prerequisite Round 3 (dataflow) output not found at `\/.sast\/dataflow.md`. Run `\/sast-dataflow ` first. ``` ## Input !cat \/.sast\/recon.md !cat \/.sast\/dataflow.md ## Output Write your findings to `\/.sast\/exploits.md`. Follow the exact template from the output-templates reference. ## Procedure ### Step 1: Identify PoC Targets From `\/.sast\/dataflow.md`, select all findings with: - Verdict: `VULNERABLE` or `LIKELY VULNERABLE` - Severity: `CRITICAL` or `HIGH` For MEDIUM severity findings, only generate theoretical exploits (no runnable PoC). If there are no CRITICAL\/HIGH findings, write a report noting that no PoC generation was needed and include any theoretical exploits for MEDIUM findings. ### Step 1.5: Verify Exploit Path (if code-nav available) Before generating PoCs, use code-nav to verify the exact path from entry point to vulnerability: 1. Use `getCallees` to walk the call chain from the handler to the sink, confirming it matches the dataflow trace from Round 3 2. At each function in the chain, use the Read tool to capture the exact parameter names, types, and any validation logic 3. This ensures the PoC payload is crafted for the actual code, not a generic pattern This step is especially valuable when: - The handler goes through middleware that transforms the request - The vulnerable parameter is renamed or restructured between functions - There are multiple overloads and you need to target the right one If code-nav is not available, proceed directly to Step 2 and rely on the dataflow traces from Round 3. ### Step 2: Generate PoCs For each CRITICAL\/HIGH target, generate TWO forms of proof-of-concept: #### Option A: curl \/ HTTP Command Generate a curl command that demonstrates the vulnerability. Requirements: - **Safe payloads only**: Use payloads that demonstrate the bug without causing damage: - SQLi: `' OR 1=1--` (read-only), `SLEEP(0)` (timing), select from information_schema - XSS: `