Exploit Test

Vulnetix Exploit Test Skill

Use when

• You just applied a fix and want to validate the exploit path no longer responds.
• Confirming a patch deployed correctly to staging before promoting to production.
• Producing a copy-pasteable test command for QA hand-off.
• Comparing pre-fix vs post-fix behaviour with the same payload.
• Building authorised proof-of-fix evidence for an audit.

Don't use for

• Unauthorised testing — the skill explicitly requires user-supplied authorised targets.
• Live attack simulation — use a dedicated red-team tooling chain.
• Generating detection rules — use /vulnetix:detection-rules.

Conventions

This skill follows _lib/contract.md: the Vulnetix CLI is auto-installed by hooks, .vulnetix/capabilities.yaml is always present, every vulnetix vdb call is piped through a verified jq filter from _lib/jq/, independent calls run in parallel as concurrent Bash tool calls, and trailing follow-ups are limited to one line. See the contract for output style, memory write rules, and cooldowns.

Builds a copy-pasteable exploit-validation command. Best used after a fix to confirm the vulnerability path no longer responds. The user runs the command — this skill does not auto-execute.

Step 1: Load capabilities

Read .vulnetix/capabilities.yaml. Specifically binaries.nuclei, binaries.curl, binaries.docker.

Step 2: Fetch exploit content

vulnetix vdb exploits "$ARGUMENTS" -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/skills/_lib/jq/exploits.jq"
vulnetix vdb ai-assisted-exploits get "$ARGUMENTS" -o json | jq -f "${CLAUDE_PLUGIN_ROOT}/skills/_lib/jq/ai-list.jq"

Capture: PoC URLs, Metasploit module IDs, Nuclei template IDs, AI-assisted demo scripts.

Step 3: Fetch Nuclei template (preferred when binary present)

If binaries.nuclei: true:

vulnetix vdb nuclei get "$ARGUMENTS" --format yaml > .vulnetix/exploit-test/${ARGUMENTS}.yaml

Step 4: Render commands

Pick the highest-fidelity option available. Order:

1. Nuclei + binary present:

   nuclei -t .vulnetix/exploit-test/${ARGUMENTS}.yaml -u "$TARGET"
   

2. Metasploit module ID present and binaries.msfconsole (probe inline):

   msfconsole -q -x "use <module>; set RHOSTS <target>; run; exit"
   

3. AI-assisted Python demo script — write to .vulnetix/exploit-test/${ARGUMENTS}.py. Suggest:

   uv run --with requests .vulnetix/exploit-test/${ARGUMENTS}.py "$TARGET"
   

4. Curl-based PoC (last resort) — fetched from vdb exploits references.

Always include a --target placeholder if the user did not supply one. Refuse to run against any target without explicit user confirmation.

Step 5: Verdict guidance

After the user runs the command, expected outcomes:

• Pre-fix: vulnerability triggers (response shape varies by CVE — describe expected indicator)
• Post-fix: command returns benign / 404 / 400

Memory update

Append event: exploit-test-prepared with the chosen command class to the vuln entry.

Safety

• Never store credentials or tokens in .vulnetix/exploit-test/.
• Treat any provided target as authorized testing only — surface a one-line authorization reminder.

Edge cases & gotchas

• Authorisation is the user's responsibility. The skill surfaces an authorisation reminder; the LLM must NOT proceed if the user has not named an authorised target.
• Nuclei templates are downloaded into .vulnetix/exploit-test/<VULN_ID>.yaml. Review the template before running — some include intrusive payloads.
• Metasploit module hints reference module IDs, not module paths. Confirm the module is installed in your local msfconsole before invoking.
• AI-assisted Python demo scripts run with uv run --with requests — the script files live in .vulnetix/exploit-test/ and should never carry secrets.
• For some CVEs no Nuclei template exists; the skill falls back to a curl-based PoC pulled from vdb exploits references. Curl PoCs are typically least reliable.
• After running, the skill reads the user-described result and writes the verification outcome to memory — but only if the user explicitly reports back.