php命令注入漏洞排查需验证输入可控、拼接发生、命令落地三条件，重点审计exec等危险函数及反引号用法，检查过滤有效性，回溯输入来源，结合日志与动态监控确认执行行为。
排查 PHP 网站的命令注入漏洞，核心是确认“用户输入是否未经处理就拼进了系统命令并被执行”。这不是靠猜，而是沿着执行链路逐层验证三个刚性条件：输入可控、拼接发生、命令落地。
快速定位高危函数和调用点
先从代码里搜这些危险函数（大小写敏感，注意别名）：
- exec、shell_exec、system、passthru、popen、proc_open —— 直接执行命令的主力
- `反引号` —— 容易被忽略的命令执行语法
- pcntl_exec —— 常见于后台服务类脚本，也属高危
找到调用位置后，重点看参数是否包含任何外部输入变量，比如 $_GET、$_POST、$_SERVER、$_COOKIE 或文件读取、数据库查询结果等间接来源。哪怕只拼了一个参数，也要拉出来细查。
检查输入是否真正被过滤或转义
看到用了 escapeshellarg() 或 escapeshellcmd() 不代表安全。常见误区包括：
- 只对部分参数过滤，其余仍直拼
- 先过滤再拼接，但拼接后又做了字符串替换（如 str_replace），反而破坏了转义效果
- 两个函数混用且顺序错乱，导致单引号逃逸（例如输入
' -oG out.txt '可能绕过） - 过滤前已做 trim()、urldecode() 等操作，引入额外字符
建议直接在测试环境构造典型 payload 验证，比如填入 127.0.0.1; id 或 127.0.0.1 | cat /etc/passwd，观察回显或日志是否有命令执行痕迹。
回溯输入来源与上下文边界
一个变量看似“干净”，可能只是中间态。要顺藤摸瓜查清它的完整生命周期：
- 原始来源是哪里？是表单提交、URL 参数、HTTP 头、还是缓存/数据库读取？
- 中间是否经过 json_decode、unserialize、base64_decode 等解码操作？这些都可能还原出恶意内容
- 是否在 if/else 分支中被不同方式拼接？有些路径可能绕过过滤逻辑
- 有没有使用 extract()、parse_str() 这类动态赋值函数？它们会把任意键名变成变量，极易扩大攻击面
特别注意框架封装场景：比如 Laravel 的 Artisan 命令、ThinkPHP 的命令行模块，表面看不调用 shell 函数，但底层若拼接参数并执行，同样存在风险。
借助日志与动态验证收口
静态代码审计容易漏，必须结合运行时证据：
- 开启 PHP 错误日志，搜索
Warning: exec()、sh: command not found等线索，异常报错常暴露拼接逻辑 - 在关键命令执行前加日志，记录原始输入、过滤后值、最终拼出的命令字符串（脱敏敏感字段）
- 用 strace 或 process monitor 观察 Web 进程是否真实 fork 出了
ping、curl、nmap等子进程 - 检查 Web 服务器访问日志中是否存在含分号、管道符、重定向符（
;|>）的请求参数
只要有一处满足“输入→拼接→执行”闭环，就必须修复，不能因其他地方有防护就掉以轻心。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
