Vulnetix Exploit Search Skill

Vulnetix Exploit Search Skill

Use when

• You need to know what is being exploited in YOUR ecosystem this week (e.g. --ecosystem npm --since 2026-04-01).
• Building a watchlist of weaponised CVEs for a specific package family or vendor.
• Filtering for CISA-KEV-only items at HIGH/​CRITICAL severity with EPSS > 0.5.
• Looking for exploits from a specific source (e.g. Metasploit-only) for a red-team scenario.
• Producing a weekly threat newsletter scoped to one ecosystem.

Don't use for

• Deep-diving a single CVE — use /​vulnetix:exploits.
• Daily SOC queue intersected with this repo's deps — use /​vulnetix:soc-triage.
• Listing CVEs for a single package — use /​vulnetix:vuln <package>.

Conventions

This skill follows _lib/​contract.md: the Vulnetix CLI is auto-installed by hooks, .vulnetix/​capabilities.yaml is always present, every vulnetix vdb call is piped through a verified jq filter from _lib/​jq/, independent calls run in parallel as concurrent Bash tool calls, and trailing follow-ups are limited to one line. See the contract for output style, memory write rules, and cooldowns.

This skill searches for vulnerabilities with known exploits across the entire VDB, with filtering by ecosystem, severity, exploit source, EPSS score, and CISA KEV status. Use it to discover exploited vulnerabilities relevant to your repository's technology stack. This skill does not modify application code -- it only updates .vulnetix/​memory.yaml to track findings.

How this differs from /​vulnetix:exploits: The existing /​vulnetix:exploits <vuln-id> skill performs deep analysis of a single known vulnerability (PoC fetching, ATT&CK mapping, CWSS scoring). This skill discovers exploited vulnerabilities across the landscape, optionally filtered to your repository's ecosystems.

Vulnerability Memory (.vulnetix/​memory.yaml)

This skill reads and updates the .vulnetix/​memory.yaml file in the repository root. This file is shared with /​vulnetix:fix, /​vulnetix:exploits, /​vulnetix:package-search, /​vulnetix:vuln, and /​vulnetix:remediation.

Schema

The canonical schema is defined in /​vulnetix:fix. This skill creates minimal stub entries for newly discovered vulnerabilities that affect the repository.

Reading Prior State

At the start of every invocation:

1. Use Glob to check if .vulnetix/​memory.yaml exists in the repo root
2. If it exists, use Read to load it -- used in Step 4 to annotate results with prior status
3. Use Glob for .vulnetix/​scans/​*.cdx.json -- cross-reference against search results

Writing Updated State

After completing the search (Step 5):

For each result that matches a dependency in the repository and is not already tracked:

1. Create a stub entry with status: under_investigation, discovery.source: scan, decision.choice: investigating, decision.reason: "Discovered via /​vulnetix:exploits-search"
2. Append to history: event: discovered, detail: "Found via exploit search (<filters used>)"

For existing entries, do not change status or decision.

VEX Status Mapping

• not_affected --> "Not affected"
• affected --> "Vulnerable"
• fixed --> "Fixed"
• under_investigation --> "Investigating"

CLI install + capabilities — see ../​_lib/​contract.md. Skip the install dance; the hooks handle it.

Workflow

Step 1: Load Memory and Detect Repository Ecosystems

1. Load .vulnetix/​memory.yaml if it exists
2. Use Glob to detect manifest files and determine repository ecosystems:
   • package.json, package-lock.json, yarn.lock, pnpm-lock.yaml --> npm
   • go.mod, go.sum --> go
   • Cargo.toml, Cargo.lock --> cargo
   • requirements.txt, pyproject.toml, Pipfile, poetry.lock, uv.lock --> pypi
   • Gemfile, Gemfile.lock --> rubygems
   • pom.xml, build.gradle, gradle.lockfile --> maven
   • composer.json, composer.lock --> packagist

The detected ecosystem is used as a default filter if the user does not specify one.

Step 2: Parse Filters from User Message

Map the user's natural language and any explicit arguments to CLI flags:

CLI Reference (from vulnetix vdb exploits search docs):

Natural language mapping examples:

