cve-research

name	cve-research
description	Aggressive use of CVE intelligence, public advisories, KEV, and EPSS data to find high-value vulnerabilities and variants in authorized bug bounty targets. Use to identify weak patterns in your current codebases, prioritize attack surfaces, hunt for similar issues, and assess real-world exploitability in your specific environment.
metadata	{"short-description":"Red-team CVE intelligence — variant hunting, surface prioritization, and exploitability assessment","category":"vulnerability-research","priority":"high"}

CVE Research (Red Team Edition)

CVEs are not just a patch list. They are a map of where the industry has already been exploited.

Your job is to use that map to find similar (or identical) problems in the targets you're authorized to attack — faster and more effectively than generic code review.

Red Team Philosophy

• Public CVEs are free reconnaissance. The hardest part of many bugs is knowing where to look. CVEs tell you exactly where other people have succeeded.
• Prioritize variant hunting. If Log4Shell was bad, go look for every custom logging or JNDI-like pattern in your target. If a crypto library had a timing issue, go look at how your target handles similar operations.
• KEV and EPSS are not just risk scores — they are "this has been used to make money in the wild" signals. Use them to decide which code paths deserve your most aggressive attention.
• Be willing to draw offensive conclusions. If a CVE is in KEV, has high EPSS, and your target has the vulnerable component reachable from an attacker-controlled entry point, treat it as a serious lead until proven otherwise.

Core Workflow

1. Identify High-Leverage CVEs

   • Start with recent KEV entries and high-EPSS vulnerabilities that match technologies in your target (frameworks, libraries, crypto, auth, parsers, etc.).
   • Look for CVEs in the exact dependency tree or similar custom implementations.

2. Map to Your Target

   • Find where the vulnerable pattern could exist (even if the exact library/version is different).
   • Ask: "Does this target have an equivalent dangerous pattern, even if it's not the same CVE?"

3. Assess Real Exploitability Here

   • Not just "is the version affected?" but "can an attacker actually reach and trigger this in our environment?"
   • Factor in: authentication requirements, sandboxing, network exposure, custom mitigations, and how the component is actually used.

4. Hunt for Variants

   • Use the CVE as a template. Search the codebase for similar dangerous constructions (string concatenation in queries, unsafe deserialization, weak signature checks, etc.).
   • This is often more valuable than the original CVE itself.

5. Prioritize and Escalate

   • High KEV + reachable in your target + no strong compensating controls = promote aggressively in finding-tracker.
   • Feed strong leads into code-vulnerability-review or exploit-chain-analysis.

Helper Script

python3 .grok/skills/cve-research/scripts/cve_lookup.py CVE-2021-44228
python3 .grok/skills/cve-research/scripts/cve_lookup.py --json CVE-2021-44228 CVE-2025-49113

The script pulls CVE.org + NVD + CISA KEV + EPSS + OSV data. Treat the output as a starting point, not the final answer. Always dig into the actual vendor advisory and the code in your target.

High-Value CVE Categories for Red Teaming

Focus your energy on these classes when they appear in or near your targets:

• Remote code execution / deserialization
• Authentication / authorization bypasses
• Crypto and signature validation failures
• SSRF and internal network access
• Parser and deserialization issues (especially in image, document, and protocol parsers)
• Supply chain / dependency confusion
• Sandbox escape primitives

Handoffs (Aggressive)

• Strong variant or reachability lead → code-vulnerability-review (point to the specific component)
• Multiple related issues that could chain → exploit-chain-analysis
• Confirmed high-impact in your environment → finding-tracker as a high-priority lead
• Needs live validation → web-app-security-inspection
• Native component → binary-reversing or binary-debugging

Bottom Line

CVE research in red team mode is not about making nice vulnerability intelligence reports.

It is about finding the next paid bug faster by learning from every public failure that came before you.

Use public pain as your shortcut. The attackers already did. So should you.