/vuln-research

name: vuln-research
description: "Research a specific CVE or vulnerability disclosure end-to-end — what version is affected, is your code reachable, is there a public PoC, is there a patch, what's the exposure window, what's the mitigation if you can't patch immediately. Use when the user mentions 'CVE,' 'vulnerability research,' 'is this CVE relevant,' 'zero-day,' 'CISA KEV,' 'GitHub Security Advisory,' 'reachability analysis,' 'patch analysis,' 'exploit availability,' 'EPSS,' 'CVSS,' or 'should we drop everything and patch this.'"
allowed-tools: Read, Grep, Glob, Bash, WebSearch, WebFetch

Vuln Research — CVE Deep-Dive and Applicability Assessment

When a CVE drops, the question isn't "do we have this package?" — `dependency-audit` answers that. The questions are:

• Is the vulnerable code path actually invoked in our usage?
• Is there a public proof-of-concept making this easy to exploit?
• Is there a patch? When? What's our exposure window if we can't deploy in 24 hours?
• If we can't patch, what's the mitigation?
• Is CISA tracking it as actively exploited?

This skill walks that workflow end-to-end. Pairs with `dependency-audit` (which surfaces the CVE in the first place) and `finding-triage` (which closes the disposition loop).

Workflow

Step 1 — Pull the canonical sources

Start with the authoritative descriptions; everything downstream is summarized or sometimes wrong.

• **NVD record** — `https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN`
• **Vendor advisory** — search the vendor's security page; this is usually the most accurate description of which versions are affected and what the fix is
• **GitHub Security Advisory** — `https://github.com/advisories/GHSA-...` (often more concise than NVD, sometimes has detail NVD lacks; check the parent project's security tab)
• **CISA Known Exploited Vulnerabilities catalog** — `https://www.cisa.gov/known-exploited-vulnerabilities-catalog`. If the CVE is here, treat as actively exploited — patch within CISA's stated due date
• **EPSS score** — `https://www.first.org/epss/` — Exploit Prediction Scoring System; a 30-day probability of exploitation. Useful tiebreaker between high-CVSS-low-EPSS vs medium-CVSS-high-EPSS

Step 2 — Confirm affected versions

Vendor advisories sometimes hedge ("affects versions before X"); pin down the exact range.

• Check the vendor's release notes and the commit history of the fix
• For OSS projects: find the patch commit (usually mentioned in the advisory) and run `git tag --contains <commit>` to see which releases include the fix
• For closed-source: the advisory is the only source — verify version comparisons carefully (semver isn't always observed)
• For monorepos / re-publishers: confirm the same fix landed in any forks or distributions you depend on

Step 3 — Map to your environment

# Is the package installed at all?
npm ls <package>           # or yarn why <package>, pnpm why <package>
pip show <package>          # or pip list | grep <package>
bundle info <gem>
go list -m all | grep <package>

# What version exactly?
# Inspect lockfiles directly — the resolved version is what runs, not the range
grep -A1 '"<package>"' package-lock.json

# Where is it used?
# Direct dependency, transitive, dev-only?
npm ls <package> --omit=dev  # production-reachable?

If transitive, walk up the dependency tree until you find which direct dependency is pulling it in. That's where the override / pin / replacement lives.

Step 4 — Reachability analysis (the high-leverage step)

A CVE is only exploitable if you actually call the vulnerable code path. This is where dependency-audit's noise gets cut down to real risk.

**Read the patch.** The fix commit shows exactly which function / file / API was vulnerable. Then:

# Does your code call the vulnerable function directly?
grep -rn "vulnerableFunction\|VulnerableClass" . \
  --include="*.{js,ts,py,rb,go,java}" \
  --exclude-dir=node_modules

# Does the dependency call it internally even if you don't?
# Trickier — you have to read the parent's source. For an indirect call:
cd node_modules/<package>
grep -rn "vulnerableFunction" .

**Common reachability outcomes:**

• **Reachable, direct:** You call the bad code. Highest priority — patch or workaround now
• **Reachable, indirect:** Your dependency calls the bad code as part of normal use. Still high priority
• **Not reachable:** The bad code is in a feature you don't use (different module, different entry point, different runtime). Lower priority; still recommend patching but won't break SLA
• **Unknown:** Document as unknown and patch on the cautious side

Don't write "not reachable" without showing the work. Future-you will want to revisit when usage changes.

Step 5 — Check for public PoCs and active exploitation

• **GitHub:** search for `CVE-YYYY-NNNNN` in code and repos — PoCs land here within days of disclosure
• **CISA KEV:** if listed, it's actively exploited in the wild
• **Exploit-DB:** `https://www.exploit-db.com/` — confirmed exploits
• **Vendor's security mailing list:** sometimes the most recent intel
• **GreyNoise:** `https://www.greynoise.io/` — internet-wide scanning telemetry; if attackers are mass-scanning for this, your exposure window is now
• **Twitter / Mastodon security circles** — for breaking intel, but verify against canonical sources before acting

**EPSS interpretation:**

| EPSS score | Meaning | |---|---| | > 0.7 | High probability of exploitation in next 30 days — treat as urgent | | 0.1 – 0.7 | Meaningful exploitation likelihood — patch on regular cadence | | < 0.1 | Low predicted exploitation — patch when convenient |

EPSS is empirically tuned; it correlates better with actual exploitation than CVSS does.

Step 6 — Patch / mitigate / accept-risk

**Patch (preferred):**

• If a patched version exists and you can deploy quickly — upgrade the package, run tests, deploy
• For transitive deps without a direct patch, use `overrides` (npm) /