Auto-ecosystem detection: If the user does not specify an ecosystem and the repository uses a single ecosystem, automatically add --ecosystem <detected>. If the repo uses multiple ecosystems, ask whether to filter or search across all.

If the argument $ARGUMENTS is provided as free text (not a flag), use it as the -q value.

Step 3: Execute Exploit Search

Build and run the CLI command:

vulnetix vdb exploits search [flags] -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/​skills/​_lib/​jq/​exploits.jq"

Examples:

# Search for critical npm exploits
vulnetix vdb exploits search --ecosystem npm --severity CRITICAL -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/​skills/​_lib/​jq/​exploits.jq"

# CISA KEV entries with high EPSS
vulnetix vdb exploits search --in-kev --min-epss 0.5 --sort epss -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/​skills/​_lib/​jq/​exploits.jq"

# Free-text search
vulnetix vdb exploits search -q "remote code execution" --ecosystem npm -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/​skills/​_lib/​jq/​exploits.jq"

# Metasploit modules for Maven
vulnetix vdb exploits search --source metasploit --ecosystem maven -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/​skills/​_lib/​jq/​exploits.jq"

# Sort by exploitation maturity
vulnetix vdb exploits search --ecosystem pypi --sort maturity --limit 20 -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/​skills/​_lib/​jq/​exploits.jq"

Response structure (from V2 OAS ExploitSearchResult schema):

{
  "timestamp": 1711382400000,
  "total": 142,
  "limit": 100,
  "offset": 0,
  "hasMore": true,
  "filters": { "ecosystem": "npm", "severity": "CRITICAL" },
  "results": [
    {
      "cveId": "CVE-2021-44228",
      "state": "PUBLISHED",
      "title": "Apache Log4j2 JNDI injection",
      "description": "...",
      "aliases": ["GHSA-jfh8-c2jp-5v3q"],
      "metrics": {
        "cvssV3Score": 10.0,
        "cvssV3Vector": "AV:N/​AC:L/​PR:N/​UI:N/​S:C/​C:H/​I:H/​A:H",
        "cvssV4Score": null
      },
      "epss": { "score": 0.97, "percentile": 0.999 },
      "cess": { "score": 0.92 },
      "cwes": [{ "id": "CWE-502", "description": "Deserialization" }],
      "affectedProducts": [{ "vendor": "apache", "product": "log4j" }],
      "fixAvailability": { "hasRegistryFix": true, "hasSourceFix": true },
      "kev": {
        "inCisaKev": true,
        "dateAdded": "2021-12-10",
        "dueDate": "2021-12-24",
        "overdue": true,
        "ransomwareUse": true
      },
      "exploitationMaturity": {
        "score": 95,
        "level": "WIDESPREAD",
        "confidence": "HIGH"
      },
      "exploitTriviality": { "level": "TRIVIAL" },
      "exploitSources": {
        "exploitdb": 3,
        "metasploit": 2,
        "nuclei": 5,
        "github": 12,
        "vulncheckXdb": 1,
        "crowdsec": 1
      },
      "sightings": {
        "totalSightings": 50000,
        "uniqueIPs": 12000,
        "isActive": true
      },
      "timeline": {
        "publishedDate": "2021-12-09",
        "firstExploitDate": "2021-12-09",
        "ageDays": 1567
      },
      "ecosystems": ["maven", "npm"]
    }
  ]
}

Step 4: Present Results

Render a results table:

Exploit Search Results
Filters: ecosystem=npm, severity=CRITICAL
Total: N results (showing 1-20)

| # | CVE ID          | Severity | EPSS | Maturity   | Exploit Sources       | KEV | Fix? |
|---|-----------------|----------|------|------------|-----------------------|-----|------|
| 1 | CVE-2021-44228  | critical | 0.97 | WIDESPREAD | ExDB:3 MSF:2 Nuc:5   | Yes | Yes  |
| 2 | CVE-2024-XXXXX  | critical | 0.82 | ACTIVE     | MSF:1 GH:3            | Yes | Yes  |
| 3 | CVE-2023-YYYYY  | critical | 0.65 | WEAPONIZED | ExDB:1 Nuc:2          | No  | No   |

Column definitions:

