Common warning signs include use of exec, system, or passthru with strings built from request data, especially GET parameters, POST bodies, headers, cookies, or uploaded file content. Another signal is code that accepts freeform values without validation before passing them to a shell. If the command changes based on user input, the application deserves immediate review.
How command injection usually shows up in PHP code
The clearest warning sign is any path where application data becomes part of a shell command. That risk is highest when a developer concatenates request-controlled values into a command string and then hands it to OWASP Top 10-style input handling failures are visible in the surrounding code, such as missing validation, weak allowlists, or ad hoc sanitisation.
In PHP, the danger is not limited to obvious command wrappers. Review code that routes user-controlled values into functions such as exec, system, passthru, shell_exec, popen, proc_open, or backtick execution, especially when the input is pulled from GET, POST, cookies, headers, file uploads, or JSON bodies and then interpolated into a shell command.
- Commands built by string concatenation instead of fixed arguments
- Freeform parameters accepted without allowlist validation
- Output from one command reused in a second shell call
- Developer comments that mention “temporary” shell usage for convenience
A useful review question is whether the command would still be safe if the input contained shell metacharacters, spaces, quotes, command separators, or pipeline characters. If the answer depends on the input “being well behaved”, the code deserves immediate scrutiny.
Why the execution context matters more than the function name
Not every use of a shell helper is equally risky. Some applications call external programs with fixed arguments, while others construct dynamic commands from partially trusted data. The security problem appears when the shell gets to interpret the string, because then application logic and operating-system parsing become the same trust boundary.
That boundary often breaks in three places: the developer assumes filtering is enough, the application trusts a field that was never intended for command construction, or the code mixes user input with file paths, options, or environment-like values. A path parameter can become a command option, a filename can become a shell fragment, and a harmless-looking search term can become an entire second command.
For readers who want the broader testing angle, the OWASP Web Security Testing Guide is useful for turning those code-review clues into repeatable verification steps, while OWASP ASVS gives a stronger baseline for input validation and command-handling expectations in application assurance work.
Another practical signal is inconsistency: if one execution path uses fixed arguments and another path builds a string from request data, the unsafe path is usually the one that slips through review. command injection is frequently a narrow, localised defect, but one vulnerable endpoint is enough to create a full server compromise path.
What a practical review should prioritise in PHP
Start with any endpoint that can influence file names, report generation, maintenance actions, image conversion, archive handling, network utilities, or integration scripts. Those features often feel “administrative”, which makes teams more willing to allow shell access without the same level of scrutiny they would apply to ordinary user-facing logic.
What to verify: confirm whether the command can be expressed without a shell at all, whether arguments are passed as separate values rather than one interpolated string, and whether the allowed input space can be reduced to a small fixed set. If the code needs the shell, verify that the input is constrained before command construction, not after.
Common mistake: treating escaping as a complete fix. Escaping can reduce risk, but it is not a substitute for removing shell dependence, especially when business logic later expands the command string or reuses the same value in a second context.
For deeper defensive reading, OWASP Cheat Sheet Series is the best navigation aid for safe input handling and command construction patterns, and OWASP SAMM helps teams treat this as a repeatable secure-development practice rather than a one-off code fix.
Practitioner takeaway: the strongest sign of command injection risk is not the presence of a shell call by itself, but the combination of shell execution, request influence, and weak input restriction. When those three appear together, assume the code needs immediate review, not later tuning.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Safe coding controls apply to input handling and command construction in PHP apps. |
| Recommendation — Enforce secure coding and review rules for any code that invokes system commands. | ||
Related resources from NHI Mgmt Group
- What are the signs that an application may be vulnerable to SQL injection?
- What are the signs that an application has weak input handling and may be vulnerable to code injection or XSS?
- What breaks when a management platform is vulnerable to command injection?
- What are the signs that prompt injection defenses are failing in a gen AI application?
