10月21日，PHP官方紧急发布四个修复版本，处理两处可能导致远程代码执行的高危漏洞。
两处漏洞可能让攻击者不用登录，就在服务器上执行代码。在一种Apache部署方式下，攻击甚至可能赶在业务代码运行前发生。
PHP官方公告。来源：PHP安全公告
但这条命令查到的，只是当前终端使用的PHP。网站可能跑在另一个容器里；新包装好了，处理网页请求的旧进程也可能还没重启。
反过来，看到PHP8.1，也不能直接认定它没有补丁。
Ubuntu已经把修复补进部分旧版本的软件包，版本号不会变成PHP官网公布的最新版。
这次需要查清的是：用户打开网站时，请求到底交给了哪套PHP？那套程序打上补丁了吗，处理请求的进程重启了吗？
漏洞在PHP自身，改业务代码补不上
这两处漏洞分别是CVE-2026-109618和CVE-2026-109619，CVSS 4.0评分均为9.2。
简单说，它们都发生在PHP处理请求时的内存状态：一次异常退出后，尚未准备好的数据或已经释放的内存，可能被后续流程继续使用。
PHP官方把PHP-FPM、Apache mod_php、php-cgi、FrankenPHP和LiteSpeed等接收Web请求的安装方式都列入排查范围。
其中，mod_php的风险最高，已有无需登录、在应用代码执行前触发的攻击得到验证。其他运行方式也不能据此放行，但不能写成“每一种环境都已复现同样的攻击”。
这也是为什么只升级WordPress插件、改一段Laravel业务代码，解决不了问题。漏洞在PHP运行时。Cloudflare在自己的说明中也明确提醒：更新网站代码或插件，无法代替更新服务器上的PHP软件。
许多报道把注意力放在“AI挖出PHP漏洞”上。
发现过程值得看，但对守着线上服务的开发者来说，先要确认补丁有没有到位。
Wiz研究文章。中文要点：漏洞位于PHP核心，可影响网站请求处理；关于Calif的发现与PHP维护者主导修复，另见OpenAI原文
官网没有PHP8.1新版本，不等于你的8.1没救了
PHP项目发布的修复版本是8.5.12、8.4.27、8.3.36和8.2.35。照着这个清单看，一台仍在运行PHP8.1的服务器似乎已经无路可走。
但操作系统发行商会把安全修复“回补”到旧版本：版本主干仍叫8.1，软件包里的代码已经更新。
Ubuntu给出的例子很直观。
Ubuntu22.04的PHP8.1修复包是8.1.2-1ubuntu2.28；Ubuntu24.04的PHP8.3修复包是8.3.6-0ubuntu0.24.04.13。这两个版本号都没有跳到PHP官网列出的新版本，却已有对应的发行版补丁。
Ubuntu公告。要点：Ubuntu22.04的PHP8.1已有修复包8.1.2-1ubuntu2.28，旧主版本不等于没有补丁。来源：Ubuntu安全公告
判断一台旧版机器是否修好，不能只看php -v显示的主版本，要看它从哪个渠道安装、实际软件包版本是多少、该渠道是否已发布修复。
Debian也在安全跟踪页按发行版列出了修复状态。自编译PHP、第三方仓库、云厂商镜像和托管主机，则要分别核对各自的维护者公告。
PHP团队还提供了PHP7.4、8.0、8.1的最小源代码回补，供自行构建或缺少长期维护渠道的用户使用。
Debian安全跟踪页。同一PHP版本在普通仓库与安全仓库中的状态可能不同，应看具体发行版和软件包。来源：Debian安全跟踪页
php -v只回答了命令行，不回答网站在跑什么
还有一种更隐蔽的误判：在宿主机执行php -v，显示“已更新”，就给线上服务打勾。
这条命令查到的是当前终端调用的PHP。
网页请求可能走Nginx后面的PHP-FPM容器，可能走另一套Apache mod_php，也可能由主机商提供的PHP进程处理。
宿主机升级了，容器镜像没重建；命令行PHP是8.4，网站仍指向PHP8.1。这些部署并不罕见。
排查时先画出请求去向：域名进了哪台主机、哪个容器或服务、由哪个PHP进程接手。再到那个环境里核对安装来源和补丁状态。不要为了查版本，临时把phpinfo()页面公开到互联网上；它还会暴露许多运行配置。
编辑部根据PHP与Ubuntu官方公告整理的排查路径示意图
Ubuntu提供了一个软件包盘点命令：
apt list '?installed ?name(^php[0-9.]+$)'。它能帮助确认系统装了哪些PHP解释器包，仍不能替你证明网站到底使用哪一个。容器环境还要看实际部署的镜像摘要与运行中的容器，不能把镜像标签当作最终证据。
软件包更新成功，旧进程可能还在接请求
查到修复包之后，工作也没有结束。Ubuntu公告专门提醒：使用PHP的应用可能需要重启；对于Apache mod_php，示例是重启Apache。自动安全更新即使已经安装了新包，相关应用仍可能需要重启或整机重启。
Ubuntu公告。要点：安装修复包后，使用PHP的应用仍需重启；Apache mod_php的示例是重启Apache。来源：Ubuntu安全公告
对运维团队来说，收尾要看运行态：PHP-FPM或Apache是否完成重启，容器是否重新构建并发布，负载均衡后面的每个实例是否都已切换。只要还有一台旧实例接流量，仪表盘上的“更新成功”就不能算验收结果。
WAF能挡一阵，不能替代补丁
Cloudflare已部署针对这次漏洞的WAF规则，也表示观察到攻击流量以及攻击者调整请求以尝试绕过防护。它给客户的建议仍是尽快更新PHP，同时把WAF作为额外防线。前提还包括请求确实经过相应的WAF配置；源站若能绕过它直接被访问，边缘规则就护不到那条路径。
Cloudflare官方说明。要点：WAF是额外防线，即使已部署规则，仍应更新PHP。来源：Cloudflare官方博客
如果业务今天确实无法升级，PHP公告给了减少暴露的临时措施，例如在服务端配置中关闭session.upload_progress并重启全部工作进程，或限制请求大小。
但这些措施只覆盖部分已知攻击路径，配置错位置还可能完全不起作用；memory_limit=-1也会改变内存耗尽时的风险，不能当作一行“万能修复命令”直接抄进生产。官方说得很清楚：完整的解决办法只有更新PHP。
开发者有话说：补丁到了，链路还没走完
Hacker News里，一位开发者先说PHP7已经停止更新，随后自己编辑补充“看来还是有回补补丁”。
另一位开发者直接回复：“已经有回补了。”这正是旧版排查的麻烦之处：不能把“PHP官网不再发新版”和“所有安装渠道都没有补丁”画等号。
Hacker News原评论与后续更正。来源：PHP8.2.35讨论串
同一讨论串里，还有开发者盯着Docker官方PHP镜像何时完成发布。
有评论指出，源码仓库里的更新合并后，还要经过官方镜像构建与分发流程。评论反映的是发布当时的等待和困惑，不能据此判断此刻镜像仍未更新；它提醒我们检查实际拉到的镜像，而不是看见源码发布就认定容器已修好。
Hacker News用户讨论官方镜像发布流程。来源：PHP8.2.35讨论串
披露时机也引起了争论。
有开发者质疑，少数机构提前获知问题，而其他开发者直到公开当天才拿到修复；跟帖则提醒，提前公开补丁本身，也可能把漏洞细节一并暴露。
Hacker News用户对协调披露时机的不同看法。来源：PHP8.2.35讨论串
这次最该留下的，不是一张“高危漏洞”海报，而是一份能对上线上流量的清单：每个站点由谁处理PHP请求、补丁来自哪个发布渠道、更新后的进程是否已接管流量。三个问题都答上了，才算真正完成这轮修复。
资料来源：
PHP安全公告
Ubuntu修复公告
Debian安全跟踪
Cloudflare防护说明
OpenAI披露
PHP GitHub安全公告
——好文链接——
开发者低估了AI的能力！Claude工程负责人：用旧方法指挥Agent，开发者们反倒成了“传送带”
AI为什么越聊越容易犯错？Every评估负责人：旧的上下文，正在带偏你的 Agent
思维链并不是大模型的内心独白！Anthropic研究员：模型并非逐行写成，它是在训练中“长出来”的
