php2shell排查清单：找出服务器上藏着的每一个PHP

php2shell 漏洞最麻烦的地方，是它藏在 PHP 解释器内核而不是任何应用代码里。多数站长听到消息后的反应是检查 WordPress 版本，可这个漏洞的影响面远远不止主力站点——凡是服务器上以任何形式运行 PHP 的东西都在射程内，而“想不起来它在那儿”的那些，才是最容易漏掉又被打穿的部分。这篇文章给你一份按顺序执行的排查清单。

先看影响有多大

安全研究者的分析显示：受影响代码最早出现在 PHP 5.4.0（2012 年发布），也就是说这个坑埋了 14 年；一共梳理出 5 条独立攻击链，其中针对 Apache mod_php 的一条无需任何应用层漏洞、未认证一个请求即可触发；按 W3Techs 口径约 78% 的网站运行 PHP，WordPress 一家就占 43%。修复版本为 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12，官方公告见 php.net。

清单第一步：盘点运行方式

把服务器上所有 PHP 运行模式列出来：FPM、Apache mod_php、php-cgi、LiteSpeed、FrankenPHP。重点标出 mod_php——它是风险最高的运行方式，一条链可以零条件利用。宝塔、cPanel 这类面板通常一个机器装了多个 PHP 版本，别只看当前站点在用的那个。

清单第二步：找出“副应用”

PHP 往往还藏在主力站点的阴影里：phpMyAdmin、Nextcloud、Roundcube、MediaWiki、WHMCS、OpenCart、Magento，以及各种运维工具自带的管理界面。这些应用平时没人访问、没人升级，恰恰是漏洞最爱待的地方。荷兰国家网络安全中心（NCSC-NL）维护了一份内嵌 PHP 的第三方软件清单（GitHub 上可查），照着对一遍你服务器上跑了哪些。

清单第三步：容器和镜像单独处理

Docker 用户注意：改运行中容器里的文件没有意义，容器重建后就打回原形。正确做法是更新基础镜像或拉取新的官方镜像，重新构建、重新部署，并在 CI 流程里固定住修复版本号。部署机、跳板机、内网测试机同样要过一遍，官方明确提醒不要只查公网可达的服务。

排查顺序与批量盘点

机器多的话别一台台手动查，按两个原则排序：先公网可达、后内网系统；先高权限环境（管理后台、数据库工具）、后低权限环境。盘点动作可以自动化——SSH 批量执行 php -v 列出所有版本，用配置管理工具或干脆一条 for 循环把几十台机器的版本号拉回来对表，五分钟的事，比事后排查入侵便宜太多。负载均衡后面的多台机器要逐台确认，别被其中一台升级成功假象骗了。

清单第四步：升级之后验证与查入侵

所有修复完成后重启常驻的 PHP 进程（FPM 重启、Apache 重启），确认实际运行的版本号已经变化。然后做入侵排查：翻访问日志找升级前的异常请求，看进程列表有没有陌生的常驻进程，检查关键文件有没有被篡改。要记住一个原则——打补丁修复的是漏洞，不会自动清除已经利用过漏洞的人。

写在最后

想深入研究攻击原理的，可以看研究者公开的完整分析仓库，5 条攻击链、检测规则和靶场都在里面（官方地址：github.com/ikow/php2shell-poc，MIT 许可，已 1500+ 星）。这次事件最大的教训其实只有一句：不知道自己服务器上跑着什么，比漏洞本身更危险。