php2shell-checker 使用笔记:让 Codex 帮你检查 PHP2Shell 漏洞

前几天,PHP出现了CVE-2026-109618、CVE-2026-109619这两个非常严重的漏洞,均可能在特定条件下被未经身份验证的远程攻击者利用,实现远程代码执行。该漏洞位于PHP核心层,不依赖某个特定CMS,所以,WordPress、Typecho、Drupal、Laravel、phpMyAdmin等使用受影响PHP版本运行环境的系统均需进行排查。

然后今天我看到 OpenAI 提供了一个技能叫 php2shell-checker。对于自己维护 PHP 网站的站长来说,太方便了!

它主要通过网站响应头里的 PHP 版本,或者服务器上的实际安装信息,判断是否需要关注 PHP2Shell 相关漏洞。工具不会发送漏洞利用请求,也不会尝试拿服务器权限。

项目地址:
https://github.com/openai/php2shell-checker

最方便的方法:直接交给 Codex

在 Codex 中输入项目提供的安装提示词:

$skill-installer install both skills from https://github.com/openai/php2shell-checker

项目提供两项技能:phpcheck-url 用于检查网站对外显示的 PHP 版本;phpcheck-server 用于有服务器访问权限时核查实际安装情况。

如果只是想先检查一下网站,可以输入:

$phpcheck-url check https://你的域名

如果 Codex 已经可以访问你的服务器,我更倾向于直接让它检查服务端:

$phpcheck-server 检查我的网站实际使用的 PHP 是否已修复 PHP2Shell 相关漏洞。请确认提供服务的 PHP-FPM、Apache 模块或容器,核对软件包完整版本、厂商公告和运行进程。先只检查,列出依据和处理建议,不要修改配置或升级。

服务端检查有个容易忽略的地方:终端里执行 php -v 看到的版本,可能和网站实际使用的 PHP 不一样。服务器技能会要求核对真正提供服务的安装位置、软件包,以及更新后工作进程是否重启。

不用 Codex,也可以直接运行

电脑上准备好 Git 和 Node.js,在终端依次执行:

git clone https://github.com/openai/php2shell-checker.git
cd php2shell-checker
node phpcheck.js "https://你的域名"

需要方便脚本读取的 JSON 结果,就加上:

node phpcheck.js "https://你的域名" --json

返回结果主要有三种:

结果 应该怎么理解
OK 对外显示的版本达到工具记录的上游修复版本
POTENTIALLY VULNERABLE 版本落在风险范围,需要进一步核查
UNKNOWN 版本被隐藏、无法识别,或者检查失败

URL 检查只读取 X-Powered-By、Server 等响应头,不会分析网页内容,也不会自动跟随跳转,所以最好直接填写网站最终使用的 HTTPS 地址。

检测结果别直接当成安全结论

网站隐藏了 PHP 版本,显示 UNKNOWN 很正常,不能据此判断有没有漏洞。即使返回 OK,也只是响应头中的版本符合条件,没有验证服务器实际运行的程序。

反过来,版本偏旧也不一定代表没修复。有些 Linux 发行版会保留原来的 PHP 主版本号,把安全补丁回移进去,这就需要结合软件包完整版本和厂商公告判断。

截至今天也就是2026 年 10 月 26 日,PHP 官方针对这两项漏洞公布的上游修复版本是 8.2.35、8.3.36、8.4.27、8.5.12。另外,10 月 23 日官方又补充了 Session 上传进度相关风险说明,所以达到这些版本,也不代表后续公告可以忽略。

我的理解是,这个项目适合用来快速筛查和辅助核查。只有网址就先查响应头,有服务器权限就继续查实际软件包和运行进程,这样结果才更有参考价值。

刚刚让 codex 安装 php2shell-checker 后对服务器进行了检查,结果显示:

已通过 Windows 原生 OpenSSH 完成只读检查。当前网站使用的 PHP 应判定为存在 PHP2Shell 潜在漏洞,未达到厂商针对两个 CVE 提供的更新版本。 未运行利用探测,因此不声称已验证可利用。

检查时间:2026-10-26 14:39(北京时间)。未修改配置、升级软件或重启服务。

核查依据如下:

项目 实际结果
操作系统 Alibaba Cloud Linux 3,UPDATE_ID=9
站点 heqianwei.com、ihacksoft.com、techzhi.com,以及各自的 www 域名
服务链路 Nginx 配置将 PHP 请求转发至 /run/php-fpm/www.sock;该监听套接字由运行中的 FPM 进程持有
PHP 服务方式 宿主机 php-fpm.service,www 池;没有发现这些站点使用 Apache 模块或容器提供 PHP
实际二进制 /usr/sbin/php-fpm,PHP 7.4.33
完整软件包版本 php-fpm 0:7.4.33-15.el8.remi.x86_64
软件包提供方 Remi;启用的模块流为 php:remi-7.4
关联软件包 php-common、php-cli 及已安装的 PHP 扩展同为 7.4.33-15.el8.remi
运行进程 主进程 PID 212531,2026-05-08 启动;检查时共 36 个 FPM 进程
运行文件核对 全部 FPM 进程的可执行文件 SHA-256 与磁盘二进制一致;RPM 校验未报告该二进制内容变化

厂商公告与版本比较

Remi 的 PHP 7.4 公告明确指出,7.4.33-31 包含针对 CVE-2026-109618、CVE-2026-109619 的缓解内容;对应 EL8 软件包为:

php-fpm-7.4.33-31.module_php.7.4.el8.remi.x86_64

服务器现有仓库缓存也列出了这个包。使用 RPM 原生版本比较,当前 -15.el8.remi 低于该版本,返回值为 -1。这里采用的是实际提供方 Remi 的依据,没有套用 RHEL、Ubuntu 或 Debian 的修复门槛。Remi 公告、具体软件包记录

需要区分的是:Remi 对旧版 7.4 使用了“mitigation”措辞,不能据此承诺更新到 -31 就等同于受支持分支的完整修复。PHP 官方建议所有提供 Web 请求服务的 PHP 安装更新;已公布修复版本包括 8.2.35、8.3.36、8.4.27、8.5.12。PHP 官方公告

建议按以下顺序处理:

  1. 优先安排兼容性测试,迁移到仍受支持且包含修复的 PHP 分支,同时检查三个站点及扩展兼容性。
  2. 若短期必须保留 7.4,可评估 Remi 7.4.33-31.module_php.7.4.el8.remi 或同流后续版本作为过渡,并确认其剩余风险。
  3. 更新后需要重启全部 PHP-FPM 进程,再核对运行文件和软件包版本。此次还发现进程映射着已删除的旧 libgomp 文件,应在维护时一并验证依赖是否刷新。
  4. 如需临时缓解,可评估禁用会话上传进度、限制请求复杂度及 WAF 防护;这些措施不能作为已修复的证明。PHP 官方漏洞公告

连接时,你提供的 C:\Users\HQW.ssh\vps_codex 不存在,实际使用了本机已有的 C:\Users\HQW\.ssh\vps_codex;服务器主机密钥通过了已有记录校验。(这条请忽略)

然后我对codex说:你能修复当前版本吗?如果可以,请直接修复。不要更改网站文件和数据库。

最后它处理后反馈:已完成处理,未改动网站文件,也未执行数据库修改操作。当前状态是已应用厂商补丁及缓解措施。