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:

{
  "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:

#!/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:

"$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.

"$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'

"$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'

first vuln x command should have the flags -s "critical,high" -n 0 to first check all critical and high. second vuln x command should have -s "critical,high,medium" -n 20 --poc true to second check top 20 higher severity wit poc`s third: (decide yourself to use vunx best then) For text or HTML dumps, use context around hits instead of large extracts:

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:

"<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:

## 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

"$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

"$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

"$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:

"$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.