Command Injection Risk Calculator

Score OS command injection risk from how the command is invoked, the argument validation, process privileges and runtime isolation.

About Command Injection Risk Calculator

The single biggest factor is whether a shell is involved at all: passing an argument array to execve removes the metacharacters that make injection possible, which is why it scores 1 while string concatenation scores 9. Impact is what the resulting shell inherits — the account's privileges and whatever the sandbox still lets it touch. Command injection converts directly into remote code execution, so the gap between a hardened container running as nobody and a root process on the host is the gap between a contained incident and a breach.

Formula

Command Injection Risk

Likelihood = mean(invocation style, argument validation, endpoint reachability, execution auditing); impact = mean(process privileges, runtime isolation).

invocation: 1 argument array … 9 shell string concatenation
isolation: 2 hardened container … 9 host with secrets

Worked example

With the default values below, Command Injection Risk Calculator returns Overall Risk Severity of High. Change any input above and every figure here is recalculated in your browser.

Inputs used

How the command is invokedone of No shell — execve with an argument array — 1, Shell with quoted allow-listed arguments — 3, Shell with an escaping helper — 6, Shell string built from user input — 9: Shell string built from user input — 9
Validation of the user-controlled argumentone of Strict regex allow-list — 1, Type and length checks — 4, Metacharacter deny-list — 7, None — 9: Metacharacter deny-list — 7
Reachability of the endpointone of Local CLI only — 2, Authenticated admin API — 5, Authenticated user API — 7, Unauthenticated endpoint — 9: Unauthenticated endpoint — 9
Process execution auditingone of EDR alerting on unexpected child processes — 1, Audit logs reviewed — 3, Logged without review — 8, Not logged — 9: Logged without review — 8
Privileges of the process accountone of Unprivileged with no capabilities — 3, Service account with application data access — 6, Sudo rights for specific commands — 7, Root — 9: Service account with application data access — 6
Runtime isolationone of Hardened container, read-only filesystem, seccomp — 2, Container with the default profile — 5, Shared virtual machine — 7, Host with mounted secrets — 9: Container with the default profile — 5

Results

Overall Risk Severity: High
Likelihood Score: 8.25 / 9
Impact Score: 5.50 / 9
Risk Score: 5.04 / 9
Suggested Remediation Window: 14 days
Highest-Value Fix: Drop the shell and pass arguments as an array to execve

Step by step

1Values used
2Command Injection Risk
3Overall Risk Severity= High
4Likelihood Score= 8.25 / 9
5Impact Score= 5.50 / 9
6Risk Score= 5.04 / 9
7Suggested Remediation Window= 14 days
8Highest-Value Fix= Drop the shell and pass arguments as an array to execve

Assumptions and limits

The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is Command Injection Risk calculated?

Likelihood = mean(invocation style, argument validation, endpoint reachability, execution auditing); impact = mean(process privileges, runtime isolation). The single biggest factor is whether a shell is involved at all: passing an argument array to execve removes the metacharacters that make injection possible, which is why it scores 1 while string concatenation scores 9. Impact is what the resulting shell inherits — the account's privileges and whatever the sandbox still lets it touch.

Why does Command Injection Risk matter?

Command injection converts directly into remote code execution, so the gap between a hardened container running as nobody and a root process on the host is the gap between a contained incident and a breach.

What values do I need to enter?

This calculator takes 6 inputs: How the command is invoked, Validation of the user-controlled argument, Reachability of the endpoint, Process execution auditing, Privileges of the process account, Runtime isolation. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Is escaping the input a valid fix?

It is a fallback, not a fix. Escaping has to be correct for the exact shell, quoting state and locale, and one missed case restores full injection. Removing the shell removes the whole vulnerability class, and every mainstream language offers an argument-array API for it.