The clearest warning signs are direct use of user input inside eval, exec, os.system, or subprocess calls built from concatenated strings. Risk also rises when code accepts free-form expressions, command fragments, or operating parameters without validation. If the application depends on shell parsing to separate trusted and untrusted data, it is likely exposing a command injection path.
Warning Signs in the Code Path
The most reliable clue is a flow that lets attacker-controlled text reach a command interpreter with little or no boundary between data and executable syntax. In Python, that often shows up when input is passed into functions that can invoke a shell, or when strings are assembled into commands instead of using structured arguments. The risk is highest when the code assumes the shell will safely “figure out” what is trusted versus untrusted.
Other warning signs include accepting free-form command fragments, option flags, filenames, or expressions from users without tight validation, allowlisting, or escaping. Even when the code is not obviously launching a shell, a vulnerable pattern can still exist if the application hands untrusted text to OWASP Top 10-style input handling weaknesses or builds operating-system commands from concatenated pieces. The practical test is simple: if the code path can change process behaviour rather than just data values, treat it as suspect.
For Python-specific examples, look for wrappers around os.system, os.popen, subprocess with shell mode enabled, and any indirect execution path that reaches eval or exec. Unsafe command construction often pairs with missing validation on user-supplied parameters, which makes the vulnerability easier to trigger and harder to contain. In serious cases, the same flaw can become a full remote code execution path.
What Usually Makes the Vulnerability Real
A command injection issue is not just “user input exists.” It becomes real when that input is interpreted by a shell or execution context that supports metacharacters, chaining, substitution, quoting rules, or command separators. If the developer is depending on string sanitisation alone, rather than eliminating shell interpretation or constraining the allowed values, the code is usually fragile. That fragility matters because shell parsing is both powerful and easy to misjudge.
The most common structural mistakes are concatenating commands, passing whole command lines instead of argument lists, and mixing trusted and untrusted fields in the same string. A second red flag is any logic that permits arbitrary expressions or partially structured command text because “power users” need flexibility. That convenience usually creates an execution surface that is wider than the application really needs.
Python projects also become vulnerable when they treat convenience APIs as harmless shortcuts. eval and exec are especially dangerous when the source is not fully controlled, but even subprocess usage can be unsafe when shell expansion is enabled or when the code builds a command through concatenation. In practice, the question is not whether the function is “for commands,” but whether untrusted input can influence syntax rather than just value.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Code injection often pairs with exposed secrets that expand attacker impact. |
| NHI-02 — Overprivileged Non-Human Identities | Injected commands are more damaging when runtime identities have broad privileges. | |
| Recommendation — Remove hardcoded secrets from code paths that build or execute commands. Reduce execution privileges for processes that can reach shell or subprocess calls. | ||
| CIS Controls v8 | CIS 16 — Application Software Security | This subject is an application input-to-execution flaw that secure coding controls should prevent. |
| Recommendation — Validate inputs and avoid shell execution patterns in application code. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Python command injection maps directly to abuse of command interpreters. |
| Recommendation — Hunt for attacker use of command interpreters triggered through injected input. | ||
Practitioner Guidance
What to verify: Trace every path from user input to process creation and check whether the final handoff is a structured argument list or a shell-parsed string. If the code uses free-form parameters, confirm whether each field is allowlisted rather than merely escaped, because escaping alone is often brittle under edge cases.
Common mistake: Teams often focus on whether the input is “sanitised” and ignore whether the shell is still in the execution path. That is the wrong confidence signal. If the application can achieve the same task without shell interpretation, the safer design is to remove the shell dependency rather than harden a risky one.
Practitioner takeaway: The strongest indicator of command injection risk is any design that lets untrusted text influence command syntax, not just command values. If you can map that boundary clearly in code review, you can usually tell very quickly whether the implementation is robust or one quoting bug away from compromise.
Related resources from NHI Mgmt Group
- What are the signs that an application has weak input handling and may be vulnerable to code injection or XSS?
- What are the signs that a PHP application may be vulnerable to command injection?
- What are the signs that a Node.js application is vulnerable to command injection?
- What breaks when a management platform is vulnerable to command injection?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
