Cve Search

CVE Search

Repeatable workflow for collecting CVEs of a given type, finding the best public PoC reference for each one, verifying the URLs, and writing traceable Markdown output.

When to use

Use this skill when the task is to:

• enumerate CVEs for a class such as local privilege escalation, RCE, SSRF, or auth bypass
• find public PoC references with GitHub preferred when available
• refresh an existing CVE note with working links and evidence
• produce a Markdown artifact another analyst or agent can review later

Do not use this skill to claim exploitability without evidence. If no public PoC exists, say so explicitly and keep the best authoritative advisory instead.

Inputs

• vuln_type — required vulnerability class or search theme
• time_range — optional year, date range, or freshness limit
• dest_file — optional workspace path for the Markdown output; create one if missing
• preferred_source — optional source preference; default is github

Output format

Write entries in Markdown using this template:

- **CVE-YYYY-NNNN:** short title
  - **Type:** {vuln_type}
  - **PoC:** {poc_url or "not found"}
  - **Verification:** {verified | redirected | advisory-only | not-checked}
  - **Platforms:** {affected product / version / OS build if known}
  - **Source:** {primary evidence source}
  - **Notes:** {why this PoC or fallback was chosen}

Workflow

Follow these steps in order. Skip a step only when it is clearly not applicable.

1. Bound the search

Before searching, make sure the request is concrete enough to execute:

• normalize vuln_type into 2–5 search phrases
• note any product, platform, vendor, or date constraints
• if dest_file is not provided, derive a clear filename from the request

2. Enumerate candidate CVEs

Collect candidate CVEs from authoritative sources in priority order:

• CISA KEV (cisa.gov/known-exploited-vulnerabilities-catalog) — confirmed active exploitation; check first
• NVD (nvd.nist.gov) and CVE.org — cross-check both; NVD has an unresolved enrichment backlog since Feb 2024 and all pre-2018 CVEs are marked Deferred (April 2025), so fall back to CVE.org when NVD metadata is absent
• GHSA / OSV (github.com/advisories, osv.dev) for library and package ecosystem CVEs
• vendor advisories such as MSRC when the request is vendor-specific

Filter candidates by the requested vulnerability class and time range. Prefer exact matches over broad keyword matches. When filtering by severity, prefer CVSS v4.0 when present in NVD, else v3.1.

3. Find PoC candidates

For each CVE, search sources in this priority order:

1. Sploitus (sploitus.com) — aggregates ExploitDB, Packet Storm, and GitHub PoCs in one query
2. PoC-in-GitHub (poc-in-github.motikan2010.net) — tracks GitHub PoC repositories by CVE ID
3. GitHub repositories, releases, gists, or raw files
4. researcher write-ups or reputable exploit write-ups
5. vendor advisories or NVD references when no public PoC is available

Source ranking rules:

• prefer a GitHub repository root, release page, gist, or stable raw file URL
• avoid fragile URLs such as line-anchored snippets, tree/ views, or search-result pages
• never label a vendor advisory as a PoC

4. Select the best link

Choose the best link using this order:

1. working GitHub PoC with clear CVE mapping
2. working public exploit write-up with code or reproducible steps
3. authoritative advisory when no public PoC is found

If multiple credible PoCs exist, keep the best one in PoC and mention alternates in Notes.

5. Write the entry

For each CVE, write one Markdown entry to dest_file.

Quality rules:

• include the exact CVE ID in the heading line
• include at least one source for every entry
• use PoC: not found when no public exploit reference is available
• keep Notes short and evidence-based
• include platform or version data only when the source supports it

6. Verify collected URLs

When shell access is available, verify URLs by extracting them from dest_file, following redirects, and recording the final HTTP result.

Use the command style that matches the environment.

POSIX shell:

grep -Eo "https?://[^ )\]\"]+" "${dest_file}" | sed 's/[),.]$//' | sort -u | \
  while IFS= read -r url; do
    curl -sS -L -o /dev/null -w '%{http_code} %U\n' "$url" || echo "000 $url";
  done > check_${dest_file##*/}_urls_results.txt

PowerShell:

$destFile = $dest_file
$outFile = "check_$([System.IO.Path]::GetFileName($destFile))_urls_results.txt"
Get-Content $destFile |
  Select-String -AllMatches 'https?://[^ )\]\"]+' |
  ForEach-Object { $_.Matches.Value } |
  ForEach-Object { $_.TrimEnd(')', ',', '.') } |
  Sort-Object -Unique |
  ForEach-Object {
    try {
      $response = Invoke-WebRequest -Uri $_ -MaximumRedirection 10 -Method Head
      "{0} {1}" -f [int]$response.StatusCode, $_
    } catch {
      $status = if ($_.Exception.Response) { [int]$_.Exception.Response.StatusCode } else { 0 }
      "{0} {1}" -f $status, $_
    }
  } | Set-Content $outFile

Interpretation:

• 200 usually means the link is directly usable
• 3xx after redirects is acceptable if the final destination is the intended resource
• 404 or 000 means find an alternate PoC or fall back to an advisory and explain why

7. Final review

Before finishing, confirm that:

• each entry matches the requested vulnerability class
• each PoC field is either a working public reference or not found
• each fallback advisory is clearly marked as advisory-only in Verification or Notes
• the verification results file exists when URL checks were run

Precision rules

• Do not infer exploitability from keyword similarity alone.
• Do not invent affected versions, Windows builds, or exploitation status.
• Distinguish clearly between public PoC found, reference only, and not found.
• Prefer fewer high-confidence entries over a long noisy list.

Resources

No references, scripts, or assets — skill is self-contained.