Cve Research

CVE Research

Use this skill after engagement-scope has established the authorized target, asset inventory, impact tolerance, and desired deliverable. For general vulnerability intelligence, proceed with public sources. For target-specific exploitability, keep testing within the authorized environment.

CVE and advisory data changes frequently. Always verify current source data before answering. Prefer primary sources and name the retrieval date when the answer will drive patching, exposure decisions, customer communication, or reporting.

Research Modes

Choose one primary mode:

• CVE brief: summarize one or more CVEs with affected products, severity, exploitation status, references, mitigations, and fix versions.
• Affected-version analysis: decide whether an inventory item, package, image, appliance, kernel, browser, library, or commit range is affected.
• Exploitability triage: assess reachability, prerequisites, exposure, exploitation-in-the-wild signals, exploit maturity, and compensating controls.
• Patch prioritization: rank vulnerabilities using KEV, EPSS, CVSS, SSVC-style decision points, internet exposure, asset criticality, and business context.
• Advisory comparison: reconcile differences between CVE.org, NVD, vendor, GitHub/GHSA, OSV, distro advisories, and security scanner output.
• Report prep: produce a concise internal advisory, customer notice, bounty background section, or remediation plan.

Source Priority

Use multiple sources because no single database is complete or always current:

1. Vendor or maintainer advisory, release notes, commit, patch, and workaround.
2. CVE.org record, including CNA and CISA Vulnrichment ADP containers.
3. CISA Known Exploited Vulnerabilities (KEV) for confirmed exploitation in the wild.
4. Ecosystem advisories: OSV, GitHub Advisory Database, Go/Rust/PyPA/npm/Maven, Linux distro trackers, container image advisories, and cloud provider bulletins.
5. NVD for normalized CVSS/CWE/CPE enrichment and references.
6. FIRST EPSS for probabilistic near-term exploitation likelihood.
7. Reputable incident reports, exploit intelligence, proof-of-concept repositories, honeypot observations, and threat reports as secondary context.

Treat scanner output, social media, exploit databases, and third-party mirrors as leads until confirmed by primary sources or direct evidence.

Helper Script

Use scripts/cve_lookup.py for quick enrichment. It fetches CVE.org, NVD, CISA KEV, FIRST EPSS, and OSV data and prints a compact Markdown report.

python3 <skill-dir>/scripts/cve_lookup.py CVE-2021-44228
python3 <skill-dir>/scripts/cve_lookup.py CVE-2026-31431 CVE-2025-49113
python3 <skill-dir>/scripts/cve_lookup.py --json CVE-2021-44228

The helper is a starting point, not the final answer. Follow vendor and ecosystem links for exact affected versions, fixed versions, configuration preconditions, and mitigation nuance.

Workflow

1. Restate the question: CVE/advisory IDs, product names, package ecosystem, versions, deployment context, exposure, and output needed.
2. Normalize identifiers. Map aliases across CVE, GHSA, OSV, vendor IDs, distro IDs, commit hashes, package coordinates, and scanner plugin IDs.
3. Gather source data from priority sources. Record publication/update dates, source owners, confidence, and disagreements.
4. Establish affectedness. Compare the user's version, build, branch, package manager, distro backport status, image digest, appliance release train, or commit range against fixed and affected versions.
5. Assess exploitability in context. Check attack vector, privileges, user interaction, configuration, feature flags, reachable code paths, exposed services, sandboxing, authentication, and compensating controls.
6. Prioritize. Combine KEV, EPSS, CVSS, exploit maturity, public exploit or scanning activity, asset exposure, business criticality, prevalence, safety impact, and remediation availability. Do not rank by CVSS alone.
7. Produce the deliverable: brief, affected/not affected decision, patch priority, mitigation plan, source comparison, or report text.

Affected-Version Analysis

Be precise about package identity:

• Name and ecosystem: npm, PyPI, Maven, Go, Cargo, NuGet, distro package, container image, appliance firmware, browser, OS, kernel, or SaaS.
• Version semantics: semver, distro epochs, backported security fixes, vendor hotfix trains, LTS branches, commit ranges, git tags, build metadata, and bundled/transitive dependencies.
• Runtime reachability: the vulnerable component is present, loaded, reachable, enabled, configured, and exposed to the attacker model.

Common false positives:

