# Pentest Cve Vulnerability Research Helper

> CVE and vulnerability research skill for exact CVE lookup, product/version applicability, exploit maturity, KEV/PoC status, source ranking, contradiction handling, and non-destructive validation guidance.

- Skill: `crtvrffnrt/pentest-cve-vulnerability-research-helper` (Agent Skill)
- Install (CLI): `npx skillmds@latest add crtvrffnrt/pentest-cve-vulnerability-research-helper`
- Raw SKILL.md: https://api.skillmd.com/api/skills/crtvrffnrt/pentest-cve-vulnerability-research-helper/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: crtvrffnrt (https://skillmd.com/u/crtvrffnrt)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/crtvrffnrt/pentest-cve-vulnerability-research-helper

---


# CVE Exploit Search Helper v2

## Purpose
Use this skill to find, validate, deduplicate, rank, and explain vulnerability intelligence for a product, version, component, exploit artifact, or CVE ID. It is tool-aware for `vulnx`, but still works with web search alone when `vulnx` is unavailable.

## When To Use
- A CVE is known and you need affected products, exploit maturity, technical details, and verification steps.
- A product, package, CPE, vendor, or version is known and you need relevant CVEs.
- A feature, endpoint, DLL, module, protocol, port, or vulnerability class is known and you need likely CVEs tied to it.
- You need to decide whether a vulnerability is theoretical, public-PoC, KEV-listed, or scanner-actionable.
- You need a concise evidence trail for risk-based vulnerability assessment.

## Operating Contract
- Separate `confirmed`, `likely`, and `rejected` results.
- Distinguish pre-auth from post-auth when relevant.
- Prefer exact identifiers first, then product/version, then product family, then vulnerability class.
- Keep commands minimal and reproducible; use placeholders for listener IPs, credentials, and target values.
- Do not run exploit traffic against a live target unless scope and authorization are explicit.

## Inputs To Normalize
Reduce the user request into a normalized input bundle before searching.

Required fields when available:
- `cve_ids`
- `product_names`
- `vendor_names`
- `versions`
- `components`
- `vulnerability_classes`
- `exploit_artifacts`
- `environment`

Normalization rules:
- Preserve the original user string and derived aliases.
- Generate separator variants and CPE-style guesses only as search aids.
- If the input is broad, mark it as `low_specificity` and stay broad.
- If product and class are both present, search the combined form first.
- If an exploit artifact is present, use it as a correlation key in web sources and structured CVE records.

Example normalized bundle:

```json
{
  "cve_ids": ["CVE-2023-53959"],
  "product_names": ["FileZilla Client", "filezilla_client", "filezilla"],
  "vendor_names": ["filezilla-project"],
  "versions": ["3.63.1"],
  "components": ["TextShaping.dll"],
  "vulnerability_classes": ["remote_code_execution", "dll_hijacking", "CWE-427"],
  "exploit_artifacts": ["EDB-ID:51267", "https://www.exploit-db.com/exploits/51267"],
  "environment": ["Windows client application"]
}
```

## Hard Preflight
Only use `vulnx` when the ProjectDiscovery API key is present and authentication succeeds.
Keep `PDCP_API_KEY` exported in the same shell session that runs `vulnx`, or prefix one-off calls with `PDCP_API_KEY="${PDCP_API_KEY:?}"` so the child process sees it.

Use this gate:

```bash
#!/usr/bin/env bash
set -euo pipefail

VULNX_BIN="${VULNX_BIN:-$HOME/.pdtm/go/bin/vulnx}"
if ! test -x "$VULNX_BIN"; then
  VULNX_BIN="$(command -v vulnx)"
fi

: "${PDCP_API_KEY:?PDCP_API_KEY must be set before using vulnx}"
"$VULNX_BIN" auth --test
```

If `vulnx auth --test` fails:
- Do not run unauthenticated `vulnx` commands.
- Continue with web-only research unless the user explicitly required `vulnx`.
- Mark `tool_status.vulnx` as `unavailable` and include the exact failure category: missing binary, missing key, invalid key, network/DNS blocked, timeout, or command syntax error.

Always discover current syntax before relying on examples:

```bash
"$VULNX_BIN" version
"$VULNX_BIN" search --help
"$VULNX_BIN" id --help
"$VULNX_BIN" analyze --help
```

