vulnerability-topic-taxonomy-builder

name

vulnerability-topic-taxonomy-builder

description

Build a comprehensive, generalized mutation/variation taxonomy for any given vulnerability topic. Triggered when the user asks for a reclassification, taxonomy, mutation catalog, variation matrix, or attack surface map for a vulnerability class — such as HTTP smuggling, deserialization, SSRF, path traversal, race conditions, prototype pollution, etc. The skill conducts systematic multi-source research (academic papers, conference talks, CVEs, bug bounties, tooling), then synthesizes findings into a unified document organized by generalized structural criteria — never by paper or source. Output is a deeply structured Markdown reference document.

Vulnerability Topic Taxonomy Builder

Build a comprehensive, generalized taxonomy of mutation/variation types for any given vulnerability topic. The output is a deeply structured Markdown reference document that organizes the entire attack surface under generalized criteria — techniques, structural targets, architectural conditions — rather than by individual paper or source.

Core Principle

Sources inform the taxonomy; they do not structure it.

Every finding from papers, talks, CVEs, and bounties must be dissolved into generalized categories defined by what is being mutated and what discrepancy it creates. The reader should never need to know which paper introduced a technique to understand where it fits.

---

Workflow Overview

1. SCOPE       → Identify vulnerability topic, set boundaries
2. RESEARCH    → Systematic multi-source collection (5 categories, 10-30 searches)
3. AXIS DESIGN → Derive classification axes from collected data
4. SYNTHESIS   → Write taxonomy under generalized criteria
5. ENRICHMENT  → CVE/bounty table, tool matrix, summary
6. DELIVERY    → Save and present

---

Phase 1: Scope Definition

Identify the vulnerability topic from the user's request and establish boundaries.

Input Patterns

The user may say things like:

• "Build a taxonomy of SSRF variations"
• "Reclassify deserialization attack types"
• "Map the mutation space for race conditions"
• "Create a comprehensive variation catalog for prototype pollution"

Scope Negotiation

If the topic is too broad (e.g., "web vulnerabilities"), propose a partition:

Too broad: "web application security"
Good scope: "HTTP Request Smuggling mutations"
Good scope: "Server-Side Request Forgery (SSRF) bypass techniques"
Good scope: "Deserialization attack chains across languages"

Target size: A single taxonomy document should contain 30–70 distinct subtypes organized under 5–10 top-level categories. If the topic would produce significantly more, propose splitting into volumes.

Scope Output

Before proceeding, mentally establish:

