verify-exploit

name	verify-exploit
description	Develop and verify exploit code against a vulnerable Docker environment using fix commit analysis or public PoCs
allowed-tools	verify_exploit python_repl http_request use_browser

Exploit Code Development & Verification

Prerequisites

Before starting, you must have:

• Validated Fix/Patch URLs and/or PoC Exploit URLs from prior analysis
• CVE ID, affected software, affected versions, and vulnerability type

Docker Daemon Preflight

Use python_repl to run docker.from_env().ping(). If Docker is unavailable:

• STOP — do not attempt verify_exploit
• Mark all artifacts as UNVERIFIED
• Include the exact error and remediation hints (start Docker Desktop, check daemon/socket, docker ps)
• Proceed to report generation with unverified artifacts

Path Selection

Use Primary Path (5A) if validated Fix/Patch Commit URLs exist. Use Fallback Path (5B) only if:

• No Fix/Patch URLs were found
• All fix commit URLs were inaccessible or had no useful diff
• Primary path failed after retries

---

Primary Path: Generate Exploit from Fix Commit Analysis

1. Select the best fix commit. Prefer NVD-tagged "Patch" commits, then GitHub Advisory patch references. Prefer the official upstream repository.

2. Fetch the commit diff. Use http_request or python_repl:

   • GitHub commit URLs: append .patch or .diff
   • GitHub pull request URLs: append .diff
   • Other platforms: attempt similar approaches or use use_browser

3. Analyze the diff. Determine:

   • What code was changed (files, functions, lines)
   • What the fix does (security check, validation, sanitization)
   • What the pre-patch vulnerable behavior was (the absence of the fix IS the vulnerability)
   • The attack vector (input, endpoint, parameter, or sequence that triggers it)

4. Determine exploit mode:

   • "remote": vulnerability exploited via network traffic to a listening service. Exploit runs in a separate container using TARGET_HOST and TARGET_PORT env vars.
   • "local": vulnerability triggered locally (privilege escalation, file parsing, deserialization, buffer overflow, command-line tool exploits). Exploit runs INSIDE the target container. Do NOT use TARGET_HOST/TARGET_PORT.

5. Write original exploit code targeting the pre-patch behavior:

   • Python (preferred), bash, or sh. For local mode, prefer bash/sh.
   • Print clear output: "EXPLOIT SUCCESSFUL: " on success
   • Exit code 0 on success, non-zero on failure

6. Write a Dockerfile following the rules in references/dockerfile-rules.md.

7. Call verify_exploit with ALL required parameters: dockerfile_content, exploit_code, exploit_language, cve_id, target_info (with affected_software, affected_versions, vulnerability_type), exploit_mode, and target_port (required for remote mode).

8. Handle results (up to 3 retries):

   • build_error: read build_log, fix Dockerfile, retry
   • target_error: read target_logs and build_log, fix Dockerfile, retry
   • failed: review exploit_output and target_logs, adjust exploit or try alternative sources
   • Docker daemon errors: STOP immediately, mark as unverified

---

Fallback Path: Use Public PoC Exploits

Select ONE most promising PoC:

1. NVD reference links with original researcher's PoC
2. GitHub Advisory page with PoC
3. GitHub repository with most stars containing a PoC

Do NOT attempt every link — pick the single best candidate.

Analyze the PoC: Classify it (RCE, DoS, info-leak) by looking for network calls, command execution, and memory corruption indicators.

Write a Dockerfile following references/dockerfile-rules.md. Choose exploit mode based on whether the PoC targets a network service ("remote") or triggers locally ("local"). For remote mode, update the PoC to read TARGET_HOST and TARGET_PORT from environment variables.

Call verify_exploit and handle results (up to 5 retries):

• build_error or target_error: read logs, fix Dockerfile, retry. If a public GitHub PoC exists, rebuild until it succeeds.
• If build_error persists: check GitHub advisory for preconditions; try base image with the vulnerable package for local exploits.
• failed: adjust exploit. If still failing, try a different PoC source.
• Docker daemon errors: STOP immediately, mark as unverified.

---

Common Rules (Both Paths)

• Docker cleanup is automatic — verify_exploit removes containers, networks, and images after each run
• Save the exact Dockerfile content and exploit code for the final report
• Construct and save: (1) the Docker CLI build command, (2) the exploit execution command
• Note which path was used (fix-commit-derived vs public PoC) and why
• Only skip verify_exploit entirely if the vulnerability targets kernel, hardware, or hypervisor that cannot run in Docker — state the reason

Choosing exploit_mode

Mode	Use for
"local"	Privilege escalation, file parsing bugs, library vulnerabilities triggered by local input, command injection in local tools, deserialization, buffer overflows
"remote"	Any vulnerability exploited by sending network traffic to a listening service (web servers, databases, APIs, network daemons)

Environment Variables

If the target requires auth or feature toggles, pass them via target_env in verify_exploit (e.g., {"LANGFLOW_SKIP_AUTH_AUTO_LOGIN": "true"}).

Node.js ES Modules

When building Docker images for Node.js packages published as ES modules, add "type": "module" to package.json and use import instead of require().