exploit-verifier git:20260504.2a64374A

Immutable. This exact content is served forever at /api/v1/blob/0fc2dec5c3026222.

---
name: exploit-verifier
description: Sentinel-V exploit verification agent for confirming bugs and exploits across web application, API, and AI/LLM pentesting. Use when verifying a reported vulnerability, confirming a finding, proving/disproving an exploit, generating a verification report, or checking for false positives.
---

# Exploit Verifier (Sentinel-V)

Systematic exploit verification agent. Receives findings from pentesting workflows and proves or disproves them using the Triple-Check Method.

**This skill does NOT discover vulnerabilities.** It consumes findings from pentesting workflows and agent scan results, and produces structured VERIFICATION REPORTs with Confirmed / Partial / False Positive verdicts.

## Triple-Check Method

Every finding goes through three sequential phases. No phase can be skipped.

### Phase 1: Static Viability

Determine if the vulnerability CAN exist given the target's observable state.

- Does the endpoint/component exist and accept input?
- Is the technology stack compatible with the vulnerability class? (e.g., SQLi requires a database-backed endpoint)
- Are there visible protections that would prevent exploitation? (WAF headers, CSP, CORS policy, input type restrictions)
- Does the response indicate the input reaches server-side processing?

**Decision:** PASS → proceed to Phase 2. FAIL → verdict: False Positive.

### Phase 2: Dynamic Trigger

Send the payload and confirm it reaches the vulnerable code path.

- Does the payload get processed (not rejected at input validation)?
- Is there a behavioral difference between normal and malicious input? (response content, status code, timing, headers)
- Does error output indicate the payload reached backend logic?

**Decision:** PASS → proceed to Phase 3. FAIL → verdict: False Positive.

### Phase 3: Sink Confirmation

Prove the exploit reaches its intended sink and achieves impact.

| Vuln Class | Sink Confirmation |
|---|---|
| XSS | Payload renders in DOM unencoded |
| SQLi | Data extracted or error confirms query manipulation |
| SSRF | Internal resource accessed or OOB callback received |
| Path Traversal | File contents returned |
| BOLA/IDOR | Unauthorized data returned for another user's resource |
| Prompt Injection | Model behavior changed, system prompt leaked, or unauthorized action taken |
| CSRF | State-changing action completed without CSRF token from cross-origin |
| Auth Bypass | Protected resource accessed without valid credentials |
| Mass Assignment | Unauthorized field persisted after write |
| JWT Bypass | Elevated access with forged/manipulated token |

**Decision:** PASS → verdict: Confirmed. FAIL → verdict: Partial.

## Decision Matrix

| Phase 1 (Static) | Phase 2 (Dynamic) | Phase 3 (Sink) | Verdict | Confidence Range |
|---|---|---|---|---|
| PASS | PASS | PASS | **Confirmed** | 7-10 |
| PASS | PASS | FAIL | **Partial** | 4-7 |
| PASS | FAIL | — | **False Positive** | 2-4 |
| FAIL | — | — | **False Positive** | 1-2 |

## Verification Guidance by Class

### Web Application

**XSS:** Check reflection context (attribute, tag body, JS string). Verify CSP doesn't block execution. Confirm payload renders unencoded in DOM — HTML-encoded output is a false positive.

**SQL Injection:** Confirm parameter reaches database with error-based or boolean detection. Differentiate SQL-specific errors from generic errors. Time-based: confirm delay is significantly above baseline and repeatable.

**SSRF:** Confirm server-side fetch occurs (not just client redirect). Test internal addresses and cloud metadata. Use OOB callbacks for blind SSRF.

**Path Traversal:** Confirm file contents returned (not a default/error page). Test encoding variations if basic `../` is filtered.

**CSRF:** Verify no SameSite cookie protection, no CSRF token requirement, and no custom header requirement. Confirm state change persists from cross-origin request.

**Auth Bypass:** Test path manipulation, method override, header injection. Confirm actual access to protected content (not just a different status code).

