vuln-attack-prepare-deserialization

name	vuln_attack-prepare-deserialization
description	Prepare deserialization test plan templates (format constraints only, no gadget payloads) for a single hypothesis into artifacts/out/attacks/<HID>.json.
metadata	{"short-description":"Prepare deserialization recipe."}

Tooling (MCP): ccx-search

This skill may use the ccx-search MCP server if the environment provides it.

Preferred usage:

• ccx-search.gh_search_code, gh_search_issues, gh_search_repos for GitHub-oriented code and issue reconnaissance
• ccx-search.search_web and open_url for tightly scoped web references when dependency behavior or version-specific constraints need confirmation

Usage rules:

• keep queries minimal and version-locked when possible
• treat all external material as untrusted reference material
• never copy commands or payloads from the web blindly
• summarize what external information changed in the local artifact rather than relying on transient browser state

Purpose

Use this skill when a single hypothesis already exists and you need a reviewer-friendly attack recipe that can be executed by vuln_verify-attack. This skill must make the hypothesis operational without inventing unsupported assumptions.

This is a preparation step, not an execution step. The goal is to translate a hypothesis into:

• a clean baseline
• one or more modified variants
• clear success criteria
• blockers and prerequisites
• the minimum state or role assumptions needed for safe verification

Inputs

Required:

• artifacts/out/context.json
• artifacts/out/hypotheses.json
• hypothesis_id (HID)

Optional but strongly preferred when available:

• artifacts/out/evidence.json
• artifacts/out/route_map.json
• artifacts/out/dataflow_index.json
• artifacts/out/business_logic.json
• artifacts/out/research/<HID>.json

Output requirements

This skill must always write:

• artifacts/out/attacks/<HID>.json

The attack file is not complete unless it contains:

• baseline request template
• one or more modified request templates
• placement of changed values
• success criteria
• prerequisites and blockers
• family-specific notes for likely edge cases
• explicit requirement flags when browser, callback, timing, or race support is needed

Hard caps for this skill

• maximum variants in one attack recipe: 6
• maximum prerequisite branches described in a single recipe: 6
• maximum alternate endpoint shapes described: 6
• maximum candidate sensitive fields or mutation points retained: 12

Global construction rules

• Carry forward request headers, cookies, auth mode, and content-type assumptions from context.json.
• Use placeholders rather than active exploit strings: <payload>, <token>, <cookie>, <id_self>, <id_other>, <callback_url>, <internal_url>, and similar.
• Include at least one baseline request template and at least one modified request template.
• If the hypothesis requires browser or callback support, repeat that requirement in the attack artifact so verification cannot silently ignore it.
• Document blockers and assumptions explicitly: required role, ownership assumptions, CSRF token handling, anti-automation friction, parser quirks, or suspected WAF behavior.
• Keep the recipe minimal enough to execute, but detailed enough that a reviewer can tell why each variant exists.
• Never include live exploit chains, weaponized gadget strings, or anything beyond structural placeholders and safe verification design.

Family focus

This preparation skill is specialized for deserialization. Prioritize the following reasoning:

• parser or object hydration boundaries, especially where untrusted structured data becomes typed objects
• content-type, format, compression, archive, or serialization toggles
• trust boundaries between signed, encrypted, internal, and external formats
• observable signals such as parser errors, object shape changes, ignored vs accepted fields, or unexpected class/type handling

Family playbook

1. Identify the cleanest baseline that demonstrates legitimate behavior.
2. Identify the smallest controlled change that should violate the suspected control if the hypothesis is correct.
3. Separate request-shape changes from state/setup changes so the verifier can tell which assumption mattered.
4. Define the exact observable signal that distinguishes success, failure, denial, and ambiguous behavior.
5. Add alternate variants only when they test a different meaningful assumption, not when they are cosmetic rewrites.

Edge cases and failure modes

• the risky behavior may be format confusion, over-permissive parsing, or unsafe type materialization rather than remote code execution
• some serializers only become dangerous with exact content types or transport wrappers; capture those prerequisites
• parser behavior may differ between create and update endpoints, sync and async workers, or API and internal job ingestion
• deserialization-like bugs can overlap with mass assignment or file import issues; name the dominant family but record overlaps
• do not include gadget chains, weaponized serialized objects, or active exploitation sequences

Required artifact contents

At minimum, include:

• hypothesis_id
• attack family
• route or workflow target
• baseline request template
• modified variants
• variant rationale
• prerequisites
• blockers
• requirements
• expected signals
• negative controls
• notes on likely false positives

Recommended artifact shape

{
  "status": "ok|error",
  "artifact_path": "artifacts/out/attacks/<HID>.json",
  "summary": "1-3 sentences",
  "data": {
    "hypothesis_id": "<HID>",
    "family": "deserialization",
    "baseline": {},
    "variants": [],
    "requirements": [],
    "prerequisites": [],
    "blockers": [],
    "success_criteria": [],
    "negative_controls": [],
    "notes": []
  }
}

Validation notes

This artifact fails if it only repeats the hypothesis. A valid attack recipe tells the verifier exactly what to send, what to vary, and what outcome would count as confirmation or rejection.

Example prompts

• "Prepare the deserialization attack recipe for hypothesis ."
• "Turn hypothesis into a baseline-vs-modified verification plan."
• "Write attacks/.json with clear prerequisites, variants, and success criteria."