Exploits SearchSAFE
A single hub to find Claude Skills, Agents, Commands, Hooks, Plugins, and Marketplace collections to extend Claude Code, Claude Desktop, Agent SDK and OpenClaw
Overview
A single hub to find Claude Skills, Agents, Commands, Hooks, Plugins, and Marketplace collections to extend Claude Code, Claude Desktop, Agent SDK and OpenClaw
80a0afd96301OBSERVED · 2026-10-07What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
--- name: exploits-search description: Search for exploits across all vulnerabilities with filtering by ecosystem, severity, source, and EPSS argument-hint: "[search query]" user-invocable: true allowed-tools: Bash, Read, Glob, Grep, Edit, Write model: sonnet --- # Vulnetix Exploit Search Skill 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" ## 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): | Flag | Type | Default | Description | |------|------|---------|-------------| | `--ecosystem` | string | -- | Filter by package ecosystem (npm, pypi, maven, go, cargo, nuget, rubygems, packagist, etc.) | | `--source` | enum | -- | Filter by exploit source: `exploitdb`, `metasploit`, `nuclei`, `vulncheck-xdb`, `crowdsec`, `github`, `poc` | | `--severity` | enum | -- | Filter by CVSS severity: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` | | `--in-kev` | bool | false | Only show exploits listed in CISA KEV catalog | | `--min-epss` | float | -- | Minimum EPSS score threshold (0.0-1.0) | | `-q` | string | -- | Free-text search query (CVE ID, title, description) | | `--sort` | enum | recent | Sort order: `recent`, `epss`, `severity`, `maturity` | | `--limit` | int | 100 | Maximum results per page (1-100) | | `--offset` | int | 0 | Pagination offset | | `-o, --output` | string | pretty | Output format: `json` or `pretty` | **Natural language mapping examples:** | User says | Flags | |-----------|-------| | "npm exploits" | `--ecosystem npm` | | "critical vulnerabilities" | `--severity CRITICAL` | | "metasploit modules" | `--source metasploit` | | "actively exploited" / "in KEV" | `--in-kev` | | "high EPSS" / "likely exploited" | `--min-epss 0.7 --sort epss` | | "critical npm with metasploit" | `--ecosystem npm --severity CRITICAL --source metasploit` | | "remote code execution" | `-q "remote code execution"` | | "sort by severity" | `--sort severity` | | "sort by maturity" | `--sort maturity` | | "first 20" / "top 20" | `--limit 20` | | "next page" / "more" | `--offset <previous + limit>` | **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: ```bash vulnetix vdb exploits search [flags] -o json ``` Examples: ```bash # Search for critical npm exploits vulnetix vdb exploits search --ecosystem npm --severity CRITICAL -o json # CISA KEV entries with high EPSS vulnetix vdb exploits search --in-kev --min-epss 0.5 --sort epss -o json # Free-text search vulnetix vdb exploits search -q "remote code execution" --ecosystem npm -o json # Metasploit modules for Maven vulnetix vdb exploits search --source metasploit --ecosystem maven -o json # Sort by exploitation maturity vulnetix vdb exploits search --ecosystem pypi --sort maturity --limit 20 -o json ``` **Response structure** (from V2 OAS Ex
Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
80a0afd96301full audit observations/trust-audit/skill/davepoon__exploits-search.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-07 | 80a0afd96301 | SAFE | B | 89 | first audit |
Questions
What does the Exploits Search skill do?
A single hub to find Claude Skills, Agents, Commands, Hooks, Plugins, and Marketplace collections to extend Claude Code, Claude Desktop, Agent SDK and OpenClaw
Is Exploits Search safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Exploits Search access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (80a0afd96301), read on 2026-10-07. The repository is watched, and a new audit runs when it changes — this is the first audit.