Validated command semantics:
- `vulnx search` requires a non-empty query argument. An empty query can return no JSON at all.
- Prefer `--json --silent` for parsing.
- The actual search flags include `--kev`, `--poc`, `--remote-exploit`, `--template`, `--severity`, `--vendor`, `--product`, `--fields`, `--limit`, `--sort-asc`, and `--sort-desc`.
- Do not use unverified flags such as `--kev-only` unless `search --help` confirms them in the current installation.
- Product flags may not match canonical product slugs reliably. If `--product <slug>` returns nothing, immediately try a fielded query such as `affected_products.product:<slug>`.
- Do not place raw URLs with `://` directly into `vulnx search` unless already tested. Some URL queries produce parser errors. Prefer `vulnx id` and parse `pocs[]` and `citations[]`, or use external web search for URL/exploit-ID reverse lookup.

## Suggested Workflow

### 1. Normalize And Anchor Input
Classify the input as one or more of `exact_cve`, `product_version`, `product_only`, `component_or_feature`, `vulnerability_class`, `exploit_artifact`, or `mixed`.
Use the most precise anchor available: exact CVE, exact product/version, component plus product, exploit artifact, canonical product slug, vendor plus family, then vulnerability class.

### 2. Use `vulnx` First, Keep Output Small
Prefer `--limit 5` to `10`, and project only the fields you need with `jq` or `--fields`. Use `jq` for JSON and `grep -C` for plain text or dumped HTML. Start with one anchor query, inspect the result, and only expand if the first pass leaves a real gap.

```bash
"$VULNX_BIN" id --json --silent CVE-YYYY-NNNN | jq -r '
  [
    .cve_id,
    .severity,
    (.cvss_score|tostring),
    (.is_kev // false | tostring),
    (.is_poc // false | tostring),
    ([.cwe[]?] | join(";")),
    ([.affected_products[]?.cpe] | join(";")),
    ([.pocs[]?.url] | unique | join(";"))
  ] | @tsv'
```

```bash
"$VULNX_BIN" search --json --silent --limit 8 --fields cve_id,name,severity,cvss_score,is_kev,is_poc \
  "affected_products.product:<product_slug>" | jq -r '
  .results[]? |
  [
    .cve_id,
    .severity,
    (.cvss_score|tostring),
    (.is_kev // false | tostring),
    (.is_poc // false | tostring),
    ([.affected_products[]?.product] | unique | join(";"))
  ] | @tsv'
```

For text or HTML dumps, use context around hits instead of large extracts:

```bash
curl -s "<url>" | grep -i -C 3 "CVE-YYYY-NNNN\|<product>\|Exploit-DB\|Sploitus\|GitHub"
```

### 3. Expand With Google, Exploit-DB, Sploitus, and GitHub
Use Google/web search to fill gaps that `vulnx` misses, then corroborate with the source site. Typical queries:

```text
"<product>" CVE exploit OR PoC OR advisory
"<product>" "<version>" vulnerability
site:exploit-db.com "<CVE-ID>" OR "<product>"
site:sploitus.com/exploit "<CVE-ID>" OR "<product>"
site:github.com "<CVE-ID>" OR "<product>" exploit
```

Prefer vendor or project advisories first, then CVE records, then structured databases, then exploit material, then mirrors.

### 4. Correlate, Deduplicate, And Report
Keep the applicability split small:
- `confirmed`: exact CVE or advisory matches the product and affected version.
- `likely`: strong product/component/class match, but version or environment is missing.
- `rejected`: wrong product, fixed version, wrong platform, or disputed CVE.

Rank confirmed and likely results by exact version match, KEV or active exploitation, public PoC, remote or unauthenticated path, and freshness.

Use this report shape:

```markdown
## Tool Status
- vulnx: available/unavailable, version, auth status
- web search: sources queried

## Confirmed Findings
| CVE | Product/Version | Severity | CVSS | CWE | CPE | KEV | PoC | Applicability |

## Likely Candidates
| CVE | Reason | Missing Proof | Next Minimal Test |

## Evidence Index
| ID | Source | Query/Command | Timestamp UTC | Fact |

## Reproduction / Verification
1. version check
2. non-destructive validation
3. exploit or scanner validation only when authorized
```

