| 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
-
Structural, not historical: Axes are defined by the nature of the mutation, not by who discovered it or when.
-
Orthogonal where possible: Each axis should capture a different dimension. A technique should have a clear position on each axis.
-
Exhaustive within scope: Every technique found in Phase 2 must fit somewhere. If a technique doesn't fit, the axes need revision.
-
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:
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:
- What fundamental property of the technology makes this mutation space possible?
- Why do incremental patches fail to eliminate the threat?
- 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
