Command argument built with format!/concatenation

What it detects

A Command::new(...) argument is built with format!/string concatenation instead of a fixed literal, so untrusted input can reach the child process's argv (and a shell, if one is invoked, such as Command::new("sh").arg("-c")). Command::new does not itself go through a shell, so the risk is highest once a shell interpreter is in the chain; this heuristic flags the dynamic-argument shape either way as worth a review.

Why it matters

A Command whose argument is assembled with format!/string concatenation lets whatever produced that string influence exactly what the child process receives. Command::new does not itself invoke a shell, so plain argv entries are not shell-expanded, but the risk becomes concrete the moment the chain also invokes a shell interpreter (Command::new("sh").arg("-c").arg(...)) or passes the value to a program that interprets it (many CLIs, interpreters, or scripts do). Even without a shell in the mix, a dynamically built argument can still let an attacker influence which file gets read, which flag gets set, or which host gets contacted.

How to fix it

Prefer passing each user-controlled value as its own separate .arg(...) rather than interpolating it into a combined string, and avoid invoking a shell (sh -c, cmd /C) with a built string at all; call the target program directly with distinct arguments instead. If a shell is unavoidable, validate/allowlist the value strictly before it reaches the command, and treat any value that must not be attacker-controlled as a hard requirement, not a nice-to-have.

Related Security checks

• AUTHZ-003JWT expiration check disabledMedium
• AUTHZ-006Session cookie Secure flag disabledMedium
• AUTHZ-007Django session/CSRF cookie Secure disabledMedium