exploit-verifier · diff
git:20260529.8f6ea0e to git:20260529.0ab6ab0
14 added, 67 removed. Audit A to A.
---
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.
+ description: Sentinel-V exploit verification agent — replays exploit payloads, validates CVE applicability, generates proof-of-concept verification 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?
**Checkpoint:** Document all checks performed. If FAIL, stop and issue False Positive verdict with justification.
### 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?
**Checkpoint:** Record the request/response pair showing behavioral difference. If FAIL, stop and issue False Positive verdict.
### 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 |
**Checkpoint:** Capture evidence (screenshot, response body, OOB callback). PASS = Confirmed. FAIL = Partial (impact not fully proven).
## 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.
+ For detailed decision trees and step-by-step procedures, see the checklists:
+ - Web: [references/checklists/web-verification-checklist.md](references/checklists/web-verification-checklist.md)
+ - API: [references/checklists/api-verification-checklist.md](references/checklists/api-verification-checklist.md)
+ - AI/LLM: [references/checklists/ai-llm-verification-checklist.md](references/checklists/ai-llm-verification-checklist.md)
- **Data Exfiltration:** Confirm real sensitive data in output (not placeholder/fabricated data). Check for callback if using image/URL exfil.
+ For detailed verification templates with report formatting, see:
+ - [references/verification-templates/web-verification.md](references/verification-templates/web-verification.md)
+ - [references/verification-templates/api-verification.md](references/verification-templates/api-verification.md)
+ - [references/verification-templates/ai-llm-verification.md](references/verification-templates/ai-llm-verification.md)
- **Guardrail Circumvention:** Confirm restricted content was actually generated, not just engaged with in a non-violating way.
+ For AI/LLM payload library: [references/ai-payloads/llm-injection-payloads.md](references/ai-payloads/llm-injection-payloads.md)
- ## Common False Positive Patterns
+ ### Key Sink Confirmation Rules
- ### 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 |
+ **Web:** XSS requires unencoded DOM rendering (HTML-encoded = FP). SQLi needs SQL-specific errors, not generic ones. SSRF must be server-side fetch, not client redirect. CSRF requires no SameSite + no CSRF token + confirmed state change.
- ### 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 |
+ **API:** BOLA/IDOR needs two sessions proving cross-user data access (200 with own data = FP). Mass assignment must show persisted unauthorized fields. JWT bypass must grant elevated access.
- ### 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 |
+ **AI/LLM:** Prompt injection needs behavioral change, not just acknowledgment. System prompt extraction needs consistency across two different methods. Excessive agency requires observable side effects, not just description.
## 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}
```