## JSON Field Checklist
When parsing `vulnx` JSON, extract at minimum:
- `cve_id`
- `name`
- `severity`
- `cvss_score`
- `cvss_metrics`
- `cwe`
- `affected_products[].vendor`
- `affected_products[].product`
- `affected_products[].cpe`
- `is_kev`
- `is_poc`
- `pocs[].url`
- `citations[].url`
- `requirements`
- `remediation`
- `vuln_status`
- `cve_created_at`
- `cve_updated_at`

## Tooling Usage Patterns

### Exact CVE Summary

```bash
"$VULNX_BIN" id --json --silent CVE-YYYY-NNNN | jq -r '
  [
    .cve_id,
    .severity,
    (.cvss_score|tostring),
    (.is_kev // false | tostring),
    (.is_poc // false | tostring),
    ([.cwe[]?] | join(";")),
    ([.affected_products[]?.cpe] | join(";")),
    ([.pocs[]?.url] | unique | join(";"))
  ] | @tsv'
```

### Product Candidate Table

```bash
"$VULNX_BIN" search --json --silent --limit 10 --fields cve_id,name,severity,cvss_score,is_kev,is_poc \
  "affected_products.product:<product_slug>" | jq -r '
  .results[]? |
  [
    .cve_id,
    .severity,
    (.cvss_score|tostring),
    (.is_kev // false | tostring),
    (.is_poc // false | tostring),
    ([.affected_products[]?.product] | unique | join(";"))
  ] | @tsv'
```

### Facet View

```bash
"$VULNX_BIN" analyze --json --silent \
  --query "affected_products.product:<product_slug>" \
  --fields severity,is_kev,is_poc,is_remote,is_template
```

If `is_template:true`, record the template ID and validate only in scope.

## Common Failure Modes
- Empty stdout from `vulnx search` usually means bad syntax or too-broad input; retry with `affected_products.product:<slug>` and a lower `--limit`.
- Raw URLs may parse poorly; search the URL with web search or parse `pocs[]` from `vulnx id`.
- Generic class queries like `Remote Code Execution` are broad and should stay broad.
- Avoid shell loops or fan-out over many `vulnx` queries in one pass; they usually expand context without adding much signal.
- Conflicting CVSS or remote claims should be reported, not flattened.

## Validation Fixture
These regression checks keep the output focused on exact anchors, product-only matches, and weak component-only matches.

Expected behavior:
- `CVE-2023-53959` should resolve directly.
- `FileZilla Client 3.63.1` should return CVE-2023-53959.
- `TextShaping.dll` should be treated as a weaker component-only match.
- `Remote Code Execution` alone should stay broad.
- `51267` may need web correlation through the CVE record.

Commands:

```bash
"$VULNX_BIN" id --json --silent CVE-2023-53959
"$VULNX_BIN" search --json --silent --limit 5 "FileZilla Client 3.63.1"
"$VULNX_BIN" search --json --silent --limit 5 "TextShaping.dll"
"$VULNX_BIN" search --json --silent --limit 5 "affected_products.product:filezilla_client"
"$VULNX_BIN" search --json --silent --limit 5 "Remote Code Execution"
"$VULNX_BIN" search --json --silent --limit 5 "51267"
```

## Practical Notes
- Start with exact anchors and relax one constraint at a time.
- Use `--fields`, `--limit`, `jq`, and `grep -C` to keep output small.
- Prefer one `vulnx` query at a time, then filter the candidate set before running the next query.
- Treat Google/web search, GitHub, Exploit-DB, Sploitus, vendor advisories, NVD/CVE records, and `vulnx` as complementary sources.
- Preserve contradictions; they matter for client-side, local-vs-remote, and distro-specific differences.

## Handoff Criteria
- Hand off to `pentest-exploit-execution-payload-control` only after applicability and a safe validation path are established.
- Hand off to vector-specific skills when the blocker is parser behavior, authz, XSS, OOB validation, or business logic rather than vulnerability intelligence.

## Memory Candidates
- Useful generic search anchors, source-ranking patterns, and validation checklists can be memory candidates if the runtime supports memory.
- Do not store customer products, private versions, exploit payloads, or target-specific findings.