A service starts external operating-system programs at several dozen call sites, and at one of them an attacker can influence what gets launched. Concretely, what does the attacker gain? And why is a call site that returns nothing to the caller no safer than one that prints the program's output?

## The yield is a principal, not a payload When attacker-influenced data reaches a call that starts an operating-system process, the attacker does not gain "one more command." They gain the ability to run programs **with the exact identity of the process that made the call**. Everything that process is trusted with becomes theirs. Naming that inventory concretely is what separates a candidate who has handled a real incident from one who says "remote code execution" and stops. - **Identity and capabilities.** Which OS account runs it, which privileges or container capabilities it holds, whether it can write to the filesystem it runs on. - **Environment.** Process environments are where deployments put secrets: database URLs with passwords, API tokens, signing keys, registry and build credentials. A launcher process typically also *passes* that environment down to whatever it starts. - **Files.** Configuration, private keys, session-signing material, source and templates, uploaded content that the web tier serves back to users, mounted volumes, other tenants' data. - **Network position.** Often the real prize. The process sits inside the perimeter, holds live database connections, can reach internal services that trust the network, and — in most hosted environments — can reach a link-local credential-issuing endpoint that hands short-lived platform credentials to whatever asks from that host. - **Lifetime.** Scheduled entries, startup scripts, a modified deployment artefact or a poisoned dependency cache turn a one-shot execution into persistence. The progression is **read → tamper → escalate → persist → pivot**, and each step is bounded by the principal, not by the feature that was abused. A thumbnail generator and a licence-check helper yield exactly the same thing if they run as the same account. ## Why "nothing came back" proves nothing A **blind** sink returns an empty body, a fixed message, or the same status regardless of what the launched program did. Teams routinely down-rank these because testing produced no visible output. That is a statement about the tester's convenience, not about exploitability. An attacker confirms execution through side channels: - **Timing.** Anything that costs measurable wall-clock time turns a boolean into an observable. Repeat it and you have an oracle that can read a secret one comparison at a time. - **Out-of-band DNS.** A name lookup for an attacker-controlled domain reaches the attacker's authoritative resolver. DNS frequently escapes egress policy because the workload resolves through an internal resolver that forwards outward, so it works in environments where direct HTTP egress is blocked. Data rides out in the labels. - **Outbound HTTP.** Where egress is open, a request straight back to the attacker both confirms and exfiltrates, and can pull a second stage. - **Second-order artefacts.** Writing a file into a directory the web tier serves, or a row that a later page renders, gives a response channel with no direct one. Bandwidth is low, which does not matter: credentials, keys and tokens are small. The operational rule is that triage follows **taint into the launch site** — which arguments are built from data any external party can influence, directly or through storage — and never the presence of reflection. ## The counter-intuitive inversion Request handlers attract attention: reviewed often, run unprivileged, containerised, egress-restricted. Meanwhile the nightly importer, the report generator, the media pipeline and the deployment tool run under broad service accounts, sometimes on hosts with wide grants or a mounted management socket, and consume a queue, a table or an uploaded file that any registered user can write to. So the batch job frequently outranks the web handler. Two properties compound: its **privilege** is high, and its input is **second-order** — stored today, interpolated into a command line next Sunday — which means a scanner that only fuzzes the HTTP surface never sees it and the latency between injection and execution reads, falsely, as safety. Also rank the *site*, not the parameter: one stored value can flow into two launchers with very different principals, and the severity is set by the worse one. ## Containment moves the ranking, never the verdict Worthwhile controls around process-launching code: a dedicated unprivileged account; a read-only root filesystem with a small scratch area mounted without execute permission; drop every capability not needed; default-deny outbound with an explicit allow-list (this blocks both second-stage download and exfiltration); block the local credential-issuing endpoint; strip secrets from the environment of any process that launches subprocesses; hard timeouts and resource limits. What these do is shrink the principal, and therefore shrink the ranking. What they never do is stop the attacker from altering the structure of what runs — the defect is intact, and any drift (a capability re-added, an egress rule loosened, a secret moved back into the environment) silently re-inflates severity with no code change. Present containment as a multiplier on impact, never as the fix; the fix lives on the defence ladder — **structural separation > escaping/transformation > validation > detection** — which the other questions on this topic cover. On ranking across a whole codebase, the generic reachability-by-privilege-by-sensitivity exercise applies here as it does anywhere; the only tier-specific refinement is that for process launchers privilege usually dominates and reachability is very often second-order.