common-exploit-verification

---
name: common-exploit-verification
description: Enforce "No Exploit, No Report" policy with PoC construction standards, false-positive filtering, and evidence collection per vulnerability class across backend, frontend, and mobile. Use when validating security findings, constructing exploit proofs, filtering false positives, or writing pentest findings.
metadata:
  triggers:
    keywords:
    - exploit verification
    - proof of concept
    - PoC
    - false positive
    - validate finding
    - exploit proof
    - pentest finding
    - security evidence
---
# Exploit Verification Standard

## **Priority: P0 (CRITICAL)**

## Always-Apply Rules

- **No Exploit = No Report**: Finding without reproducible PoC is discarded. No exceptions.
- **No Theoretical Findings**: "This could be exploited if..." → rejected. Demonstrate actual impact.
- **No Tool Output as Evidence**: Scanner output alone insufficient. Manual verification required.

## PoC Construction

Every confirmed finding must include all fields:

```
ID: [unique identifier]
Vulnerability: [CWE-XXX: type name]
Platform: [backend|frontend|mobile-ios|mobile-android]
Component: [file:line or endpoint]
Severity: [Critical|High|Medium|Low] (CVSS: X.X)
OWASP: [mapping — e.g., A03:2021, API1:2023, M4:2024]

-- Proof of Concept --
Preconditions: [required state, auth level, config]
Steps:
1. [exact step with command/payload]
2. [expected vs actual result]
Payload: [exact input — copy-paste ready]
Evidence: [response body, status code, data returned]

-- Impact --
Impact: [what attacker gains — data, access, control]
Blast Radius: [lateral movement, escalation paths]

-- Remediation --
Fix: [specific code change, not generic advice]
```

## Validation Gate

| Result | Action | Criteria |
|---|---|---|
| ✅ Confirmed | Include in report | PoC reproduces, impact demonstrated |
| ⚠️ Conditional | Include with conditions | Requires specific config/timing/race |
| ❌ Unconfirmed | **Discard** | Cannot reproduce despite 3 attempts |
| 🔄 Degraded | Downgrade severity | Partial impact, mitigating controls exist |

## False Positive Filters

See [false-positive-checklist](references/false-positive-checklist.md) for platform-specific filters.

Quick checks before reporting:
- **SAST-only finding**: Is the flagged code actually reachable from user input? Trace full data flow.
- **Scanner noise**: Does the "vulnerability" have compensating controls (WAF, middleware, framework defaults)?
- **Version mismatch**: Is the CVE for a function the project actually uses (reachability analysis)?
- **Client-side only**: Is the "bypass" only client-side while server enforces correctly?

## Anti-Patterns

- **No severity inflation**: Missing header ≠ Critical. CVSS score must match demonstrated impact.
- **No duplicate findings**: Same root cause across endpoints = 1 finding with multiple affected components.
- **No remediation without specificity**: "Use parameterized queries" → include the exact code change for the affected file.

## References

- [False Positive Checklist](references/false-positive-checklist.md) — platform-specific false positive filters
- [Exploit Playbook](references/exploit-playbook.md) — PoC templates per vulnerability class (backend, frontend, mobile)