• Scanner matches a version string but the distro backported the fix.
• A transitive dependency is present but vulnerable code is unused or unreachable.
• The CVE affects a different product line, platform, feature, or build option.
• NVD CPEs are overbroad or lag vendor corrections.
• The fixed version is ecosystem-specific and not the same as the upstream tag.

Source Disagreements

When sources disagree, do not average them. Resolve in this order:

• Prefer vendor/maintainer affected ranges and fixed versions over NVD CPEs.
• Prefer ecosystem-specific advisories for package coordinates and fixed versions.
• Prefer CISA KEV over speculation for "exploited in the wild" status.
• Prefer CVE.org/CNA records for canonical identity, but check ADP containers and vendor advisories for later enrichment.
• Treat CVSS scores as mutable metadata. Record the vector and source, and note when NVD, CNA, vendor, or ecosystem scores differ.
• If a patch silently fixes a vulnerability before an advisory is public, mark affectedness as uncertain and identify the commit or release note evidence.

Exploitability And Priority Signals

Use these signals together:

• CISA KEV: confirmed exploitation in the wild; treat as high urgency for exposed or relevant assets.
• EPSS: probability of exploitation in the next 30 days; useful for sorting large queues, not a replacement for context.
• CVSS v4/v3: technical severity; read the vector, not just the number.
• SSVC-style decision points: exploitation status, technical impact, automatability, mission prevalence, public-wellbeing/safety impact, and available mitigations.
• Exposure: internet-facing, reachable by untrusted users, behind auth, internal only, local-only, air-gapped, or lab-only.
• Exploit maturity: weaponized, public PoC, private report, theoretical, or unclear.
• Asset context: privileged control plane, identity system, edge device, CI/CD, developer tooling, data plane, safety system, or low-impact isolated service.

Exploit Material Handling

Collect only the exploit detail needed for triage, validation planning, or defensive detection. Prefer preconditions, affected code paths, indicators, request shapes, and safe lab reproduction notes over weaponized steps. Do not run public PoCs, high-volume scanners, or payloads against live systems unless the engagement brief explicitly allows that impact.

Evidence Standard

Treat an assessment as reliable only when it can explain:

• Identity: exact CVE/advisory aliases, product/package, vendor, and version.
• Source basis: vendor/CNA/NVD/OSV/KEV/EPSS sources checked and dates observed.
• Affectedness: why the target version is affected, fixed, not applicable, or uncertain.
• Exploitability: attacker prerequisites, reachable surface, configuration, and practical constraints.
• Impact: confidentiality, integrity, availability, privilege, tenant, account, business, safety, or supply-chain boundary affected.
• Remediation: exact fixed version, patch, mitigation, workaround, detection, or compensating control.
• Uncertainty: conflicting data, stale records, missing vendor detail, disputed affected ranges, or unvalidated assumptions.

Use Potential, Likely affected, Not affected, Fixed, or Needs vendor confirmation when certainty is incomplete.

Output Format

For a single CVE or advisory:

CVE: <id and aliases>
Status: <affected/not affected/needs validation>
Summary: <one paragraph>
Affected assets: <product/package/version/build/context>
Fixed versions: <versions, patches, mitigations>
Exploitation: <KEV/EPSS/public PoC/in-the-wild/unknown>
Severity: <CVSS vector and interpretation, not score only>
Exploitability in this environment: <reachable prerequisites and constraints>
Priority: <act/attend/track with rationale>
Evidence: <source links, dates checked, version comparison>
Recommended action: <patch, mitigate, monitor, verify, test>
Open questions: <only blockers that change the decision>

For multiple CVEs, lead with a prioritized table and then include short detail sections for anything high urgency or uncertain.

Handoff

Use code-vulnerability-review when advisory research needs source-level reachability, patch review, or remediation. Use web-app-security-inspection for live web/API validation. Use fuzz-harness-builder when parser or protocol exploitability needs systematic input generation. Use exploit-chain-analysis only for authorized lab-only chaining after individual issues are validated.

Research Basis

This workflow reflects CVE.org records and services, CISA KEV and Vulnrichment, NVD CVE 2.0, OSV/OpenSSF schema and API, GitHub Advisory Database, FIRST EPSS, FIRST CVSS v4.0, and CISA/SEI SSVC prioritization guidance. Treat these as source and prioritization signals; vendor advisories and the user's actual asset context remain authoritative.