- 摩杰斯
- 2026-10-23
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 版本并不在自己手里，这种情况该做的是：立刻联系服务商确认是否已修补；对方打不了补丁，就要求给出隔离或临时防护的具体方案与时间。
