Skip to content
Back to skills

Exploit Validation

ASecurity

Finding-validation discipline: promote scanner/hunch output from "candidate" to "confirmed", or demote it to false positive. Hypothesis matrix, minimal repro, negative control, rate guardrails, evidence closure, post-fix retest. Trigger keywords: validate finding, false positive, PoC, reproduction, exploit validation, confirmed, retest, verification gate, false positive, reproduction.

  • 4 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 6, 2026
ai-agentspythongorailsapisecurity

Works with

  • api

Security analysis

A100/100

Scanned September 6, 2026

npx -y skills add xAmirHamza77/ReverseOps-Skill --skill exploit-validation --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Exploit Validation?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Exploit Validation
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/xamirhamza77-exploit-validation/badge)](https://www.skillsdirectory.com/skills/xamirhamza77-exploit-validation)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: exploit-validation
description: |
  Finding-validation discipline: promote scanner/hunch output from "candidate" to "confirmed",
  or demote it to false positive. Hypothesis matrix, minimal repro, negative control, rate guardrails,
  evidence closure, post-fix retest.
  Trigger keywords: validate finding, false positive, PoC, reproduction, exploit validation, confirmed, retest, verification gate, false positive, reproduction.
---

## ACTION REQUIRED (execute immediately after reading)

1. `NOW`: scope.md `auth.status=granted` + the target is in the in-scope asset list; if not, stop and go back
   to `osint-recon/` or case-init
2. `NOW`: classify the destructive level of this validation (read-only / write test data / may impact service);
   anything beyond the level authorized in scope must be escalated
3. `NEXT`: build the hypothesis matrix; one row per candidate
4. `ACT`: minimal repro + negative control → verdict written to Evidence; confirmed findings get a JSON finding
   (`../reporting/finding-schema.json`), then run `scripts/mkreport.py`
5. `ACT`: after a fix ships, retest; status moves `confirmed → fixed / accepted`

# exploit-validation — from "candidate" to "confirmed"

## Validation state machine

```text
candidate ─→ confirmed        (repro + control + impact statement)
    │     ─→ false-positive   (control experiment disproves it)
    └─────→ unverifiable      (environment/permission limits — record the gap,
                               keep it out of the report main table)
```

A scanner hit is not a vulnerability. The entire value of this skill is turning the dial
from "looks like" to "can prove".

## Hypothesis matrix (write before touching the target)

| # | Candidate | Source | Falsifiable hypothesis | Minimal repro idea | Expected control |
|---|-----------|--------|------------------------|--------------------|------------------|
| 1 | /api/login rate-limit bypass | scan + 429 observation | XFF is used as the throttle key | same request, N times with/without XFF | no XFF = 429; forged XFF = 200 |
| 2 | ... | | | | |

Every hypothesis must be **falsifiable** — if you can't write a control experiment, go back to
information gathering.

## Minimal-repro discipline

- **Minimal**: if one request or one command demonstrates it, never use a chain; strip every header/parameter
  unrelated to the bug from the PoC
- **Control**: every PoC ships with a "must not succeed" request (no XFF / no metachars / no foreign ID).
  Both sides together make evidence
- **Idempotence-aware**: prefer GET/HEAD probes; for write operations use a test account + self-cleanup
  (create then delete), and log it in the timeline
- **Rate guardrails**: default ≤ 30 req/min on production; brute-force/enumeration thresholds get their own
  line in scope.md

## Evidence closure

Every confirmed finding must carry all of:

1. ≥ 2 `evidence[]` entries (request + response, or action + observation)
2. Paste-able PoC text
3. **One impact sentence**: what the attacker gains and what it unlocks next (feeds risk ranking
   and report language)
4. An actionable remediation (not "raise security awareness")

Then: `work/<case>/findings/<ID>.json` → `python3 scripts/mkreport.py` → panel/report update automatically.

## Common false-positive patterns (suspect these first)

| Pattern | Why it's often wrong | Decisive control |
|---------|----------------------|------------------|
| Reflected XSS scanner hit | WAF page / reflects but never executes | DOM observation in a real browser + `confirm()`-class payload |
| "Directory listing" | static hosting default on a marketing site | does it actually list anything sensitive |
| CVE banner from version string | the distro backported the patch | a PoC probing that CVE's observable effect |
| Open redirect | only whitelisted domains allowed | try `//evil.example` plus encoding variants once each |

## Retest

After a fix: rerun the original PoC unchanged **plus** at least one bypass variant
(encoding, method, header mutation). Record the status change in the finding JSON's `status`;
the panel's by-status chart tracks remediation progress automatically.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.