• CVE ID -- primary identifier
• Severity -- CVSS severity (critical/​high/​medium/​low)
• EPSS -- Exploit Prediction Scoring System probability (0.00-1.00)
• Maturity -- exploitation maturity level: NONE, POC, WEAPONIZED, ACTIVE, WIDESPREAD
• Exploit Sources -- abbreviated counts: ExDB (ExploitDB), MSF (Metasploit), Nuc (Nuclei), GH (GitHub PoCs), VCX (VulnCheck XDB), CS (CrowdSec)
• KEV -- in CISA Known Exploited Vulnerabilities catalog (Yes/​No). If overdue, append "(overdue)"
• Fix? -- whether a registry or source fix is available (Yes/​No)

Below the table, for each result cross-reference with memory:

• If tracked: CVE-2021-44228 -- Fixed (2024-01-15) (developer-friendly status)
• If not tracked: no annotation

CrowdSec activity -- if any result has active sightings, note: "N results have active CrowdSec sightings (live exploitation detected)"

Ransomware flag -- if any KEV result has ransomwareUse: true, note: "N results are associated with known ransomware campaigns"

Pagination: Showing 1-20 of 142. Say "next page" or "page 3" for more.

Actionable recommendations:

• For any result: "Run /​vulnetix:exploits <vuln-id> for deep exploit analysis (PoCs, ATT&CK mapping, CWSS scoring)"
• For results with fixes: "Run /​vulnetix:fix <vuln-id> for fix intelligence" or "Run /​vulnetix:remediation <vuln-id> for a context-aware remediation plan"
• For results without fixes: "Run vulnetix vdb traffic-filters <vuln-id> for Snort rules to block exploit traffic while unpatched"
• For details: "Run /​vulnetix:vuln <vuln-id> for full vulnerability info"

Step 5: Update Vulnerability Memory

1. Use Read to load the current memory file (or start fresh)
2. For each result that matches a dependency in the repository (cross-ref affected products/​ecosystems against repo manifests):
   • If not already tracked, create a stub entry
   • Record the search filters used in the history detail
3. Use Write to save
4. Confirm: "Vulnerability memory updated: N new vulnerabilities tracked from exploit search"

If no results match repo dependencies, skip memory updates and note: "No results match packages in this repository. Consider broadening the search or checking other ecosystems."

Error Handling

• If vulnetix vdb exploits search returns an error, suggest checking vulnetix vdb status for API health
• If no results found, suggest broadening filters (remove severity, lower min-epss, try different ecosystem)
• If the user's natural language is ambiguous, ask for clarification rather than guessing
• If .vulnetix/​memory.yaml cannot be written, warn but do not block results display

Important Reminders

1. This skill does not modify application code -- it is a discovery tool
2. This skill searches across all vulnerabilities -- it is not scoped to a single vuln ID (use /​vulnetix:exploits for that)
3. Auto-detect the repo ecosystem as a default filter to keep results relevant
4. Exploitation maturity levels: NONE (0-14), POC (15-34), WEAPONIZED (35-54), ACTIVE (55-74), WIDESPREAD (75+)
5. EPSS display: decimal in tables (0.97), not percentage
6. Safe Harbour scores: not applicable to search results (they are per-version, not per-CVE)
7. Always update .vulnetix/​memory.yaml for results matching repo dependencies
8. CrowdSec sightings indicate live exploitation -- flag prominently
9. Ransomware associations are high-priority signals -- always surface them

Edge cases & gotchas

• --source enum names are case-sensitive: exploitdb, metasploit, nuclei, vulncheck-xdb, crowdsec, github (not github-poc like the inner .poc.source field).
• --in-kev filters to CISA KEV; for the wider Vulnetix KEV catalog use /​vulnetix:kev-watch instead.
• --min-epss 0.5 is a probability not a percentile — 0.95 percentile != 0.95 probability.
• Default --limit is 50; the --sort default is recent not epss. Pass --sort epss for risk-ordered output.
• --ecosystem filter is applied AFTER fetch (server-side cache key includes the filter); changing it forces a fresh round-trip and is rate-limited.
• Result .exploitationMaturity.level can be ACTIVE, WEAPONIZED, POC, or UNPROVEN — only ACTIVE/​WEAPONIZED warrant urgent action.