PHP 高危漏洞 php2shell：中小企业站点应急修复清单

10月21日，国家信息安全漏洞共享平台（CNVD）收录了 PHP 的两个严重安全漏洞，编号 CVE-2026-109618 与 CVE-2026-109619，业内代号「php2shell」。两项漏洞的 CVSS v4.0 评分均为 9.2 分，CNVD 综合评级「高危」。

这不是又一个「记得更新」的常规提醒。它坏在 PHP 解释器内核的内存管理环节——也就是大多数网站跑在最底层的那一层。修复它，只能动服务器上的 PHP 本身，任何应用层操作都替代不了。

一、危害链路：一个请求，整台服务器

按官方与多家安全团队的描述，攻击路径相当短：未经身份验证的远程攻击者构造特制的 multipart POST 请求发往目标服务器，触发内存破坏，最终实现远程代码执行，拿到服务器控制权。除远程代码执行外，同一漏洞还可被用来发起拒绝服务攻击、窃取敏感数据。

时间线上还有一段插曲：漏洞信息在 10 月 20 日提前泄露，PHP 安全团队被迫确认并公布发布时间，而黑客趁机抢在补丁上线前数小时就发起了攻击。到 10 月 21 日 13:30 UTC，官方修复版本才正式发布。

换句话说，从信息泄露到补丁落地，中间存在一个窗口期，而攻击在那之前就已经开始了。

二、影响范围：先看清自己在不在这个框里

受影响的 PHP 版本如下：

分支	受影响版本	修复版本
8.5.x	低于 8.5.12	8.5.12
8.4.x	低于 8.4.27	8.4.27
8.3.x	低于 8.3.36	8.3.36
8.2.x	低于 8.2.35	8.2.35
8.1 及更早	全部（已停止官方支持）	需升级或依赖 LTS 厂商补丁

部署形态上，受影响的不是「用 PHP 写的网站」，而是所有以 PHP 处理 Web 请求的环境：PHP-FPM、Apache 搭配 mod_php、php-cgi、FrankenPHP、LiteSpeed。其中 Apache mod_php 被官方点名为风险最高的配置——攻击者可以在任何应用代码执行之前就触发攻击，一次未认证请求即可。

连带影响还覆盖 Magento、WordPress、Drupal、Joomla、MediaWiki、Roundcube、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS、OpenCart 等主流 CMS 与框架。所谓「冲击全球七成网站」，说的不是七成站点会被打，而是底层运行时共享同一个风险面。

三、两个漏洞分别坏在哪

官方与 CERT 通报给出的机制描述可以压缩成两句话。

CVE-2026-109618：出错时的现场没收拾干净。PHP 用 longjmp() 中止超出 memory_limit 的请求并抛出 OOM 错误。这会在内部请求数据只初始化了一半时直接中断——比如正在解析一次表单文件上传。后续清理流程却把这份无效数据当作有效数据去释放，而那块内存里可能还残留着攻击者可控的旧数据。

CVE-2026-109619：上个请求的东西留在了下个请求里。请求持有的内部状态，在其后备内存被释放之后仍然存活——例如发生致命错误之后。同一个 worker 处理的下一个请求，可能在正常初始化把它重置之前，就用上了这份陈旧状态。

概括起来：PHP 在「出错之后把现场收拾干净」这件事上做得不够彻底，而攻击者有能力把出错点摆在对自己有利的位置上。

四、现在该做什么（顺序别乱）

第一步，查版本——注意命令行和网站真跑的不是一个东西。

用 php -v 查命令行版本，用 php-fpm -v 或 php-fpm8.3 -v（按实际分支）查网站实际运行的版本。最常见的坑是：命令行查出来已经是 8.3.36，网站实际跑的是 FPM 池里的 8.3.20，两边根本不同步。升级之后，同样要用 FPM 的方式再复核一遍。

第二步，能升就升。

优先走发行版或 LTS 厂商的官方包，别自己编译。已经 EOL 的 8.1 及更早版本：找供应商确认有没有回溯补丁；PHP 官方这次也额外为从源码构建的组织提供了 7.4、8.0、8.1 的最小化源码 backport。

第三步，补丁打不上就先挡住。

• CVE-2026-109618：在 FPM 池配置或 Apache 配置里设 memory_limit=-1（用 php_admin_value，让应用层面无法覆盖），并确认没有别的层级把有限值又设了回来
• CVE-2026-109619：把面向互联网的 PHP 应用与公网隔离，直到补丁应用并验证完成
• 官方列出的临时手段还包括：临时下线、关闭会话上传进度功能、网络访问限制

这里要把话说清楚：官方明确说明，**只有升级才是真正的修复**，这些措施只是降低特定攻击路径的暴露面，不等于安全。

第四步，升级后必须验证。重启 php-fpm 或 apache，再查一次版本。「升了但没重启」的假修复，在事故复盘里出现的频率高得离谱。

第五步，回头查有没有被摸过。漏洞细节与验证代码已经公开传播，攻击门槛很低。补丁之外还要补三件事：更换服务器账号、口令、密钥等凭证；排查日志里的异常 multipart POST 与异常子进程；扫一遍 Webshell。

五、一个高频误解：更新 WordPress 没用

WordPress 官方已经明确：这个问题**无法通过应用层更新解决**，站点所有者必须直接更新服务器实际运行的 PHP 环境。

很多人看到新闻的第一反应是登后台更新 WordPress、更新插件——方向错了。该动的是服务器上的 PHP 本身。中小企业的站点大多托管在虚拟主机或第三方服务器上，PHP 版本并不在自己手里，这种情况该做的是：立刻联系服务商确认是否已修补；对方打不了补丁，就要求给出隔离或临时防护的具体方案与时间。