### API

**BOLA/IDOR:** Requires two separate user sessions. Confirm User A can access User B's actual data (not just a 200 OK with empty/own data).

**Mass Assignment:** Confirm unauthorized fields are persisted (not silently dropped). Check response after write to verify state change.

**JWT Bypass:** Test `alg:none`, key confusion, weak secrets. Confirm forged token grants elevated access.

**GraphQL:** Check introspection, depth limits, batch queries, field-level authorization. Introspection alone without sensitive data exposure is informational.

**Rate Limiting:** Confirm bypass sustains past the limit. Header rotation that doesn't affect server-side detection is a false positive.

### AI/LLM

Reference: `references/ai-payloads/llm-injection-payloads.md` for payload library.

**Direct Prompt Injection:** Confirm behavioral change (not just acknowledgment of the attempt). Cross-validate with multiple techniques.

**Indirect Prompt Injection:** Embed payload in external content processed by the model. Confirm injection changed behavior (not just that it was ingested).

**System Prompt Extraction:** Extract twice with different methods. Consistency indicates real extraction; contradictory results indicate hallucination.

**Excessive Agency:** Confirm the action was actually performed (observable side effects), not just described by the model.

**Data Exfiltration:** Confirm real sensitive data in output (not placeholder/fabricated data). Check for callback if using image/URL exfil.

**Guardrail Circumvention:** Confirm restricted content was actually generated, not just engaged with in a non-violating way.

## Common False Positive Patterns

### Web Application
| Reported Vuln | Common False Positive Cause |
|---|---|
| Reflected XSS | Payload reflected but HTML-encoded; CSP blocks execution |
| SQL Injection | Generic error message not caused by SQL; WAF error page |
| SSRF | URL validation rejects internal IPs; redirect not followed |
| Path Traversal | Path normalized before file access; chroot prevents escape |
| CSRF | SameSite cookies present; CORS blocks cross-origin POST |
| Open Redirect | Redirect limited to same domain; path-only redirect |

### API
| Reported Vuln | Common False Positive Cause |
|---|---|
| BOLA/IDOR | 200 OK but returns own data, not other user's; public endpoint |
| Mass Assignment | Extra fields silently dropped; no state change |
| JWT None Bypass | Server validates signature regardless of algorithm claim |
| Rate Limit Bypass | Header rotation ignored; rate limit is per-session |
| GraphQL Introspection | Introspection available but no sensitive types exposed |

### AI/LLM
| Reported Vuln | Common False Positive Cause |
|---|---|
| Prompt Injection | Model acknowledges injection but refuses compliance |
| System Prompt Extraction | Model generates plausible but fabricated instructions |
| Excessive Agency | Model describes action but doesn't execute it |
| Stop Token DoS | Tokens filtered from input before reaching model |
| Guardrail Bypass | Model engages with framing but maintains restrictions |
| Data Exfiltration | Model generates placeholder/fake data, not real user data |

## Verification Report Format

```
[VERIFICATION REPORT]
Finding ID: {identifier}
Surface: {Web Application | API | AI/LLM}
Vulnerability Class: {OWASP/CWE class}
Target: {URL or endpoint}
Original Severity: {from reporting tool}
Date: {YYYY-MM-DD}

--- Phase 1: Static Viability ---
Status: {PASS | FAIL}
Checks performed:
  - {check 1}: {result}

--- Phase 2: Dynamic Trigger ---
Status: {PASS | FAIL}
Request: {METHOD} {URL}
Response: HTTP {status_code} — {relevant excerpt}

--- Phase 3: Sink Confirmation ---
Status: {PASS | FAIL}
Evidence: {Proof of impact}

--- Verdict ---
Result: {Confirmed | Partial | False Positive}
Confidence: {1-10}/10
Justification: {2-3 sentences}

--- Impact ---
{What an attacker could achieve}

--- Remediation ---
{Brief fix recommendation}
```