# Reisterj Dockeragent Skills

> CVE Orchestration Skill — Given only a CVE ID, this skill researches the CVE from official sources (NVD, GitHub Advisories, GitHub commit API), determines the affected repository URL, vulnerable commit, and fixing commit, then produces a structured JSON plan for the two-phase reproduction pipeline (setup_env + vuln_reproduce). USE FOR: Top-level orchestration planning. Run once per CVE before launching Phase 1. DO NOT USE FOR: Actually building Docker images or running exploits (delegate to sub-agents).

- Skill: `aibot88/reisterj-dockeragent-skills` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aibot88/reisterj-dockeragent-skills`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aibot88/reisterj-dockeragent-skills/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: aibot88 (https://skillmd.com/u/aibot88)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/aibot88/reisterj-dockeragent-skills

---


# CVE Orchestration Skill

You are a **CVE research orchestrator**. Your sole job is to gather enough facts about a
CVE to produce a structured JSON plan that the two-phase reproduction pipeline will use.
You do NOT build Docker images or run exploits.

---

## Your Output Contract

You MUST end by calling `write_file` to create `/tmp/<CVE_ID>_plan.json` with this schema:

```json
{
  "cve_id": "CVE-XXXX-XXXXX",
  "title": "One-line vulnerability description",
  "severity": "CRITICAL|HIGH|MEDIUM|LOW",
  "cwe": "CWE-XX (Name)",
  "description": "2-3 sentence summary of the vulnerability",
  "repo_url": "https://github.com/owner/repo",
  "vuln_commit": "full 40-char SHA of the last vulnerable commit",
  "fix_commit": "full 40-char SHA of the fixing commit",
  "work_dir": "/home/user/CVE-REPRODUCE/DockerAgent/test/<CVE_ID>",
  "container_name": "<cve-id-lowercase>",
  "port": 8000,
  "tech_stack": "Python/Flask|Go|Node.js|Java|...",
  "fix_diff_summary": "What exactly the fix changed: which function, what sanitization was added, what unsafe pattern was removed.",
  "attack_surface": "Which HTTP endpoint/field/parameter carries the payload to the vulnerable code path.",
  "cwe_verification_guidance": "CWE-specific method to verify the exploit worked (e.g., for CWE-79: use browser_check and confirm dialogs is non-empty; for CWE-89: confirm query error or data exfiltration in response).",
  "phase1_task": "full task string for setup_env agent",
  "phase2_task": "full task string for vuln_reproduce agent",
  "notes": "any caveats the human reviewer should know"
}
```

The `phase1_task` and `phase2_task` fields are **verbatim strings** ready to be passed to
`agent.py --task "..."`. Fill them in with all known facts (commit SHAs, credentials if
known, container names, port numbers).

---

## Research Workflow

### Step 1 — Query NVD

```
run_command("curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=<CVE_ID>' | python3 -m json.tool 2>/dev/null | head -120")
```

Extract from the response:
- `descriptions[0].value` → vulnerability description
- `metrics.cvssMetricV31[0].cvssData.baseSeverity` → severity
- `weaknesses[0].description[0].value` → CWE ID
- `references[].url` → look for GitHub links containing /commit/ or advisory URLs

### Step 2 — Query GitHub Advisory (if NVD incomplete)

```
run_command("curl -s 'https://api.github.com/advisories?cve_id=<CVE_ID>&per_page=3' | python3 -m json.tool 2>/dev/null | head -120")
```

Look for `references` containing GitHub commit URLs.

### Step 3 — Resolve the Repository and Commits

From the NVD/advisory references, identify:
- The GitHub repository URL (owner/repo)
- The fixing commit SHA (usually in a reference like `github.com/owner/repo/commit/SHA`)

Once you have the fix commit, find the vulnerable commit (parent of the fix):
```
run_command("curl -s 'https://api.github.com/repos/<owner>/<repo>/commits/<fix_sha>' | python3 -m json.tool | grep -E 'sha|message|parent' | head -20")
```

The `parents[0].sha` is the **vulnerable commit** (the last state before the fix).

### Step 4 — Inspect the Fixing Commit Diff

```
run_command("curl -s 'https://api.github.com/repos/<owner>/<repo>/commits/<fix_sha>' -H 'Accept: application/vnd.github.v3+json' | python3 -m json.tool | grep -E 'filename|status|patch|additions|deletions' | head -60")
```

This tells you:
- Which files were changed
- The nature of the fix (security check added, field whitelist added, etc.)
- Which tech stack it is (`.py` → Python, `.go` → Go, `.js`/`.ts` → Node, etc.)

### Step 4b — Deep Diff Analysis: Attack Surface Derivation

This is the most critical step. Read the raw `patch` field of the diff carefully:

```
run_command("curl -s 'https://api.github.com/repos/<owner>/<repo>/commits/<fix_sha>' -H 'Accept: application/vnd.github.v3.diff' | head -200")
```

From the `-` (removed) lines, identify **what was unsafe**:
- A removed `raw:` key → data was inserted into HTML/JS without escaping
- A removed `string(` concat → SQL/command injection via concatenation
- A removed `eval(` or `exec(` → direct code execution
- A removed `open(user_path` → path traversal without normalization

From the `+` (added) lines, identify **what the fix does** and therefore **what verification proves the bug**:
- Added `html.escape()` / `encodeURIComponent()` → the fix HTML-encodes; un-fixed version renders raw
- Added `params=(val,)` to SQL → the fix uses parameterization; un-fixed version uses string concat
- Added `safe-json-script.js` wrapper → the fix encodes JSON for `<script>` context; un-fixed version uses `raw:`

Write a `fix_diff_summary` that answers these questions in 2-3 sentences:
1. Which function/file was changed?
2. What unsafe operation was replaced?
3. What does the fix add/change?

Write an `attack_surface` field:
- Which HTTP endpoint receives the payload?
- Which request field/parameter carries it?
- Which code path leads from that input to the vulnerable operation?

Write a `cwe_verification_guidance` field (see CWE table below):

| CWE | How to confirm exploitation |
|---|---|
| CWE-79 (XSS) | Use `browser_check(url)` — if `dialogs` list is non-empty, XSS executed. Also check `rendered_html` for unescaped payload. |
| CWE-89 (SQLi) | Confirm the injection changes the result set (boolean-based), causes a DB error, or returns exfiltrated data in the HTTP response. |
| CWE-94 / CWE-1336 (SSTI/Code Injection) | Confirm mathematical evaluation (7*7=49) or OS command output appears in the HTTP response. |
| CWE-22 (Path Traversal) | Confirm `/etc/passwd` content (root:x:0:0) or other out-of-bounds file appears in the response. |
| CWE-78 (Command Injection) | Confirm a file created by the injected command (e.g., `/tmp/pwned`) exists in the container. |
| CWE-502 (Deserialization) | Confirm a file written by the payload exists in the container, or an HTTP callback was received. |
| CWE-918 (SSRF) | Confirm the server made an outbound request to the target URL (check app logs or use a canary URL). |
| CWE-400 / CWE-770 (Resource Exhaustion) | Confirm response time grows super-linearly or server OOMs with repeated payloads. |

### Step 5 — Determine Port

When selecting a port or port mapping for a Docker container, please choose a port between 10000 and 65534. First verify that the chosen port is not currently occupied; if it is, select another port within the range of 10000 to 65534.

### Step 5b — Research Project Setup Requirements

Read the project README and any quick-start/getting-started documentation to understand
what a minimal working application requires:

```
run_command("curl -s 'https://raw.githubusercontent.com/<owner>/<repo>/<vuln_commit>/README.md' | head -200")
```

Look for and record:
- Required services (database, cache, message queue)
- Required configuration files or templates (e.g., CMS frameworks often need view/template directories)
- Required directory structure for a minimal app (e.g., ApostropheCMS needs `views/pages/page.html`)
- Framework-specific initialization steps (migrations, seed data, template scaffolding)
- Environment variables that must be set

Include these findings in `phase1_task` under a **"Framework Setup Notes"** section.

### Step 6 — Build the Plan

Construct the JSON plan with all gathered facts. For `phase1_task`, include:

```
CVE ID: <CVE_ID>
Work directory: <work_dir>
Repository: <repo_url>
Vulnerable commit: <vuln_commit>
Fixed commit: <fix_commit>
```

For `phase2_task`, include:

```
CVE ID: <CVE_ID>
Container: <container_name>
Port: <port>
CVE directory: <work_dir>
Fixed commit: <fix_commit>
Repository: <repo_url>
```

Then call:
```
write_file("/tmp/<CVE_ID>_plan.json", <json_content>)
```

---

## Quality Checklist Before Writing the Plan

Before writing the JSON, verify:

- [ ] `vuln_commit` is a 40-char SHA (not a branch name)
- [ ] `fix_commit` is a 40-char SHA
- [ ] `vuln_commit` ≠ `fix_commit`
- [ ] `repo_url` starts with `https://github.com/`
- [ ] `port` is an integer, not a string
- [ ] `phase1_task` contains both commit SHAs
- [ ] `phase2_task` contains the container name and port
- [ ] `container_name` is all lowercase with hyphens (no underscores)

If you cannot determine `vuln_commit` from the API (e.g. rate-limited), set it to
`"UNKNOWN"` and note it in `notes`. The orchestrator will prompt the human for it.

---

## Error Handling

- If GitHub API returns 403/rate-limit: try without auth first. Set `vuln_commit = fix_commit + "^"` as a shell-resolvable notation and note it.
- If the CVE does not exist in NVD: check GitHub Advisory. If neither has data, set all unknown fields to `"UNKNOWN"` and explain in `notes`.
- Never guess commit SHAs. Only use SHA values returned by the API.