eresus-variant-analysis

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:

1. Source — where does attacker-controlled data enter?
2. Sink — which dangerous API/function receives the data?
3. Missing guard — what validation/sanitization is absent?
4. Trust boundary — which trust boundary was violated?
5. 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:

1. Is the source actually attacker-controlled in this context?
2. Is the sink reachable from the source in the execution flow?
3. Are there mitigations present that neutralize this specific instance?
4. 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