AI-Generated OS Command Injection Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits code that builds a shell command or invokes an external program. The goal is to stop a generated integration, build script, or file-processing feature from shipping a command injection hole because it works for the expected input and looks like ordinary subprocess code.

This is a review policy, not a command-injection tutorial. It tells reviewers what must be true about a generated change's process-invocation API, input validation, and privilege level before the change is safe to merge.

Review Inputs

Collect enough context to know what the process call actually does and where its inputs come from.

• Every place the change builds a command string or invokes a subprocess, child process, or external program.
• Which parts of the command (the program name, flags, or arguments) come from user input, an uploaded file, configuration, or another external system, versus values hardcoded by the developer.
• Whether the call goes through a shell (a single string parsed by /bin/sh or cmd.exe) or the array/list form that bypasses shell parsing.
• Whether a built-in library function could accomplish the same task without invoking an external program at all.

Avoid-The-Shell Rules

• The strongest defense is not calling an OS command at all: prefer a language or framework library function (filesystem, archive, image, network libraries) over shelling out to an equivalent CLI tool.
• When an external program is genuinely required, use the array/list form of the process API so the program and its arguments are passed directly to the OS without a shell interpreting metacharacters: subprocess.run([...], shell=False) in Python, execFile/spawn with an argument array in Node.js, ProcessBuilder with separate arguments in Java.
• Flag shell=True, os.system, exec/execSync given a single string, backticks, or any API that hands a whole command line to a shell, whenever any part of that line is not a hardcoded literal.
• Remember the language-specific distinction: some "exec" APIs (for example Java's Runtime.exec given a string) split on whitespace and invoke the first token directly without shell metacharacter support, while others genuinely invoke a shell — verify which behavior the specific API in the diff actually has before treating it as safe.

Input Validation And Argument Injection Rules

• Validate the command itself against an allowlist of permitted programs; never let user input choose which program to run.
• Validate each argument with positive/allowlist validation — an allowed character set and a maximum length — rather than trying to deny a list of "dangerous" characters (& | ; $ > < \ \ ! ' " ( )` and whitespace are common shell metacharacters, but a denylist is easy to miss a variant of).
• Treat argument injection as a real risk even for a fixed command name: an attacker who controls an argument value can still pass an unexpected flag (for example turning a data argument into --help, --output=..., or a second target) and change the program's behavior.
• Where the target program and library support it, use a -- end-of-options delimiter (or the equivalent convention) so attacker-controlled values cannot be interpreted as flags.
• Escaping functions (for example PHP's escapeshellarg()) reduce risk but do not fully close argument injection; prefer array-form APIs and allowlist validation as the primary defenses, with escaping only as an additional layer when shelling out cannot be avoided at all.

Least-Privilege Rules

• Run the process with the lowest privileges that accomplish the task, not with the privileges of a more powerful parent process (root, an admin service account, or a broad cloud IAM role).
• Prefer a dedicated, isolated account or sandbox for a single narrow task over reusing a general-purpose privileged account for subprocess work.
• Assume any successful injection will run with whatever privilege the process already has; least privilege limits the blast radius even when every other defense fails.

Merge Blockers

Block merge when any of these is true.

• Untrusted input (user input, uploaded file content/name, external API response) reaches a shell-parsed command string (shell=True, os.system, string-form exec, backticks) without going through the array-form API instead.
• A built-in library function could replace the external-program call entirely and was not used, with no documented reason for shelling out.
• Command or argument values are validated with a denylist of "bad" characters instead of positive/allowlist validation.
• A fixed command name is invoked with attacker-controlled arguments and no consideration of argument injection (unexpected flags, extra targets).
• The subprocess runs with elevated or inherited privileges broader than the task requires.

Review Checklist

• {"task": "Shell avoided where possible", "description": "A library function replaces the external-program call wherever one exists"}
• {"task": "Array-form API used", "description": "Unavoidable process calls use the array/list form, not a shell-parsed command string"}
• {"task": "Allowlist validation", "description": "Commands and arguments are validated against an allowlist, not a denylist of dangerous characters"}
• {"task": "Argument injection considered", "description": "Attacker-controlled argument values can't be interpreted as unexpected flags, even for a fixed command"}
• {"task": "Least privilege", "description": "The subprocess runs with the minimum privilege needed, not an inherited elevated account"}
• {"task": "No secret leakage", "description": "Subprocess stdout/stderr isn't logged in a way that could echo back credentials or sensitive paths"}

AI Review Rules

AI assistants can write and review process-invocation code, but they should show their evidence.

• Ask the assistant to list every place the change invokes an external program or builds a command string, and what API it uses for each.
• Require the assistant to state whether each call goes through a shell or uses the array-form API, and to justify shelling out when a library alternative exists.
• Have the assistant identify which parts of each command are attacker- or externally-influenced, and how those specific values are validated.
• Do not let the assistant claim an escaping function alone makes a shell-parsed call safe; require the array-form API plus validation.
• Re-run review after any change to how a command or its arguments are constructed, or to the account/privileges the process runs under.

Troubleshooting

• Switching to the array-form API breaks a command that relied on shell features (globbing, pipes, redirection): implement the specific shell feature in code (expand the glob yourself, chain calls explicitly) rather than reintroducing a shell-parsed string for convenience.
• Allowlist validation rejects a legitimate argument: widen the allowlist pattern deliberately and re-test with known-bad payloads, rather than switching to a denylist or removing validation.
• A fixed-command call is flagged even though the command name can't change: check whether any argument is attacker-influenced; if so, this is legitimate argument-injection risk even with a hardcoded command name.
• The subprocess needs elevated access for one specific operation: scope the elevation to that one operation (a narrowly-privileged helper, a capability, or a policy) instead of running the whole process with broad elevated privileges.

Duplicate And History Check

Before adding a new subprocess call, confirm the codebase does not already have a shared wrapper or library helper for this task. A generated change that shells out next to an existing safe wrapper, or reintroduces a string-form command where a validated array-form helper already exists, should be treated as suspicious — check whether the existing mechanism was simply not reused before adding a second, parallel, and possibly unsafe one.

Reference

Sources

• OWASP OS Command Injection Defense Cheat Sheet
• CWE-78: Improper Neutralization of Special Elements used in an OS Command
• OWASP Command Injection attack reference
• Node.js child_process documentation
• Python subprocess documentation — Security Considerations

• Source repositorygithub.com 2026-07-16T13:01:56+00:00
• Documentationcheatsheetseries.owasp.org
• Submitted by lourincedaging0-commits2026-07-15