aibot88 CVE Research and Analysis
Usage
/greyhatcc:cve <CVE-ID or product name or keyword>
Smart Input
{{ARGUMENTS}} is parsed automatically:
- CVE ID (CVE-2024-xxxx) → used for CVE lookup and exploit search
- Finding ID (FIND-001) → looked up in findings_log.md
- Description (free text) → used as search/filter query
- File path → read and analyzed directly
- Empty → error: "Usage: /greyhatcc: "
No format specification needed — detect and proceed.
Context Loading (MANDATORY)
Before executing this skill:
- Load scope:
.greyhatcc/scope.json— verify target is in scope, note exclusions - Load hunt state:
.greyhatcc/hunt-state.json— check active phase, resume context - Load program files:
findings_log.md,tested.json,gadgets.json— avoid duplicating work - Load memory: Check MEMORY.md for target-specific notes from previous sessions
- Load recon:
tech_stack.md— correlate CVEs with detected versions
CVE Analysis Workflow
Step 1: Search
- By CVE ID: Use MCP tool
greyhatcc_sec__cve_detailfor specific CVE - By product: Use MCP tool
greyhatcc_sec__cve_searchwith product name + version - By keyword: Use MCP tool
greyhatcc_sec__cve_searchwith vulnerability type
Step 2: Enrich
For each CVE found:
- Get CVSS score and vector breakdown — understand each metric
- Search for exploits via
greyhatcc_sec__exploit_db_search - Search Shodan exploits via
greyhatcc_s__shodan_exploits_search - WebSearch for GitHub PoCs:
"CVE-YYYY-NNNNN" exploit PoC - Check for Nuclei templates:
"CVE-YYYY-NNNNN" nuclei template
Step 3: CVSS Interpretation
| CVSS Metric | Meaning for Testing |
|---|---|
| AV:N (Network) | Exploitable remotely — highest priority |
| AV:A (Adjacent) | Needs network proximity — lower priority for remote testing |
| AC:L (Low) | No special conditions — straightforward exploitation |
| AC:H (High) | Needs specific config/timing — may not apply to target |
| PR:N (None) | No auth needed — can test unauthenticated |
| PR:L (Low) | Needs basic account — need test credentials |
| UI:N (None) | No user interaction — server-side exploitable |
| UI:R (Required) | Needs victim action — client-side attack |
Step 4: Exploit Availability Check
| Availability Level | What It Means | Action |
|---|---|---|
| Public exploit on Exploit-DB | Ready to use or adapt | Download, test against target |
| Metasploit module exists | Automated exploitation | Use if in scope |
| GitHub PoC exists | May need adaptation | Review code, adapt for target |
| Nuclei template exists | Automated detection | Run nuclei with specific template |
| No public exploit | Theoretical only | NOTE: most programs reject "vulnerable library without working PoC" |
| Patch diff available | Can reverse-engineer exploit | Write custom PoC from patch analysis |
Step 5: Version Correlation
Cross-reference detected versions from recon/tech_stack.md:
For each technology in tech_stack.md:
1. Extract exact version (e.g., "Apache 2.4.51")
2. Search CVEs for that product + version range
3. Check if detected version falls in affected range
4. If yes AND exploit available → HIGH priority testing target
5. If yes AND no exploit → add to gadgets as potential, low priority
Step 6: Analyze
Delegate to vuln-analyst for deep analysis or vuln-analyst-low for quick assessment.
Step 7: Output Format
## CVE-YYYY-NNNNN
**Severity**: CRITICAL (CVSS 9.8)
**Vector**: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
**Description**: ...
**Affected**: Product X versions 1.0-2.3
**Target Version**: Product X 2.1 (detected in tech_stack.md)
**In Affected Range**: YES
**Exploits Available**: Yes - Exploit-DB #12345, Metasploit module, GitHub PoC
**Exploit Tested**: [YES/NO] — [result]
**Remediation**: Upgrade to version 2.4+
**Chain Potential**: [what this CVE provides if exploited: code_execution, file_read, etc.]
State Updates
After completing this skill:
- Update
tested.json— record what was tested (asset + vuln class) - Update
gadgets.json— add any informational findings with provides/requires tags for chaining - Update
findings_log.md— log any confirmed findings with severity - Update hunt-state.json if in active hunt — set lastActivity timestamp