aibot88 GHSA / CVE Variant Analysis
Purpose
When a known vulnerability (GHSA, CVE, or manually discovered bug) is identified, systematically search the entire codebase for similar patterns. The goal is to find every instance of the same underlying weakness — not just the one that was reported.
This skill operates like a GitHub Security Lab researcher performing variant analysis after a vulnerability disclosure.
Workflow
Phase 1: Decompose the Known Vulnerability
Extract the structural components of the known bug:
- Source — where does attacker-controlled data enter?
- Sink — which dangerous API/function receives the data?
- Missing guard — what validation/sanitization is absent?
- Trust boundary — which trust boundary was violated?
- Language pattern — what does the vulnerable code look like structurally?
Example decomposition:
CVE-2024-XXXX:
Source: HTTP request body → `req.body.username`
Sink: `db.query("SELECT * FROM users WHERE name = '" + username + "'")`
Missing guard: No parameterized query, no input sanitization
Trust boundary: User input → Database query
Pattern: String concatenation in SQL query construction
Phase 2: Generalize the Pattern
Abstract away specific variable names and file paths to create search queries:
- Exact sink search — search for the dangerous function/method name
- Pattern search — search for the structural pattern (e.g., string concatenation + SQL keywords)
- Framework search — search for framework-specific equivalents
Use view_file and grep_search to locate all candidate instances.
Phase 3: Triage Each Match
For every match found, answer these questions:
- Is the source actually attacker-controlled in this context?
- Is the sink reachable from the source in the execution flow?
- Are there mitigations present that neutralize this specific instance?
- Does the framework provide implicit protection here?
Classify each match:
- CONFIRMED — same pattern, exploitable, no mitigation
- LIKELY — same pattern, probably exploitable, needs deeper trace
- MITIGATED — same pattern exists but protection is present
- FALSE POSITIVE — pattern match but not actually exploitable
Phase 4: Chain Variants
When multiple variants exist, check if they can combine:
- Can variant A bypass a control that protects variant B?
- Do multiple low-severity variants chain into a high-severity exploit?
- Does fixing one variant reveal or enable another?
Phase 5: Report
For each confirmed variant, report:
### Variant: [ID]
**Original CVE/GHSA**: [reference]
**File**: [path]:[line]
**Category**: [Same-function | Same-pattern | Cross-language | Framework-level]
**Vulnerable Code**:
[show the code]
**Exploit Path**:
[source] → [intermediaries] → [sink]
**Impact**: [what an attacker achieves]
**Remediation**: [specific fix for this instance]
Variant Categories
| Category | Description | Example |
|---|---|---|
| Same-function | Same vulnerable function called from different entry points | exec() called from 3 different API handlers |
| Same-pattern | Same dangerous pattern in different functions | SQL concatenation in getUser(), getOrder(), getProduct() |
| Cross-language | Same logical flaw in different language implementations | SQLi in both the Python API and the Go microservice |
| Framework-level | Vulnerable pattern in framework/library code affecting multiple consumers | Custom ORM rawQuery() method used by 12 models |
Tooling Constraints
Use ONLY these tools for variant search:
view_file— read source codegrep_search— find pattern matches across the codebase
Do NOT use terminal commands like grep, rg, ag, sed, awk, or any shell-based search.
Integration
Use this skill AFTER discovering an initial vulnerability with:
eresus-manual-security-audit(manual finding)eresus-sast-scanner(automated finding)- External advisory (GHSA, CVE, bug bounty report)
Feed confirmed variants INTO:
eresus-remediator(for batch patching)eresus-pr-security-review(for ongoing monitoring)