PHP漏洞扫描为何误判已修复系统
部分Linux发行版将PHP安全补丁回移至旧版本，导致只比较上游版本号的扫描器或AI Agent把已修复系统判为易受攻击。文章列出多个发行版的修复构建号，并指出部分扫描模板和Agent技能存在此类判断问题。
原文暂未完整获取，基于公开信息的快读
PHP 安全更新装了，扫描器或 AI Agent 却仍报漏洞，问题可能出在版本比较方式。dev.to 这篇文章指出，部分 Linux 发行版会把安全补丁回移到已有 PHP 版本，保留旧的上游版本号；只盯着这个号码判断，可能误报。反过来，机械读取 CVE 记录，也可能把受影响的旧分支判成安全。
目前能确认什么
据原文节选，PHP 上游已在 8.2.35、8.3.36、8.4.27 和 8.5.12 修复 PHP2Shell 相关漏洞。部分发行版采用补丁回移（backport）：把修复应用到原有软件包，再通过发行版构建号区分更新。
因此，看到 8.3.6，不能直接断定它缺少修复。文章指出，Nuclei 的相关模板、Assetnote scanner 在特定回退判断中，以及部分社区 Agent 技能，存在只比较上游版本号的问题。
另一个方向也会出错。节选称，相关 CVE 记录只列出部分新分支，其他版本被标为不受影响，但 PHP 安全团队也为 7.4、8.0 和 8.1 发布了源码修复。未被记录列为受影响，不等于已经证实安全。
我的判断
漏洞自动化需要输出判断依据，而不能只给一个红绿标签。对发行版安装的 PHP，应核对实际服务使用的软件包完整版本、对应发行版安全公告，以及 PHP 进程是否在更新后重启。只检查 php -v，或者确认安装命令执行成功，都不足以闭环。
给 Agent 的指令也应具体：按发行版修复构建号比较，无法核实就报「未知」，不要自行补成「安全」。
目前节选没有给出各发行版完整修复构建清单，也不足以确认相关扫描工具当前是否已修正逻辑。文中点名的问题适合用来检查自己的判断流程，不能直接扩大成对这些工具所有扫描结果的否定。