Ashrafiucse Cve Research

---
name: cve-research
description: Researches current, publicly known vulnerabilities (CVEs) affecting a project's exact stack and versions — queries OSV.dev and the CISA Known Exploited Vulnerabilities catalog live, and reads the bundled, versioned vuln knowledge base for detection guidance. Use when checking whether a project is affected by newly disclosed CVEs, or when maintaining/updating the security-skills knowledge base.
license: MIT
---

# CVE Research

Two knowledge sources, always use in this order: (1) the **bundled knowledge base** (`vuln-db/entries/`) for curated detection guidance, (2) **live lookups** for freshness.

## Step 1 — Know the exact stack

From manifests/config (or a previous audit's Stack section): framework name + version, language runtime version, key infrastructure (nginx, postgres, redis...) + versions. No versions → find them first (`package.json`, `go.mod`, `Pipfile`, `Dockerfile` base images).

## Step 2 — Bundled knowledge base

Read `vuln-db/README.md` for the entry format, then scan `vuln-db/entries/*.md` frontmatter (`ecosystem`, `affected`) for matches with the stack. Each matching entry has a **Detection** section: what to grep, what config value to check. Run those checks and report matches with the entry's fix guidance.

For severity narratives and prioritization, load `references/notable-incidents.md` — it maps real breaches and mass-exploitation waves (Equifax, Capital One, SolarWinds, Log4Shell, MOVEit, Jenkins/Confluence takeovers, npm token heists) to the exact checks in these skills. When a finding's class has KEV + public exploit modules + a named incident behind it, the fix stops being advisory.

## Step 3 — Live lookups (network required)

### Dependencies → OSV.dev

```bash
python3 ../dependency-vulns/scripts/osv_scan.py <project_root>
```

### CISA KEV (actively exploited — priority zero)

```bash
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | python3 -c "
import json,sys
d=json.load(sys.stdin)
for v in d['vulnerabilities']:
    p=v['vendorProject'].lower()+' '+v['product'].lower()
    print(v['cveID'], '|', v['vendorProject'], v['product'], '|', v.get('dateAdded'), '| due:', v.get('dueDate'))
" | grep -iE "<product1|<product2|<framework>"
```

Replace the grep with the stack's product names (e.g. `struts|log4j|confluence|nginx|tomcat`). Any hit on an in-use product/version → **CRITICAL, fix by KEV dueDate**.

### One-off CVE lookup

```bash
curl -s "https://api.osv.dev/v1/query" -d '{"package":{"ecosystem":"npm","name":"express"},"version":"4.17.0"}'
```

### In-the-wild 0-day tracker (Project Zero)

Each tracked 0-day is a markdown file (`0day-RCAs/<year>/CVE-*.md`) in the `googleprojectzero/0days-in-the-wild` repo. Check a specific CVE via the GitHub API, or browse by year:
```bash
curl -s "https://api.github.com/repos/googleprojectzero/0days-in-the-wild/contents/0day-RCAs/$(date +%Y)" | grep -o '"CVE-[0-9-]*"' | tr -d '"'
```
A hit means the CVE was exploited in the wild as a 0-day — severity ceiling for any affected finding. A weekly digest workflow (`watch-0days.yml`) triages new entries automatically.

### Public exploit availability (Metasploit / exploit-db)

If a local metasploit checkout exists: `rg -l "<CVE>" modules/exploit/`. Otherwise check the module listing at rapid7/metasploit-framework `modules/exploit/**` (advisory text usually states it). A public module turns 'theoretical' into drop-in weaponized — record it in the finding and in the vuln-db entry Summary.

### If web search is available

Search `"<framework> <version>" CVE site:nvd.nist.gov` and the project's GitHub Security Advisories. Prefer NVD/GHSA/OSV over blogs for severity; blogs for exploitation details. High-signal sources in order: vendor PSIRT/advisory pages, Project Zero blog + the 0days-in-the-wild tracker, GitHub Security Lab (code-level writeups), PortSwigger research (new web classes), Snyk/Tenable writeups (ecosystem reach), exploit-db/Metasploit for weaponization status.

## Step 4 — Report & watchlist

- Match **confirmed** (version in affected range): severity, entry/CVE, detection evidence, fix version or mitigation.
- Match **possible** (can't pin version): what to check, exact command to run.
- Produce a **watchlist**: top 5 products in this stack to monitor, so future CVE triage is instant.

## Maintainer mode: adding an entry

When a new relevant vulnerability goes public, create `vuln-db/entries/YYYY-MM-DD-<cve-or-id>.md` using the template at `vuln-db/entry-template.md` — then PR it per `CONTRIBUTING.md`. The weekly automation (`.github/workflows/update-kev.yml`) flags new KEV additions as issues to remind maintainers.