---
{
  "title": "OS command injection",
  "summary": "OS command injection occurs when untrusted input changes a system command an application executes.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: OS Command Injection Defense",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

OS command injection occurs when untrusted input changes a system command an application executes. Shell parsing introduces metacharacters and expansion rules that make string concatenation hazardous. Prefer a library operation that performs the task without launching a shell or external command.

## A practical example

An image service needs to inspect a file. It uses a maintained library rather than constructing a shell command from the uploaded filename. If an external process is unavoidable, the service fixes the executable and validates each permitted argument.

## What to check

Remove unnecessary command execution, use APIs that pass arguments separately, reject unsupported options and values, and run the process with minimal permissions. Include filenames and other indirectly supplied values in the review.

## A common pitfall

Avoiding shell metacharacters does not eliminate argument injection. An attacker-controlled value might still become an option that changes a trusted program's behavior.

## Think it through

Does passing arguments separately make every argument safe?

**Answer:** No. It avoids shell interpretation but the program still parses options and values, which require validation.

## Separate shell interpretation from program behavior

Consider a fictional document service that generates thumbnails. There are two parsers to think about: a shell, if the application invokes one, and the thumbnail program's own argument parser. Removing the shell closes one route by which a filename could become command syntax. It does not decide whether the external program should accept that filename as an option or access that path.

A safer design may avoid the subprocess entirely through a maintained image library. If a subprocess is needed, keep the executable and supported options under application control. Place untrusted filenames in a controlled working area, constrain the accepted formats, and verify the tool's documented way of separating options from operands. Treat configuration and environment variables as part of the process's effective input.

Privileges determine the consequence of a mistake. A thumbnail worker that can read customer exports or write deployment files has more authority than the image task requires. Isolation, restricted filesystem access, resource limits, and timeouts reduce that unnecessary authority. They complement correct argument handling rather than making unsafe command construction acceptable.

## Inspect a harmless conversion workflow

In a local training application, list the inputs to a conversion task: filename, format, dimensions, working directory, and executable path. Mark which are selected by the server and which originate with a user. Then explain what happens to a filename beginning with a dash and an unsupported output format, using dummy files only.

The review outcome should identify where each input is interpreted and why its permitted form is sufficient. This is more informative than claiming a string is 'escaped.' It also exposes indirect inputs, such as an archive filename or a partner-supplied path, that might otherwise be missed.

## Related concepts

- [[injection]]
- [[input-validation]]
- [[least-privilege]]