Vuln Diagnose

Vulnerability Diagnose

A suspected vulnerability is not a finding. Before writing anything, build a deterministic reproduction case. If you cannot reproduce it reliably, you cannot report it.

Inspired by the principle: a fast, deterministic, agent-runnable pass/fail signal is a superpower.

Process

Step 1 — State the Hypothesis

Write one sentence: "I believe [vulnerability type] exists at [endpoint/component] because [observed behaviour]."

This is the claim. Everything that follows either confirms or disproves it.

Step 2 — Build the Feedback Loop

Create the minimal test case that produces a binary YES/NO answer:

• An HTTP request that succeeds when it shouldn't
• A payload that executes when it shouldn't
• A response that contains data it shouldn't

The test must be:

• Reproducible — same result every time
• Minimal — only the essential input, no noise
• Unambiguous — pass is clearly different from fail

If you can't build this test case, the hypothesis is not testable yet. Stop and gather more information.

Step 3 — Test Alternate Explanations

Before confirming, rule out:

• Caching (replay the request — is the result fresh?)
• Rate limiting (does it fail on the 5th attempt?)
• Session dependency (does it work with a fresh session?)
• Race conditions (does it fail on a second run?)

Step 4 — Confirm the Impact

Actually demonstrate the worst-case impact:

• For data access: retrieve data belonging to another user
• For XSS: execute alert(document.domain) or exfiltrate a cookie
• For SQLi: extract a row from a table not intended to be accessible
• For privilege escalation: perform an admin action with a user token

A confirmed impact requires evidence (HTTP request + response, screenshot, extracted data).

Step 5 — Document

Produce a Minimal Reproduction Case:

Vulnerability: [type]
Endpoint: [METHOD] [URL]
Precondition: [e.g., logged in as user A]

Request:
[exact HTTP request]

Response:
[relevant snippet proving the issue]

Confirmed impact: [what was demonstrated]
Reproducible: YES / NO (notes if flaky)

Then pass this to finding-writer to produce the full finding.

Rules

• No exploit, no finding — Shannon's rule. If you cannot demonstrate impact, downgrade to "suspected" and label it clearly
• Never report a finding based on tool output alone without manual confirmation
• If the test is flaky (fails intermittently), investigate root cause before reporting
• One hypothesis per session — do not stack unconfirmed vulnerabilities

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Rifteo
• Source: Rifteo/skills
• License: MIT

Install and usage instructions live in the source repository linked above.