Command and argument injection

An application may ask another program to resize an image or produce a report. The important question is how it passes the request. A shell interprets command language. A separate program interprets its own arguments. Either can misunderstand untrusted data when the interface fails to preserve the intended meaning.

Two different boundaries

Shell injection happens when data becomes shell syntax. Argument injection can occur without any shell: a value may be interpreted as an option or change the target program’s behavior. That can alter an existing operation without starting an additional process.

An argument array avoids one kind of string construction, but does not make all values acceptable. The chosen executable, option set, filenames, and program-specific parsing still need an explicit contract. Platform APIs differ; verify the guarantees of the actual runtime rather than assuming that all process-launching interfaces behave like POSIX.

Scenario: the photo service

The service accepts a photo and a choice of small or large thumbnail. A library API may avoid launching a process entirely. If an external converter is necessary, the server chooses the executable and maps those two choices to fixed options. User data remains separate, with type, size, and location restrictions.

A program’s end-of-options marker can help when supported, but it is not universal and does not validate the resulting filename or content. Choosing a library also leaves ordinary library vulnerabilities, file handling, and resource consumption to manage.

Authority belongs to the execution context

The program normally inherits a service security context unless a broker, impersonation, or privilege change alters it. This may include groups, capabilities, sandbox restrictions, mounted data, and available credentials. A container does not automatically imply either isolation failure or unrestricted host access.

The reviewer can learn these properties from service configuration and approved deployment evidence. No command execution demonstration is required merely to explain which privileges should exist.

Evidence and prevention

A delay or error is not by itself proof of command execution. Review the call path and diagnostics available to the owner. Record confirmed behavior separately from potential access.

Prefer an appropriate library; otherwise use a controlled executable and structured arguments with positive validation. Restrict file and network access, and bound time, memory, and output. Logging should retain useful operation identifiers and failure reasons while redacting secrets and sensitive arguments. Logging every argument verbatim can create a second exposure.

The durable lesson is to remove unnecessary interpreters and constrain the remaining ones, not to build a growing blacklist of characters.

Review a thumbnail contract

The fictional photo team wants exactly two thumbnail sizes. Its proposed design uses a fixed converter selected by the server, launches it through a structured argument interface without a shell, and accepts a free-form options field from the request. The worker can read its assigned input and write to a temporary output area.

Removing the shell addresses shell-language interpretation, but the free-form field still delegates converter behavior to the caller. The feature needs a size choice, not arbitrary program options. Map the two supported choices to server-owned settings and reject choices outside that feature contract. Also check the specific runtime’s process-launch guarantees.

PredictThe team replaces the free-form field with small and large. Is that sufficient to approve the worker’s whole design?

It addresses the stated option-selection gap. Input decoding, output location, effective service authority, timeout, memory use, and cleanup still need their own evidence. The correction does not establish those separate properties.

Consider supplied acceptance limits: each job must finish within five seconds, use at most 128 MiB of worker memory, and leave no output after a failed job. An owner-run validation record reports four seconds, 96 MiB, and an abandoned output file. Timing and memory meet their limits; failed-job cleanup does not. A successful limit in one dimension cannot compensate for another unmet requirement.

A reusable library could remove process launching, but it would still decode untrusted input and consume resources. Compare the interfaces by the work they must perform and the authority they need, rather than treating either implementation label as a guarantee.

The reviewer can write a concrete result from these supplied records: restrict option selection, retain the bounded service identity, and require evidence that failure cleanup meets the contract. Nothing in this packet establishes that an unauthorized command was executed.