Philo Groves Codex Attack Skills Cve Research

---
name: cve-research
description: Research CVEs, GHSAs, vendor advisories, affected versions, exploitability, exploitation status, severity, prioritization, mitigations, and remediation guidance from current authoritative vulnerability sources. Use when Codex needs to investigate a CVE or advisory ID, determine whether a product or dependency version is affected, compare NVD/CVE.org/vendor/OSV/GitHub advisory data, check CISA KEV or EPSS signals, triage patch urgency, prepare vulnerability intelligence summaries, or support authorized exploitability and remediation analysis.
---

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

```bash
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:

```text
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.