/hunt

name: hunt
description: "Full CVE hunting pipeline. Usage: /hunt <package-name>. Orchestrates all agents: registry check, clone, code review, PoC build, validation, and report generation."

/hunt <package-name>

Run the full CVE hunting pipeline on a target package.

Pipeline Steps

Execute these steps in order. Stop if any step fails.

Step 1: Registry Check

Check if this package has already been investigated: 1. Read REGISTRY.md and search for the package name 2. Query NVD/OSV for existing CVEs:

   curl -s "https://api.osv.dev/v1/query" -d '{"package":{"name":"$ARGUMENTS","ecosystem":"npm"}}'

3. If found in registry as SUBMITTED/SKIP/DUPLICATE -> report status and STOP 4. If found as FALSE_POSITIVE -> show reason and ask Director if they want to re-investigate 5. If CLEAN -> proceed

Step 2: Target Reconnaissance

Gather target information: 1. Get repo metadata:

   gh search repos "$ARGUMENTS" --json fullName,stargazerCount,updatedAt,description --limit 5

2. Check npm download counts:

   curl -s "https://api.npmjs.org/downloads/point/last-week/$ARGUMENTS"

3. Check for SECURITY.md, bug bounty info 4. List existing security advisories:

   gh api "repos/<owner>/<repo>/security-advisories" 2>/dev/null

5. Create `targets/<package>/brief.md` with findings

Step 3: Clone and Setup

# Clone the repo
git clone --depth 1 <repo-url> targets/<package>/repo

# Check the version
cat targets/<package>/repo/package.json | python3 -c "import sys,json; print(json.load(sys.stdin)['version'])"

Step 4: Hunter Code Review

Perform systematic code review as the Hunter agent:

1. Map attack surface based on package type 2. Search for vulnerability patterns (Tier 1 first, then Tier 2, then Tier 3) 3. For each potential finding, trace the full data flow: source -> transforms -> sink 4. Document findings in `targets/<package>/findings.md`

If no findings after thorough review:

• Record in REGISTRY.md as SKIP with vectors checked
• Report to Director: "No vulnerabilities found in <package>. Checked: <vectors>."
• STOP

Step 5: PoC Development

For each finding:

1. Present the PoC plan to the Director:

   Finding: <description>
   Root cause: <file:line>
   Plan: <approach>
   Chaining: <opportunities>
   CVSS: <estimated score>
   Approve?

2. Wait for Director approval 3. Write PoC script at `targets/<package>/poc_<vuln_type>.py` 4. Test that the PoC runs and produces expected output

Step 6: Validation

Run the full 6-gate verification process:

1. Gate 1 (Process): Verify all evidence is present 2. Gate 2 (Reachability): Confirm attacker can reach the vuln 3. Gate 3 (Real Impact): Confirm genuine security consequence 4. Gate 4 (PoC Validation): Run PoC 3 times, all must succeed 5. Gate 5 (Math Bounds): For DoS, verify exponential growth 6. Gate 6 (Environment): Check for runtime/framework protections

Apply the 13-item false positive checklist. Run the Devil's Advocate 7-question self-check.

Write verdict to `targets/<package>/verdict.md`.

Step 7: Report

If CONFIRMED: 1. Determine the best disclosure channel:

• HackerOne (if program exists)
• GitHub Security Advisory (preferred for open source)
• Direct email (if SECURITY.md provides one)

2. Generate the disclosure report using `/report` 3. Present to Director for final submit/drop decision

If FALSE_POSITIVE: 1. Record in REGISTRY.md with reason 2. Report lesson learned to Director

Step 8: Registry Update

Update REGISTRY.md with the final outcome:

• SUBMITTED: package, severity, channel, date
• FALSE_POSITIVE: package, what was checked, why false, date
• SKIP: package, vectors checked, date

Quick Reference

/hunt lodash-merge    # Hunt in a specific package
/hunt csv-parse       # Hunt in csv-parse
/hunt pug             # Hunt in pug template engine