How to fix command injection in embedded firmware

Command injection (MITRE CWE-78 for the OS shell, CWE-77 for any product-specific command language) happens when firmware builds a command string from attacker-influenced input — a hostname, filename, SSID, or CLI argument — and passes it to a shell or command interpreter without neutralizing the characters that change its meaning. Both MITRE pages are read as of 2026-10-29. The fix is largely architectural: stop invoking a shell at all where a library call will do, and treat every remaining shell invocation as a parameterized call plus allowlist, not as a string to sanitize.

1. Detect

• Grep the firmware's web UI and CLI handlers (diagnostics, ping/traceroute, firmware upgrade, Wi-Fi/VPN configuration, log export) for calls into system(), popen(), exec*(), backticks, or an equivalent shell-invoking call in your language/SDK, and trace every argument back to its source.
• Flag any handler where a user-supplied string (device name, SSID, filename, email address) is concatenated into that command line rather than passed as a discrete, already-separated argument.
• Run static analysis with a rule set that maps to CWE-77/78 (most commercial and open-source SAST tools ship one), and treat a hit on firmware CLI/web-UI code as higher priority than the same hit in a build script, since the former is attacker-reachable over the network.
• Check CLI protocol parsers (not just the shell) for the CWE-77 case: a device's own management protocol or scripting language can carry the same risk if it does not separate commands from data.

2. Fix

1. Remove the shell call. OWASP's primary defense is to "avoid calling OS commands directly" and use a built-in library function instead — a filesystem function for mkdir/rm, a DNS resolver library for a ping-equivalent check, a native Wi-Fi configuration API instead of shelling out to wpa_cli. MITRE's own architecture-and-design mitigation for CWE-78 says the same: use library calls "rather than external processes to recreate the desired functionality."
2. If a shell call cannot be removed, parameterize it. Call the exec-family function with the command and each argument as separate list elements (so the OS invokes the binary directly, with no shell parsing step in between), rather than building one interpolated string that a shell then re-parses.
3. Add allowlist validation on top of parameterization, not instead of it: validate the command itself against a fixed allowlist, and validate each argument against a strict pattern (for example, a hostname regex) that rejects shell metacharacters (ampersand, pipe, semicolon, dollar sign, angle brackets, backtick, backslash, quotes and parentheses). OWASP is explicit that parameterization alone "doesn't replace argument validation" — the two layers address different attack paths.
4. Treat OS-specific escaping (e.g. escapeshellarg()) as a last resort only, when neither of the above is possible — it still allows an attacker to control which arguments reach an otherwise-fixed command.
5. Run with least privilege. If the firmware process that shells out does not need root, drop privileges first, so a missed case is contained rather than a full compromise.

3. Verify

• Re-run the original report's proof-of-concept input, and a short fuzz list of shell metacharacters, against the patched handler and confirm the command no longer executes unexpected behaviour.
• Add the test case to your regression suite so a future refactor cannot silently reintroduce the same concatenation pattern.
• Re-run SAST/static analysis across the firmware image and confirm the CWE-77/78 finding is gone, not just suppressed.

4. Ship an update

Build and sign a new firmware image carrying the fix, and distribute it through your normal secure-update channel (signed image, integrity check, rollback protection). See our firmware SBOM guide to confirm which shipped models and versions actually contain the vulnerable handler before you scope the release.

5. Disclose via PSIRT

Publish an advisory describing the affected products, versions and fix, following ISO/IEC 29147/30111's receive-verify-remediate-disclose shape — see our CVD process guide — and, for EU-market products, check whether the Cyber Resilience Act's 24-/72-hour reporting duty applies if the flaw was being actively exploited; see CRA 24h/72h reporting. If you do not have a standing PSIRT process yet, our PSIRT setup guide covers what a small device maker needs.

CISA's Secure by Design Pledge lists "reducing the prevalence of one or more vulnerability classes" as one of its seven measurable goals — command injection in a repeated code pattern (every diagnostic handler shelling out the same way) is a good candidate for exactly that kind of class-wide fix; see our CISA Secure by Design guide.

SoftWSP's device and firmware scanning flags command-injection-prone code paths like these directly in a firmware image, mapped to the specific CWE: see device & firmware security.

This guide summarises public MITRE CWE and OWASP guidance; it is not a substitute for a full source-code review and does not constitute legal advice.