PHP 漏洞修复技能如何避免版本误判

让 AI agent 帮忙排查 PHP 漏洞，最容易踩的坑可能是版本判断：版本号看起来旧，发行版却已经补过漏洞；命令行里的 PHP 更新了，网站进程却还在运行旧代码。

原文围绕 PHP2Shell 比较了几套 agent skills，重点看它们查什么、怎样确认补丁，以及修改前是否等待批准。作者读的是 skill 文件，没有给出运行实测。它最有用的提醒是：先让 agent 收集证据，再决定要不要修。

PHP 版本低于修复版，就一定有漏洞吗

按原文，PHP2Shell 包含 CVE-2026-109618 和 CVE-2026-109619 两个 PHP 自身漏洞，PHP 项目于 2026 年 10 月 21 日在 PHP 8.2.35、8.3.36、8.4.27、8.5.12 中修复。

但这些上游版本号，不能直接当作所有服务器的判定线。Linux 发行版经常把安全补丁移植到旧版本，同时保留原来的上游版本号，这叫补丁回移（backport）。

原文列了三个例子：

• Ubuntu 24.04 的修复包是 php8.3 8.3.6-0ubuntu0.24.04.13，对应 USN-8948-1。
• RHEL 9 的修复包是 php-8.0.30-8.el9_8.1，对应 RHSA-2026:87151。
• Chainguard 的修复包是 8.4.26-r4。

只看到 8.3.6 小于 8.3.36，就判定 Ubuntu 那个包存在漏洞，会把已修复的机器报成有问题。agent 如果据此自动升级，就可能制造一次没有必要的变更。

判断补丁状态，要看完整软件包修订号和厂商公告。

原文也没有说所有版本排序都可靠。Chainguard 的 skill 特别提醒，不能按普通文本比较版本，因为 -r10 比 -r4 更新。

这些 skills 的差别，在于怎样收集证据和约束修改

原文称，漏洞修复发布后的两天内，多支团队为 Claude Code、Codex、Devin 等编码和运维 agent 发布了相关 skills。作者比较的是文件里的规则，几套方案各有侧重。

OpenAI phpcheck-server 要求结合覆盖两个 CVE 的厂商指引，比较完整包修订号；还会检查更新后 Web worker 是否重启，并禁止运行漏洞利用探测。

OpenAI phpcheck-url 则明确承认自己的边界：HTTP 响应头无法证明某个版本是否包含回移补丁。因此，它适合初步摸排，不能独立下结论。

Cognition fix-php-vuln 禁止单靠 php -v 和上游版本号作判断。发现阶段结束后，它要求停止操作，展示结果表，并询问用户要修哪些仓库。

Chainguard php2shell 要求每次修改前取得用户明确批准。php2shell-response 默认只读，除非用户另有指示；遇到旧版本包，也要求检查厂商更新日志或公告。

原文还指出几种容易误判的路径：ProjectDiscovery Nuclei 的 CVE-2026-109618 模板在版本回退判断中，只比较上游补丁号，并把所有低于 8.2 的版本标为停止维护；Assetnote scanner 在没有观察到崩溃信号时，会回退到 X-Powered-By 中的版本号；部分社区 skills 虽然用了 sort -V，输入却仍然只有上游版本号。

排序工具再准确，也补不回被丢掉的包修订信息。

更新了安装包，网站为什么还可能运行旧代码

另一个排查盲区是运行入口。php -v 查到的是命令行 PHP，网站实际可能使用 PHP-FPM、Apache module 或 LiteSpeed，路径和版本未必相同。

所以原文建议，先给 agent 只读权限，让它提交包含 runtime、path、version、package、status 的表格。重点是确认服务请求的那个 PHP。

更新后还要检查进程是否重启。旧 PHP 进程停止之前，仍可能继续运行旧代码。下面这条命令用于查看 PHP 进程的启动时间：

ps -eo pid,lstart,cmd | grep -i '[p]hp'

注意 lstart 显示的是进程启动时间，需要结合更新时间判断；这条命令本身不能证明补丁已经生效。

原文同时建议，不要让 agent 下载或执行公开的概念验证代码（PoC）。作者称多数公开 PHP2Shell PoC 仓库属于攻击工具，代码未经审查。

我的判断

这篇最有价值的地方，是把「扫描结果」和「修改依据」分开了。远程响应头能帮助发现资产，本机软件包信息和厂商公告才能提供更完整的补丁证据。两种检查适合接力使用。

不过，skill 写了限制，不等于 agent 每次都会遵守。作者没有提供执行记录、误报率或不同方案的对照数据，因此这是一份规则审阅，不能据此认定哪套工具实际最可靠。

它的流程还依赖几个前提：能读取服务器软件包信息，能找到对应厂商公告，也有权限核查网站运行进程。只有 URL、没有主机权限时，结论就应保留不确定性。

作者也披露自己运营 PHP2Shell 被动检查站点 php2shell.fyi。文中的漏洞编号、修复版本和公告编号均来自所给原文，这里没有独立核验。

能拿来做什么

• 给维护 PHP 服务的 agent 明确安排发现阶段：先输出运行时、路径、版本、软件包和状态，并附上判断依据，再讨论修改。
• 审查现有安全 skills：检查它是否只拿 php -v、X-Powered-By 或上游版本排序作结论，尤其要保留发行版包的完整修订号。
• 把实际 Web 运行入口和更新后的重启验证纳入修复步骤，避免安装包更新后，处理请求的进程仍未切换。
• 使用扫描器批量摸排时，把版本比较产生的告警列为待确认项，并限制 agent 自动运行来源不明的 PoC。