Payloads.

Command Injection

Executing arbitrary commands inside the vulnerable application — the server runs your input as part of an OS command. Wherever user input touches a shell (ping, convert, zip, nslookup), the shell metacharacters become your API.

1. 01

   Find features that shell out

   Ping tools, file converters, PDF generators, DNS lookups — anything wrapping a CLI binary with user input.

2. 02

   Append separators

   Try ; id, | id, && id and `id` after your input. Output appearing in the page (or an error) = injection.

3. 03

   Test blind execution

   No output? Use sleep 10 and measure response time, or trigger an out-of-band DNS hit to a domain you control — the callback proves execution without reflection.

4. 04

   Try argument injection

   When separators are filtered, inject INTO an existing flag — e.g. ssh -oProxyCommand or psql -o both execute commands via their own options. This works even when ; | & are fully blocked.

5. 05

   Keep it harmless

   id and whoami prove execution; stop there and write the report.

• 01Semicolons stripped? Pipes, &&, ||, newlines (%0a), and backticks each reach the shell differently.
• 02All separators blocked? Argument injection — abuse the wrapped binary's own flags (-oProxyCommand for ssh, --proxy for curl).
• 03Quotes filtered? $IFS replaces spaces; brace expansion {a,b} forms arguments without spaces.
• 04Blind with no output? Timing (sleep 10) and DNS/HTTP out-of-band callbacks prove execution regardless of reflection.

1. 01Full server control — commands run as the application user.
2. 02Data exfiltration — read configs, source, databases directly off disk.
3. 03Pivot into the network — the server's position is your foothold.
4. 04Persistence potential — the finding is critical even when you don't demonstrate it.