PHP2Shell漏洞，旧版用户要忙了

一夜之间，PHP 圈子沸腾了。 北京时间 10 月 21 日 22 点，PHP 官方连夜发布紧急版本，一次修掉两个评分 9.2 的远程代码执行漏洞，外界把它们叫作 PHP2Shell。 这两个漏洞不在插件或框架里，而是藏在 PHP 解释器自身。说白了，业务代码写得再规范，服务器上只放一个 Hello World，只要 PHP 没更新，攻击者发一个请求就可能控制整台机器。 更让人头疼的是，受影响版本从 PHP 5.4 一直覆盖到 8.5，而官方只为 8.2 到 8.5 提供了正式补丁。仍在运行 PHP 7 甚至 PHP 5 的“祖传项目”，接下来恐怕要忙上一阵。 这两天里发生了什么 按原计划，漏洞信息应在 10 月 22 日公开；但消息提前泄露，PHP 团队只好把发版时间提前一天，补丁尚未发布就有人开始尝试攻击。 以下时间均为 UTC，北京时间需加 8 小时。 10 月 20 日，Hacker News 上有人曝出两个 CVE 编号以及原定 22 日的公开日期；当天晚上，PHP 发布预告，将发版提前到 21 日。 10 月 20 日约 20:00，研究团队 Calif 误将一条可利用利用链的演示视频公开。 10 月 21 日 03:02，Cloudflare 为全部 WAF 用户默认启用拦截规则，免费版也在其中。 10 月 21 日 07:41，厂商 Chainguard 提前发布已打补丁的镜像，相当于先把修复代码摆在所有人面前。 10 月 21 日 14:00，PHP 正式发布 8.5.12、8.4.27、8.3.36、8.2.35。 10 月 21 日 14:19，watchTowr 表示已观测到针对这两个漏洞的主动利用尝试。 顺便澄清一个误传：泄露时有人说漏洞评分是满分 10.0，这不准确，官方对两个漏洞给出的都是 CVSS v4.0 9.2。不过 9.2 已经足够让人紧张。 这两个漏洞有多严重 概括起来就是：无需登录，不挑应用，一个请求就可能取得服务器权限。 CVE-2026-109618：内存耗尽时“收尾”出错。PHP 处理请求时，如果内存恰好在内部数据只初始化了一半时耗尽，后续清理流程会把未完成的数据当成正常数据使用，攻击者可借此执行代码。打个比方，后厨备菜做到一半突然停电，收尾的人却把半成品当作成品端上了桌。 CVE-2026-109619：前一个请求留下的“旧房卡”没有失效。请求结束后，残留状态仍指向已释放的内存，同一个 worker 处理下一个请求时继续使用，这就是典型的 use-after-free。官方确认，它既能泄露内存内容，也能远程执行代码。 之所以说它狠，有几个原因。 第一，跟你的代码无关。漏洞位于引擎层，PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed，只要在处理 Web 请求，就都在影响范围内。 第二，mod_php 最危险。官方演示过：一个未认证请求，在任何应用代码运行之前就能触发攻击。 第三，不拿 shell 也能窃取信息。攻击者可以直接读取 worker 进程的内存，其中可能留有其他请求的密码、登录令牌、API Key 和证书。 第四，主流 CMS 都中招。研究团队确认，对特定版本的 WordPress、Drupal、Joomla、Magento 都能实现无需登录的远程代码执行。 第五，盘子很大。有安全研究员粗略估计，公网上可能受影响的主机超过 130 万台。 对照版本，看看自己处在哪一档 官方只负责 8.2 到 8.5；7.4 到 8.1 提供的是需要自行处理的源码补丁；更老的版本则无人维护。 8.5.x：官方提供正式修复版 8.5.12，应立刻升级。 8.4.x：官方提供正式修复版 8.4.27，应立刻升级。 8.3.x：官方提供正式修复版 8.3.36，应立刻升级。 8.2.x：官方提供正式修复版 8.2.35，先打补丁；8.2 将在 2026 年 12 月 31 日停止支持，顺手安排迁移。 7.4、8.0、8.1：不出正式版，只放出最小化源码补丁。需要自行编译打补丁，或寻找发行版、商业 LTS 厂商；长远看必须迁移。 5.4 到 7.3：什么都没有。只能迁移；迁移前先隔离或下线公网入口。 使用 Linux 发行版自带软件包的人要注意：各发行版已提前拿到补丁，软件包版本号看起来可能仍是“旧”的，但实际上已经修复。判断时应查看包 changelog 中是否出现这两个 CVE 编号，而不是只看版本号。 老版本钉子户，是时候面对了 先看一组数据。W3Techs 在 2026 年 8 月 22 日的统计显示，在已知服务端语言的网站中，PHP 占 70.3%。其中 PHP 8 占 63.1%，PHP 7 仍有 28.9%，PHP 5 还有 7.9%，甚至 0.1% 的网站还在运行 PHP 4。 换句话说，超过三分之一的 PHP 网站仍停留在官方早已停止维护的版本。PHP 7.4 在 2022 年 11 月停止支持，PHP 5.6 更是在 2018 年底就退役了。 这些站点为何会留下来？做过外包的人大概都清楚。 验收即终点。项目上线、尾款到账，服务器从此再没人登录过。 能跑就别动。“又没出问题，升什么级？”这是不少甲方的口头禅，也是很多开发商的心声。 一升就白屏。祖传代码里一堆 mysql_ 系列函数、each()、create_function()，PHP 7、PHP 8 早已删除，升级等于重写。 升级没人买单。维护合同里只写“保证正常运行”，没写“保证运行时版本受支持”。 这次最尴尬之处在于，7.4 到 8.1 虽然官方给了源码补丁，却需要自行编译。可问题是，有能力从源码编译 PHP 的团队，当初多半不会停留在 7.4。至于 5.x 到 7.3，连源码补丁都没有。 更何况，一个月前（9 月 24 日）PHP 刚发布过一轮安全更新，修复了 11 个 CVE。长期停在老版本，相当于这些年一个补丁都没装上，PHP2Shell 只是其中动静最大的一次。 因此接下来几周，不少开发商的日常大概会是：翻出十年前的旧项目清单，逐个登录服务器查版本；挨个给客户打电话，解释为什么“本来好好的网站”突然要加钱升级；最后在 PHP 8 的报错堆里改到深夜。 这一回，确实有得忙了。 几个值得留意的细节 第一个细节，这个漏洞在 2024 年就露过苗头。PHP 基金会承认，2024 年进行外部安全审计时，一位核心开发者已发现与内存不足相关的问题迹象，但当时没有找到真正能打通的利用路径。几套修复方案各有风险：可能破坏兼容性，可能引入拒绝服务，也可能迫使第三方扩展跟着修改；小团队讨论不出结论，一拖就是几个月。基金会将这次拖延定性为决策流程和资源上的结构性问题，并表示已经增加人手、补充工具、调整流程。 第二个细节，AI 正成为漏洞挖掘的加速器。该漏洞由 Wiz、Calif 和 OpenAI 的研究人员发现并报告。研究者表示，AI 让一个人在大约一周内完成过去一个团队要花几个月做的事。Calif 还把这个漏洞的源头追溯到 2004 年的 PHP 研究，相关代码在 PHP 里存在了十多年。换句话说，旧漏洞被翻出来的速度只会越来越快，留给打补丁的时间只会越来越短。 第三个细节，一批网站选择先拔网线。美国 HR 软件 BambooHR 在美国、加拿大、爱尔兰下线服务，连工资发放都受影响；荷兰的政务门户、数字身份 DigiD、议会下院网站以及多套教育系统也临时下线；日本的 BASE、Codmon 等服务紧急停机，不少主机商连夜升级。这些都属于预防性操作，并不代表已经被黑。 第四个细节，攻防已经开打。Cloudflare 表示，看到攻击者不断更换载荷以绕过其规则。截至发稿，公开信息中还没有确认成功入侵的案例，但不要因此就感到安心。 第五个细节，网上的 PoC 不要随便下载。漏洞泄露后出现了不少号称可用的利用代码，安全公司提醒，来路不明的利用代码有时本身就夹带木马。 别只看热闹，今天该动手的事 官方的说法很直接：升级是唯一完整的修复方式，其他办法都只能争取时间。PHP 核心开发者 Gina Peter Banyard 在发版前回复网友时也表达了这个意思：除了打补丁升级，没有真正有效的缓解手段。 第一步，弄清自己运行的是什么。确认 Web 服务实际使用的 PHP 版本，不要只执行 php -v，因为命令行和 PHP-FPM 可能并非同一版本。宝塔这类面板、主机商后台以及 WordPress 的“站点健康”页面都可以查看。 把手头所有项目列成清单：客户站点、内部系统、接口服务、Docker 镜像，一个都不要漏。 第二步，能升级的立刻升级。升级到 8.5.12、8.4.27、8.3.36 或 8.2.35。 升级完成后重启 Apache、PHP-FPM 以及所有常驻 PHP worker；不重启就等于没升级。 使用发行版软件包的，要去 changelog 中确认这两个 CVE 编号，不要只看版本号。 提醒一句：升级 WordPress、Laravel 并不会顺带升级 PHP，运行时必须在服务器、主机商或容器镜像那一层更新。 升级后要检查内存配置：新版本增加了内存硬上限，达到上限会直接终止进程，shutdown 回调也不会执行，因此要按业务实际需求核对 memory_limit 和 post_max_size。 第三步，暂时无法升级的，先止血。以下措施只能降低部分攻击路径的风险，不能替代升级。 针对 109618：将 memory_limit 设为 -1，并以应用无法修改的方式设置，例如 FPM 池配置中的 php_admin_value；同时调低 post_max_size，在 Nginx 或网关层限制请求体大小。内存兜底交给容器或 cgroup。不要用 RLIMIT_AS、RLIMIT_DATA 代替，它们反而可能触发同一条漏洞路径。 针对 109619：设置 session.upload_progress.enabled = 0；PHP 8.5 还要加上 fatal_error_backtraces = 0。修改完成后重启所有 worker。 启用 WAF。Cloudflare 免费版也已有规则，但官方自己都说这只是临时救急，而且只覆盖经过它的流量。 实在不行，先把面向公网的服务隔离或下线，修好后再恢复。 第四步，检查此前是否被探测过。查看日志中是否有异常的 multipart 请求，随后紧跟着内存超限报错或一连串 500。 响应中是否存在大得离谱的 PHPSESSID Cookie。 PHP worker 是否出现过不明原因的重启。 给开发商的长期建议：把“运行时版本保持在官方支持范围内”写进维护合同，并按年报价。这次的补丁账单，与其临时求客户支付，不如以后提前谈妥。 写在最后 技术债就像信用卡，平时刷起来很爽，账单迟早会到。PHP2Shell 不是第一张账单，也不会是最后一张。 PHP 本身并没有那么不堪，它一直在发布版本、修复漏洞，真正拖后腿的是那些“上线后就遗忘”的服务器。今晚正在升级的人辛苦了；还在犹豫的人，请记住一句话：补丁是免费的，被黑可不是。 参考来源 PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge，The Hacker News，2026 年 10 月 21 日 php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions，Tenable，2026 年 10 月 21 日 PHPに認証不要のコード実行につながる重大な脆弱性2件「php2shell」，セキュリティ対策Lab，2026 年 10 月 21 日 PHP 8.2.34・8.3.35・8.4.26・8.5.11で11件の脆弱性を修正，セキュリティ対策Lab，2026 年 9 月 28 日 Usage statistics of PHP for websites，W3Techs，2026 年 8 月 22 日数据 修复方案以 PHP 官方安全公告为准。