exploit-test

Generate a runnable exploit-validation command (Nuclei template, Metasploit module hint, AI-assisted Python script, or curl-based PoC) against a user-specified authorised target.

Arguments: <vuln-id> [--target URL]

Grants: Bash(vulnetix:*) Read Grep Glob Bash(nuclei:*)

Typically followed by: verify-fix

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 detection-rules.

Conventions

Follows skills/_lib/contract.md. In short: use the vulnetix_* MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes.

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
vulnetix vdb ai-assisted-exploits get "$ARGUMENTS" -o json

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.