version: "1.0.0" name: exploit-verification description: Methodology for safely confirming a suspected vulnerability with a minimal, non-destructive proof and capturing reproducible evidence, then concluding Confirmed / Unconfirmed. Use before reporting a finding or when retesting whether one is still present.

Exploit verification & evidence

Use this skill to turn a suspected weakness into a confirmed one — or to rule it out — with the smallest safe proof and evidence someone else can reproduce. A finding is only worth reporting when the evidence shows the condition that makes it exploitable. This skill is about proving safely; use vulnerability-analysis for the CVE intel and severity, and web-app-testing / network-service-testing for category-specific tests.

When to use

• You have a candidate finding and must decide if it is real before reporting it.
• You are retesting an existing finding to see whether it is still present or fixed.
• A scanner flagged something and you need to separate a true positive from noise.

Goal and todo first (Agent mode)

formulate_plan(steps), then transition_step(id, "in_progress"). Goal, e.g. "Confirm whether the reflected-XSS candidate on search.example.com is exploitable, with reproducible evidence". First step: read the candidate and its original evidence (investigate_vulnerability / inspect_issue).

How to verify

1. State the hypothesis precisely. Name the exact condition that would make this exploitable (e.g. "the q parameter reflects input unescaped into HTML"), and the observation that would prove it true and the one that would prove it false.
2. Choose the least intrusive proof that settles it. Prefer a single crafted request, a benign marker, a boolean/timing difference, or an out-of-band callback over anything that changes state. Reproduce with the same tool or connector that produced the original evidence when retesting, so the comparison is like-for-like.
3. Run it once and read the real output. execute_remote_command (curl -sS -i) or run_tool_connector; use read_tool_output with a pattern on long results. Judge from what the output actually shows, not from what you expected.
4. Compare against the hypothesis. The proving condition is either present, absent, or unclear. A changed response is not a fix unless it removes that condition; a tool error is not a confirmation.
5. Conclude. Exactly one of Confirmed, Unconfirmed (likely false positive, with why), or Inconclusive (could not test cleanly — name what blocked it, e.g. a missing or not-ready tool).

Safe-proof rules

• Minimal impact. The proof must demonstrate the flaw without causing damage, reaching real user data, or degrading the service. No destructive payloads, no denial of service, no persistence, no lateral movement.
• No real exploitation. Show that injection alters the query — do not exfiltrate the database. Show one unauthorized object is reachable — do not harvest records. Show a secret is exposed — do not reuse it beyond confirming exposure.
• Reproducible. Capture the exact request (method, URL, relevant headers/body), the response lines that prove the condition, and any tool runId/command used, so the asset owner can reproduce it and later confirm the fix.
• Honest. If the evidence is weak or the result is ambiguous, say Unconfirmed or Inconclusive. Never upgrade a guess to Confirmed, and never invent evidence, CVSS or CVEs.

Safety

• Respect approvals; a rejected step is not retried.
• When a proof would require crossing into damage to be conclusive, stop at the safe boundary and report what remains unproven as a next step.

Output

A short verdict block: the hypothesis, the verdict (Confirmed / Unconfirmed / Inconclusive), the reproducible evidence (request + proving response lines, secrets masked), and — if Confirmed — one line on realistic impact to hand to the report.