- Topic: [exact vulnerability class]
- Boundary: [what's in vs. out of scope]
- Expected categories: [rough initial guess, will be revised after research]
- Depth: [single-vector deep-dive vs. cross-cutting survey]

---

Phase 2: Systematic Research

This is the most labor-intensive phase. The goal is to build a saturated picture of the attack surface — not just well-known techniques, but novel, obscure, and emerging ones.

Research Strategy: 5 Source Categories

Search all 5 categories in order. Minimum 2 searches per category, more for complex topics.

Category A: Latest CVEs and Bug Bounties (2–4 searches)

Query patterns:
  "{topic} CVE 2024 2025"
  "{topic} bug bounty writeup"
  "{topic} vulnerability disclosure"

Purpose: Ground truth — what actually gets exploited in the wild
Extract: CVE IDs, CVSS scores, affected products, root cause analysis, bounty amounts

Category B: Academic Papers and Conference Talks (3–5 searches)

Query patterns:
  "{topic} BlackHat DEF CON 2024 2025"
  "{topic} paper USENIX IEEE ACM"
  "{topic} research 2024 2025 new technique"
  "{topic} differential fuzzing"

Purpose: Systematic attack classifications and novel technique discovery
Extract: Paper titles, classification frameworks, novel attack primitives, tool names

Category C: Practitioner Blogs and Writeups (2–4 searches)

Query patterns:
  "{topic} attack techniques tutorial"
  "{topic} bypass technique 2024 2025"
  "{topic} exploit chain"
  "PortSwigger {topic} research"

Purpose: Real-world exploitation patterns and creative combinations
Extract: Technique names, payload patterns, exploit chains, edge cases

Category D: Defensive Research and Tools (1–3 searches)

Query patterns:
  "{topic} detection tool scanner"
  "{topic} defense mitigation"
  "{topic} fuzzer"

Purpose: Understand the detection landscape and identify what's being missed
Extract: Tool names, detection approaches, known blind spots

Category E: Emerging / Bleeding Edge (1–3 searches)

Query patterns:
  "{topic} new attack 2025"
  "{topic} novel bypass"
  "Top 10 web hacking techniques 2025 {topic}"

Purpose: Capture techniques not yet in papers or CVE databases
Extract: New primitives, proof-of-concepts, nominations for annual awards

Research Depth by Complexity

Complexity	Total Searches	Web Fetches	Expected Subtypes
Focused	10–15	3–5	20–35
Standard	15–25	5–10	35–55
Deep	25–40	10–20	55–80

Research Notes Template

As you research, maintain internal notes in this structure:

## Research Notes (internal, not for output)

### Novel Techniques Discovered
- [technique]: [one-line description] — [source]

### Classification Frameworks Found in Literature
- [Paper X] uses: [their axes]
- [Paper Y] uses: [their axes]
→ Synthesis needed: [notes on merging/reconciling]

### CVE / Bounty Inventory
| ID | Year | Root Cause | Impact | Amount |
|----|------|-----------|--------|--------|

### Tool Inventory
| Tool | Target | Technique | Source |

### Axis Candidates
- Candidate axis 1: [what is mutated]
- Candidate axis 2: [what discrepancy it creates]  
- Candidate axis 3: [deployment scenario]

---

Phase 3: Axis Design

After research, design the classification axes. This is the intellectual core of the skill — transforming source-specific findings into a generalized structure.

Axis Design Principles

1. Structural, not historical: Axes are defined by the nature of the mutation, not by who discovered it or when.

2. Orthogonal where possible: Each axis should capture a different dimension. A technique should have a clear position on each axis.

3. Exhaustive within scope: Every technique found in Phase 2 must fit somewhere. If a technique doesn't fit, the axes need revision.

4. Hierarchical: Top-level categories (5–10) → subcategories (2–8 each) → individual subtypes.

Standard Axis Template

Most vulnerability topics benefit from these three axes:

Axis 1: Mutation Target (WHAT is mutated)

The structural component of the message/request/object being modified.
This is always the PRIMARY axis — it structures the main body of the document.

Examples:
  HTTP smuggling → message framing, headers, URL, body structure, connection state
  SSRF → URL scheme, host, port, path, IP representation, DNS resolution
  Deserialization → type metadata, gadget chains, encoding, format structure

Axis 2: Discrepancy Type (WHAT mismatch it creates)

The nature of the parsing/interpretation difference between two components.
This is the CROSS-CUTTING axis — it explains WHY each mutation works.

Examples:
  HTTP smuggling → framing mismatch, path mismatch, host mismatch, body semantics mismatch
  SSRF → validation bypass, redirect follow, DNS rebinding, protocol confusion
  Deserialization → type confusion, gadget invocation, encoding bypass

Axis 3: Attack Scenario (WHERE it's weaponized)

The architectural deployment context in which the mutation becomes exploitable.
This is the MAPPING axis — it connects techniques to real-world impact.

Examples:
  HTTP smuggling → server-side HRS, client-side desync, cache poisoning, WAF bypass
  SSRF → cloud metadata, internal service, file read, port scan
  Deserialization → RCE, DoS, auth bypass, data exfiltration

Axis Derivation Process

1. List ALL techniques found in Phase 2
2. For each, ask: "What structural component does this modify?"
   → Group answers → these become Axis 1 categories
3. For each, ask: "What kind of mismatch/bypass does this create?"
   → Group answers → these become Axis 2 types
4. For each, ask: "In what deployment scenario is this exploitable?"
   → Group answers → these become Axis 3 scenarios
5. Verify: Can every technique be described as a combination of (Axis1, Axis2, Axis3)?
6. If gaps exist, add categories or revise axes

---

Phase 4: Synthesis — Writing the Taxonomy Document

Document Structure

# {Topic} Mutation/Variation Taxonomy

---

## Classification Structure

[Explain the axes in 2-3 paragraphs. Define key terms. 
Show the Axis 2 types in a summary table — these are the 
cross-cutting discrepancy types that apply across all categories.]

[If the topic has a fundamental mechanism (like HTTP's 4 length 
interpretation methods), present it here as a shared foundation.]

---

## §1. {Axis 1 Category 1 Name} ({Structural Target})

[1-2 sentence introduction: what this category covers and why it matters]

### §1-1. {Subcategory}

[Narrative paragraph explaining the mechanism]

| Subtype | Mechanism | Key Condition |
|---------|-----------|---------------|
| **{name}** | {how it works} | {when it's exploitable} |
| ... | ... | ... |

[If a subtype deserves extended explanation, add a paragraph after the table]

### §1-2. {Subcategory}
...

---

## §2. {Axis 1 Category 2 Name}
...

[Continue for all categories]

---

## Attack Scenario Mapping (Axis 3)

| Scenario | Architecture | Primary Mutation Categories |
|----------|-------------|---------------------------|
| {name}   | {conditions} | §X + §Y + §Z             |
...

---

## CVE / Bounty Mapping ({year range})

| Mutation Combination | CVE / Case | Impact / Bounty |
|---------------------|-----------|----------------|
...

---

## Detection Tools

| Tool | Target | Core Technique |
|------|--------|---------------|
...

---

## Summary: Core Principles

[2-3 paragraphs synthesizing the fundamental insight — what underlying 
property of the technology makes this entire class of mutations possible, 
why incremental fixes fail, and what the structural solution looks like]

---

*This document was created for defensive security research and vulnerability 
understanding purposes.*

Writing Rules

Rule 1: Source Dissolution

NEVER: "WAFFLED (ACSAC 2025) discovered 1,207 bypasses..."
       "According to Kettle's 2025 research..."
       "HTTP Garden found..."

ALWAYS: Dissolve the finding into the appropriate category and describe 
        the technique generically. Reference the source only in:
        - CVE/Bounty mapping table (for specific incidents)
        - Tool matrix (for specific tools)
        - Inline parenthetical for very recent, unreplicated findings
          e.g., "($8,500 Google VRP bounty)"

Rule 2: Mechanism Over Attribution

NEVER: "Kettle 2025's 0.CL desync uses early response gadgets"

ALWAYS: "0.CL desync occurs when the Front-End treats a request as 
        having no body while the Back-End reads Content-Length bytes, 
        creating a deadlock. This deadlock is broken via Early Response 
        Gadgets — endpoints that respond before consuming the full body 
        (static files, Windows reserved filenames, server redirects, 
        Expect: 100-continue)."

Rule 3: Structural Hierarchy

Every subtype entry must contain:
  1. A descriptive NAME (not a paper's internal label)
  2. The MECHANISM (how it works, 1-3 sentences)
  3. A concrete EXAMPLE (payload, header, URL pattern)
  4. The CONDITION under which it's exploitable (if applicable)

Optional:
  - CVE reference (inline, parenthetical)
  - Bounty amount (inline, parenthetical)
  - Affected products (for very specific subtypes)

Rule 4: Cross-Reference, Don't Repeat

When a technique spans multiple categories, explain it in the PRIMARY 
category and cross-reference from others:

"This technique relies on TE header obfuscation (§2-1) to create 
the initial framing mismatch."

Use §-notation consistently for cross-references.

Rule 5: Progressive Disclosure

Start each category with the simplest, most classic technique.
Progress toward newer, more exotic variations.
End with bleeding-edge / 2025 discoveries.

This mirrors how practitioners learn the space.

Quality Checklist

Before finalizing, verify:

• Every technique from Phase 2 notes has a home in the taxonomy
• No section is named after a paper, tool, or researcher
• Each top-level category (§1, §2, ...) targets a different structural component
• Each subtype has: name + mechanism + example
• The CVE/Bounty table maps to specific § references
• The tool matrix covers both offensive and defensive tools
• The summary identifies the root cause, not just symptoms
• Cross-references use §-notation
• The document reads coherently without consulting any source

---

Phase 5: Enrichment

CVE / Bounty Table

For each significant real-world instance (last 2 years prioritized):

| Mutation Combination | CVE / Case | Impact / Bounty |
|---------------------|-----------|----------------|
| §1-2 + §2-1 + §6   | CVE-XXXX-YYYY (Product) | $X,XXX. Brief impact description |

Rules:

• Link mutation subtypes to §-numbers
• Include bounty amounts where public
• Note patch timelines for high-impact cases
• Prioritize 2024–2025, include 2023 if landmark

Detection Tool Matrix

| Tool | Target Scope | Core Technique |
|------|-------------|---------------|
| **{Name}** ({type}) | {what it tests} | {how it works, 1 line} |

Include:

• Offensive tools (scanners, fuzzers, Burp extensions)
• Defensive tools (normalizers, guardians, WAFs)
• Research tools (differential fuzzers, REPL environments)

Summary Section

The summary must answer three questions:

1. What fundamental property of the technology makes this mutation space possible?
2. Why do incremental patches fail to eliminate the threat?
3. What would a structural solution look like?

---

Phase 6: Delivery

File Output

Save to: /mnt/user-data/outputs/{Topic}_Mutation_Taxonomy_{Year}.md

Use present_files to deliver to the user.

Reference

Reference must be appended at end of the content

Language

All contents must be written in English.

---

Iteration Support

After delivering the initial taxonomy, the user may request:

• "Add X" → Research the specific area and integrate into existing structure
• "Go deeper on §N" → Expand that category with additional research
• "Cont" → Search for additional sources and enrich the existing document
• "Update for {event/paper}" → Integrate new findings while maintaining structure

For all iterations: never break the generalized structure. New findings are dissolved into existing categories or, if they represent a genuinely new structural dimension, new categories are added.

---

Appendix: Example Axis Designs for Common Topics

These are starting points, not prescriptions. Always derive axes from actual research.

HTTP Request Smuggling / Desync

Axis 1 (Target):  Message framing, Header obfuscation, URL/path, Host, 
                   Body/Content-Type, Connection/protocol, Low-level parser, 
                   Payload encoding
Axis 2 (Discrepancy): Framing mismatch, Path mismatch, Host mismatch, 
                       Body semantics mismatch
Axis 3 (Scenario): Server-side HRS, Client-side desync, Response poisoning, 
                    Cache poisoning, WAF bypass, ACL bypass

SSRF (Server-Side Request Forgery)

Axis 1 (Target):  URL scheme, IP representation, Hostname, Port, Path, 
                   DNS resolution, Redirect chain, Protocol handler
Axis 2 (Bypass):  Allowlist bypass, Blocklist bypass, Parser differential, 
                   TOCTOU, Protocol confusion
Axis 3 (Scenario): Cloud metadata, Internal API, File read, Port/service scan, 
                    RCE chain

Deserialization

Axis 1 (Target):  Type metadata, Object graph, Gadget chain, Encoding layer, 
                   Format structure, Magic method
Axis 2 (Effect):  Type confusion, Arbitrary invocation, Resource exhaustion, 
                   Property injection
Axis 3 (Scenario): RCE, Auth bypass, DoS, Data exfiltration, Privilege escalation

Prototype Pollution

Axis 1 (Target):  Assignment path, Merge operation, Clone operation, 
                   Parser output, Framework binding
Axis 2 (Gadget):  Property override, Template injection, Path traversal, 
                   Auth bypass, RCE
Axis 3 (Scenario): Client-side (DOM), Server-side (Node.js), Supply chain

Path Traversal / Confusion

Axis 1 (Target):  Encoding, Normalization, Separator, Null byte, 
                   Module pipeline, Filesystem semantics
Axis 2 (Mismatch): Proxy vs origin, Cache vs origin, WAF vs app, 
                    OS-level vs app-level
Axis 3 (Scenario): File read, ACL bypass, Cache deception, RCE

Race Conditions / TOCTOU

Axis 1 (Target):  Authentication state, Session binding, File operation, 
                   Database transaction, Token validation, Rate limit
Axis 2 (Window):  Single-packet, Multi-connection, Last-byte sync, 
                   Database-level, Filesystem-level
Axis 3 (Scenario): Limit bypass, Double-spend, Privilege escalation, 
                    File overwrite