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 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 — platform-specific false positive filters
• Exploit Playbook — PoC templates per vulnerability class (backend, frontend, mobile)