# sast-exploit

> SAST Round 4: Exploit PoC Generation — Generate safe proof-of-concept tests for CRITICAL and HIGH severity findings.

- Author: Georgios Gousios
- Repository: endorlabs/claude-sast
- Version: 20260206102817
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/endorlabs/claude-sast
- Web: https://mule.run/skillshub/@@endorlabs/claude-sast~sast-exploit:20260206102817

---

---
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 `<target_path>/.sast/`.

## Prerequisites

Round 3 output must exist at `<target_path>/.sast/dataflow.md`. Read it first to get the confirmed vulnerabilities.

If `<target_path>/.sast/dataflow.md` does not exist, output an error message to `<target_path>/.sast/exploits.md`:
```
# ERROR: Missing prerequisite
Round 3 (dataflow) output not found at `<target_path>/.sast/dataflow.md`. Run `/sast-dataflow <target_path>` first.
```

## Input

!cat <target_path>/.sast/recon.md
!cat <target_path>/.sast/dataflow.md

## Output

Write your findings to `<target_path>/.sast/exploits.md`. Follow the exact template from the output-templates reference.

## Procedure

### Step 1: Identify PoC Targets

From `<target_path>/.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: `<script>alert('XSS')</script>` or `<img src=x onerror=alert(1)>`
  - Command injection: `; id` or `| whoami` (read-only commands)
  - Path traversal: `../../etc/passwd` (read-only)
  - SSRF: `http://169.254.169.254/latest/meta-data/` (metadata endpoint)
- **Include prerequisites**: Auth tokens, cookies, required headers
- **Note expected response**: What the output looks like when vulnerable vs patched

#### Option B: Framework Test

Generate a test using the project's testing framework (detected from recon):
- Python: pytest, unittest
- JavaScript: jest, mocha, vitest
- Go: testing package
- Java: JUnit
- Ruby: RSpec, minitest

The test should:
- Set up any required fixtures/mocks
- Send the malicious input
- Assert on the vulnerable behavior
- Include a comment explaining what the test proves

### Step 3: Document Remediation

For each PoC, include a minimal code fix:
- Show the vulnerable code (from dataflow trace)
- Show the fixed code
- Explain why the fix works
- Prefer framework-idiomatic solutions (parameterized queries, built-in escaping, etc.)

### Step 4: Theoretical Exploits for MEDIUM

For MEDIUM severity findings:
- Describe the attack scenario in 2-3 sentences
- Explain why a full PoC wasn't generated (e.g., requires specific environment, timing-dependent)
- Provide remediation guidance

### Step 5: Write Report

Compile all PoCs into `<target_path>/.sast/exploits.md` following the canonical template.

## Safety Rules

**CRITICAL**: All PoC payloads MUST be:
1. **Non-destructive**: No DROP TABLE, no rm -rf, no file writes, no data modification
2. **Self-contained**: No external callbacks, no reverse shells, no exfiltration
3. **Detectable**: Use obvious marker payloads (like `alert('XSS')`) that are easy to identify
4. **Documented**: Clear explanation of what the payload does and why it's safe
5. **Authorized-use-only**: Include disclaimer that PoCs are for authorized testing only

**NEVER generate**:
- Reverse shells or bind shells
- Payloads that modify or delete data
- Payloads that exfiltrate real data
- Payloads that establish persistence
- Payloads that escalate privileges beyond demonstration
- Encoded/obfuscated payloads designed to evade detection

## Important Notes

- Read the actual vulnerable code to understand the exact injection point
- Test payloads should work against the actual code, not be generic
- Include both the happy-path (vulnerable) and expected-fixed behavior
- If the project has no test framework, only generate curl commands
- For non-HTTP entry points (CLI, queue, WebSocket), adapt the PoC format accordingly
- Quality matters more than quantity — a well-crafted PoC is more useful than many generic ones

## Reference: Output Template

!cat .claude/skills/sast/references/output-templates.md