exploit-validation

name	exploit-validation
description	Develop and execute proof-of-concept exploits to validate suspected vulnerabilities. Confirms exploitability, measures real impact, and produces reproducible evidence for confirmed findings.
applyTo	**/*

Exploit Validation

Purpose

Transform suspected vulnerabilities into confirmed findings through proof-of-concept (PoC) development and execution. Validate exploitability, measure actual impact, document exact reproduction steps, and produce definitive evidence. This skill bridges the gap between "this looks vulnerable" and "this is exploitable."

Triggers

• Bug bounty triage routes a suspected finding for validation
• High-confidence suspected vulnerability needs confirmation
• Code review identifies a vulnerability that needs runtime validation
• Chained vulnerabilities need end-to-end exploit demonstration
• Stakeholder requires proof of exploitability before remediation

Required Inputs

Input	Description	Required
governance_context	Active engagement governance record	Yes
finding	Suspected finding with preliminary evidence	Yes
target	Exact endpoint, function, or component to exploit	Yes
vuln_class	Vulnerability type (SQLi, XSS, IDOR, RCE, etc.)	Yes
access_level	Current authentication/authorization context	Yes
constraints	Any exploit restrictions (no data modification, rate limits, etc.)	Recommended

Workflow

1. Scope & Constraint Check — Verify:

   • Target is within authorized scope
   • Exploit type is within rules of engagement
   • Constraints from governance context are documented
   • Rollback plan exists for any state-changing exploit

2. Exploit Planning — Define:

   • Attack vector and payload strategy
   • Expected outcome if successful
   • Success/failure indicators
   • Potential side effects and mitigations
   • Required tools and environment setup

3. Payload Development — Build PoC:

   Injection Exploits (SQLi, XSS, CMDi, SSTI, etc.)

   • Start with detection payloads (tautologies, timing, error-based)
   • Escalate to extraction/execution payloads
   • Test WAF/filter bypass if initial payload blocked
   • Document each payload iteration and result

   Authentication/Authorization Exploits (IDOR, Priv Esc, Auth Bypass)

   • Prepare requests with manipulated tokens, IDs, or roles
   • Test horizontal and vertical escalation paths
   • Document exact request differences between authorized and unauthorized access

   Business Logic Exploits

   • Map the expected workflow
   • Identify the logic violation (step skip, race condition, value manipulation)
   • Build step-by-step reproduction with exact timing if race condition

   Chained Exploits

   • Validate each link in the chain independently
   • Then execute full chain end-to-end
   • Document dependencies and ordering requirements

   File/Upload Exploits

   • Craft malicious file payloads (polyglots, double extensions, null bytes)
   • Test upload → storage → retrieval path
   • Verify if uploaded content is executed or rendered

   SSRF Exploits

   • Test with internal IP targets (127.0.0.1, 169.254.169.254)
   • Check protocol handlers (file://, gopher://, dict://)
   • Verify response reflection or blind SSRF indicators

   Deserialization Exploits

   • Identify serialization format (Java, PHP, Python pickle, etc.)
   • Build gadget chain appropriate to target framework
   • Start with information disclosure, escalate to RCE

4. Exploitation — Execute PoC:

   • Capture full request and response
   • Timestamp all actions
   • Record authentication context
   • Note any errors or unexpected behavior
   • Test idempotency (is it repeatable?)

5. Impact Assessment — Determine actual impact:

   • What data was accessible?
   • What actions were possible?
   • What is the blast radius?
   • Can it be escalated further?
   • Is it persistent or one-time?

6. Evidence Collection — Document:

   • Complete HTTP request/response pairs
   • Code execution output
   • Data accessed (redacted)
   • Screenshots or terminal output
   • Timing information for race conditions
   • Environment details (browser, tool versions)

7. Cleanup — After validation:

   • Remove any test data created
   • Revert any state changes
   • Document cleanup actions taken
   • Verify target is in pre-test state

8. Upgrade Finding — Update finding status:

   • Status: Suspected → Confirmed (or False Positive)
   • Confidence: Upgrade to C1 (Confirmed with PoC)
   • Attach complete evidence package
   • Route to evidence-and-reporting

Allowed Actions

• Develop and execute proof-of-concept exploits within authorized scope
• Craft injection payloads, manipulated requests, and exploit chains
• Bypass security controls (WAF, filters, rate limits) for validation purposes
• Test authentication and authorization boundaries
• Execute code within authorized scope for RCE validation
• Access data through exploited vulnerabilities (for evidence, with redaction)
• Test lateral movement paths within authorized scope
• Develop persistence mechanisms for validation (with cleanup)
• Credential abuse within authorized scope (spraying, stuffing, replay)
• Social engineering validation within authorized scope
• Evasion technique testing for realistic assessment

Forbidden Actions

• Exploit targets outside authorized scope
• Cause permanent data loss or corruption without rollback plan
• Exfiltrate real user data (access to verify, but redact in evidence)
• Leave persistent backdoors or access mechanisms after validation
• Skip cleanup after state-changing exploits
• Present failed exploit attempts as successful
• Execute exploits with potential DoS impact without explicit authorization
• Use exploited access to pivot to out-of-scope systems

Output Format

### [FINDING-ID]: [Title] — CONFIRMED

| Field | Value |
|-------|-------|
| **Severity** | [S1-S5] |
| **Confidence** | C1 — Confirmed with PoC |
| **Status** | Confirmed |
| **Category** | [CWE-XXX] |
| **Affected Target** | [endpoint/component] |
| **Exploit Complexity** | Low / Medium / High |
| **Authentication Required** | None / Low / High |
| **User Interaction** | None / Required |

#### Vulnerability Summary
[Concise description of the confirmed vulnerability]

#### Proof of Concept

**Prerequisites:**
- [Authentication state, tools needed, environment setup]

**Steps:**
1. [Exact step with specific values]
2. [Exact step with specific values]
3. [Exact step with specific values]

**Exploit Payload:**
\```
[Exact payload used]
\```

**Request:**
\```http
[Full HTTP request]
\```

**Response:**
\```http
[Full HTTP response — sensitive data REDACTED]
\```

#### Confirmed Impact
[What was actually achieved, not theoretical. Data accessed, commands executed, privilege gained.]

#### Attack Chain
[If chained: Finding A → Finding B → Impact. Each link with evidence.]

#### Remediation
[Specific fix based on confirmed root cause]
\```[language]
[Fix code/configuration]
\```

#### Cleanup Performed
- [Actions taken to revert state]
- [Test data removed]
- [Access revoked]

#### Validation Notes
[How to verify the fix blocks this exact exploit. Regression test.]

References

• references/severity-matrix.md — Severity classification
• references/web-common-risks.md — Exploit patterns by vulnerability class
• references/report-template.md — Report format for confirmed findings