How do I install the Common Exploit Verification skill?

Run npx skillmds@latest add hoangnguyen0403/common-exploit-verification in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Common Exploit Verification safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Common Exploit Verification?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Common Exploit Verification free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Common Exploit Verification?

HoangNguyen0403 (@hoangnguyen0403) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Common Exploit Verification by hoangnguyen0403

Name: Common Exploit Verification
Rating: 4.2 (5 reviews)
Author: HoangNguyen0403

Common Exploit Verification

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.

HoangNguyen0403 Updated Sep 9, 2026 542 repo stars

File contents

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)

---name: common-exploit-verificationdescription: 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.---# 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)

Frequently asked questions