PHP 紧急修复两个 9.2 分远程执行漏洞：哪些站最危险，暂时升不了怎么办

如果你的服务器上跑着 PHP，这两天需要把它升级到下面这四个版本之一：8.5.12、8.4.27、8.3.36、8.2.35。如果你用的是 Apache 加 mod_php 的部署方式，最好今天就马上升级。

10 月 21 日，PHP 官方发布了这四个版本，修复了两个漏洞，编号是 CVE-2026-109618 和 CVE-2026-109619，CVSS 评分都是 9.2。攻击者不需要登录，只要发送特制的请求，就有可能以 Web 进程的权限在你的服务器上执行任意代码。安全圈给这两个漏洞起了一个非正式的名字，叫 PHP2Shell。

PHP 官网 10 月 21 日发布的安全公告，列出了两个漏洞、受影响的部署方式和修复版本

按 W3Techs 2026 年 8 月的统计，在能识别出服务端语言的网站里，大约七成用的是 PHP。所以这次涉及的范围不小，但具体到你自己的服务器危险程度有多大，还要看你的 PHP 是怎么跑起来的。

mod_php 风险最高，FPM 要满足几个条件才会被利用

官方的说法是，所有处理 Web 请求的 PHP 都在影响范围内，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。不过不同的部署方式，被利用的难度差别很大：

部署方式	风险	原因
Apache + mod_php	最高	已经有人演示过：一个不需要登录的请求，在你的业务代码还没开始运行时就能触发攻击，而且默认配置就能被利用
PHP 8.5 + mod_php	最高	除了上面这条，8.5 默认开启的「致命错误回溯」功能还多出一条利用路径
Nginx / Apache + PHP-FPM	高	已经确认能被利用，但需要同时满足几个条件：业务代码里有操作留下了残留状态、触发了致命错误，并且下一个请求正好落到同一个 worker 进程上
PHP 7.4 / 8.0 / 8.1	高	官方已经不再维护这几个版本，只提供了源码补丁，没有发布正式版本

国内用 Nginx 的站点，PHP 基本都是通过 PHP-FPM 运行的，风险比 mod_php 低一些，但也不是不受影响。

先确认你的 PHP 是怎么跑的

查看 PHP 版本：

php -v

输出的第一行就是版本号，类似这样：

PHP 8.3.36 (cli) (built: Oct 21 2026 ...)

如果你用的是 Apache，再看一下有没有加载 mod_php：

apachectl -M | grep -i php

如果能看到 php_module (shared) 或者 php7_module 这一行，就说明你用的是 mod_php，这种情况需要优先处理。如果什么都没有输出，说明 Apache 是通过 FPM 转发请求的。

需要注意的是，命令行里的 php -v 和 Web 服务实际用的 PHP 不一定是同一个。最稳妥的做法是在网站目录下临时放一个调用 phpinfo() 的页面，看完立即删掉。

发行版、宝塔和 Docker，升级方法各不一样

用 Ubuntu、Debian 系统自带的 PHP：各大 Linux 发行版都提前拿到了补丁，它们一般会把补丁打到原来的版本上，所以版本号可能还是旧的。这种情况下不能只看 php -v，要去看软件包的更新记录里有没有这两个 CVE 编号：

apt changelog php8.3-fpm | grep CVE-2026-109618

能搜到这个编号，说明已经打上补丁了。CentOS、RHEL 这类系统可以用 rpm -q --changelog php | grep CVE-2026-109618 来查。

用 remi 源安装的 PHP：很多 CentOS 用户的 PHP 是从 remi 源装的。官方在公告里专门提醒过，这个由志愿者维护的源在发布当天没有更新。如果你用的是 remi 源，先去确认一下现在有没有新包，在新包出来之前，先按下一节的方法修改配置。

用宝塔面板：有宝塔用户反映，面板已经在 10 月 22 日凌晨上架了这四个新版本，还给 7.4、8.0、8.1 自己打包了修复版本，刷新软件列表就可以更新。目前我们没有找到宝塔的官方公告，具体以你面板里显示的为准。

用 Docker 官方镜像：把镜像的 tag 换成对应的新版本（比如 php:8.3.36-fpm），然后重新构建镜像。如果你用的是 php:8.3-fpm 这种不带小版本号的 tag，也需要重新拉取镜像，再重建容器。

还有两件事容易被忽略：

升级完之后一定要重启 PHP-FPM 或 Apache，让所有 worker 进程都换成新版本，旧进程还在运行的话等于没升级。
更新 WordPress、升级插件或者执行 composer update 都不会更新 PHP 本身。这次的漏洞在 PHP 引擎里，必须升级 PHP 运行时才行。

另外，PHP 8.2 会在 2026 年 12 月 31 日停止维护。如果你这次要从 8.2 升级，可以顺便规划一下迁移到 8.3 或更高版本。

暂时升不了，先改这几项配置

如果你的服务暂时没办法升级，官方给了一组临时缓解措施。不过官方说得很清楚，这些配置只能降低风险，并不能让你的 PHP 变安全，最后还是要升级。

; 写在 php.ini、FPM 的 pool 配置或服务器配置里
session.upload_progress.enabled = 0
post_max_size = 8M          ; 如果网站需要上传文件，改成 32M
memory_limit = -1           ; 在 FPM pool 里用 php_admin_value 强制设置

如果你用的是 PHP 8.5，还要再加一行 fatal_error_backtraces = 0。改完之后，同样要重启所有 worker 进程。

这里有几个容易出错的地方：

这些配置必须写在 php.ini、FPM pool 或服务器配置里。如果你在代码里用 ini_set() 设置，或者写在 .user.ini 里，生效的时间就太晚了，起不到作用。
memory_limit = -1 的意思是取消内存上限，这样做是为了避开内存耗尽时的漏洞路径。但这也意味着单个请求可以占用更多内存，所以要配合 post_max_size，并且在 Nginx 或网关层限制请求体大小、表单字段数量、请求头数量。如果网站用不到文件上传，可以直接在网关层拦截 multipart 请求。
把错误信息隐藏起来（比如关闭 display_errors、用 @ 屏蔽报错）没有任何效果。日志里没有报错，也不代表没有被攻击。

如果你的网站接入了 Cloudflare，它从北京时间 10 月 21 日上午 11 点左右开始，就已经用 WAF 规则拦截针对这两个漏洞的攻击请求，包括免费版用户在内。不过这也只是临时措施，不能代替升级。

两个漏洞是怎么回事？

先说一个背景：不管是 PHP-FPM 还是 mod_php，为了提高效率，一个 worker 进程都会连续处理很多个请求，处理完一个请求后，PHP 会清理这个请求留下的数据，再去接下一个。这两个漏洞都出在这个「清理」环节。

CVE-2026-109618 和内存耗尽有关。当请求处理到一半时内存不够了，PHP 会中断处理，这时候一部分内部数据只初始化了一半。随后清理环节会把这些不完整的数据当成正常数据来处理，结果导致内存被破坏。攻击者可以构造一个特殊的 multipart 请求，即使请求大小看起来没有超出配置的限制，也能触发这个问题。

CVE-2026-109619 是一个跨请求的 use-after-free（释放后重用）漏洞。打个比方，上一位客人走后服务员收了桌子，但桌上的号码牌没撤，下一位客人坐下来，拿着号码牌去取餐，取到的就是已经被别人拿走的东西。对应到 PHP 里，就是上一个请求的内存已经释放了，但指向这块内存的内部状态还留着，同一个 worker 处理下一个请求时就可能用到它。默认开启的上传进度跟踪功能就能用到这个残留状态，即使你的代码里从来没有调用过 session_start()。所以前面的缓解配置里，第一条就是关掉 session.upload_progress。

动画：上一个请求端走了盘子，号码牌没撤；下一个请求拿着它去取餐，拿到的是已经释放的空托盘

这两个漏洞都出在内存管理和错误处理上，几乎每个请求都会经过这里，所以影响面很大，修起来也很难。改动稍有不慎，就可能破坏向后兼容，或者需要大量第三方扩展跟着修改。

保密期是怎么一步步被打破的

安全漏洞一般会走一个叫协调披露的流程：发现者先私下报告给项目方，项目方修好之后，提前把补丁发给 Linux 发行版、云厂商等下游，大家约定一个统一的公开时间。在这个时间之前，所有知情方都不能对外公开，这段时间就叫保密期（embargo）。这样做的目的是让补丁和漏洞信息同时出现，不给攻击者留出时间差。

这次 PHP 原本计划在北京时间 10 月 22 日 22:00 发布，结果在发布前一天多的时间里，保密期被接连打破了好几次。根据 PHP Foundation 事后公布的时间线（以下换算成北京时间）：

10 月 20 日 23:00 左右：两个 CVE 编号在论坛和社交媒体上被泄露出来，同时流传的还有错误的发布时间和错误的 10.0 分评分，但没有泄露技术细节。
10 月 21 日 03:30：PHP 官方提前发布了预告，并且把正式发布时间提前一天，改到 10 月 21 日 22:00，好让各个发行版能尽快推送更新。
10 月 21 日 04:00 左右：参与审计的安全公司 Calif 误发了一段视频，演示了用他们的攻击代码入侵多个目标的过程。视频被转载传播开，帮黑客加快了写出恶意程序的速度。
10 月 21 日 07:00 左右：发给部分关键基础设施服务商的缓解建议，可能也被泄露了。
10 月 21 日 15:41：容器镜像厂商 Chainguard 提前发布了包含修复的镜像，比约定时间早了 6 个多小时。补丁一旦以二进制的形式公开，任何人都可以拿去对比分析。
10 月 21 日 22:00：PHP 正式发布。

动画：约定 10/22 开封的信封，先后被撕开、改日期、抽走东西，最后提前一天整封打开

PHP Foundation 对 Chainguard 的批评很直接，说这个决定无视了很多方几周以来的工作。Chainguard 的 CEO Dan Lorenc 则在 Hacker News 上回应说，当时已经有几家参与披露的安全厂商报告了在野利用，他和其他研究人员开了视频会议后，才决定提前发布修复。他后来也为给 PHP 维护者增加的压力道了歉。

另外还有一个插曲。一位开发者在 Hacker News 发帖道歉，说自己之前在 HN 上提醒大家这两个漏洞的时候，并不知道还有保密期，告诉他消息的人也说没有保密期，他的本意是提醒自己编译 PHP 的人尽快更新。评论区对此看法不一：有人认为他根本不在保密协议里，打破保密期的是消息链上更早的人；也有人认为，即使不知道有保密期，在官方公告之前把还没公开的漏洞传播出去也不太合适。

公开的攻击代码打不穿，不代表可以等

漏洞细节公开之后，GitHub 上很快出现了好几份攻击代码（也就是常说的 PoC）。不过关于这次到底有多危险，安全圈有两种不同的声音。

第一种认为没有标题说的那么可怕。Rapid7 测试后发现，公开的 PoC 只在特定的操作系统、PHP 版本和 Web 服务器组合下才能成功，没有一个是普遍可用的，他们自己写的攻击代码也只能在实验室条件下跑通。一位独立研究员专门写了一篇文章，说公开的 PoC 在一台默认安装的 PHP 上根本跑不起来，大部分还要求目标网站本身已经有本地文件包含漏洞，并且认为这次「不是 Log4j 那种级别的事件」。PHP 官方也说，截至正式发布时，他们没有在流传的 PoC 里发现能实际用的。

第二种认为要担心的不是这些公开的 PoC。HN 上有安全从业者指出，真正有威胁的是那些能用但没有公开的攻击代码，Calif 那段演示视频就说明确实有人做出来了。Cloudflare 也表示在补丁发布前就已经看到了早期的攻击，不过没有公布具体的数量。

公开的攻击代码只是冰山露出水面的一角，大多跑不通；真正危险的是没公开、能用的那部分

截至目前为止，Rapid7 还没有观察到成功的在野利用，但已经看到了多起利用尝试。

我的建议是：这次的漏洞确实不像 Log4j 那样，一行 payload 就能打穿大量服务器，但能用的攻击代码已经存在，只是没公开而已，升级这件事不要拖到下周，仅供参考。

漏洞是 AI 找出来的，修复还得靠人

这次漏洞的发现过程，和最近几个月 AI 参与安全审计的趋势也有关系。

时间要拉回到 2024 年。当时一次由德国主权技术署出资、Quarkslab 执行的外部审计期间，一位 PHP 核心开发者在修另一个问题时，最早发现了内存耗尽处理的这个隐患。当时大家推测它可能被利用，但没找到具体的攻击方法。之后几个修复方案各有取舍，讨论了好几轮也没定下来，PHP Foundation 在复盘时说，这是一次「结构性的失败」。

到了 2026 年，事情的进展快了很多：

年初，Alpha-Omega 用 Anthropic 的 Claude Mythos 对 PHP 做了一次扫描。
8 月 11 日，Calif 的研究员报告了一个无条件的远程代码执行漏洞，根因和 2024 年那个内存耗尽问题是同一个。从这时起，修复它成了 PHP 安全团队的最高优先级。
8 月 24 日，Wiz 报告了更多攻击方法；9 月 18 日，OpenAI 也报告了新的攻击路径，而且 OpenAI 此前就已经独立报告过同一个根因。

从 8 月到 10 月，前后差不多两个月就从报告走到了发布。PHP Foundation 也宣布了几项调整：安全团队改成按多数意见做决定，遇到难取舍的严重漏洞时由领导层更早介入；成立生态安全团队，新增了专门负责 AI 安全的工程师；用 AI 来验证漏洞报告、合并重复的报告，但官方强调「每个决定都由人来做，每个补丁都由人来写」。

最后，PHP Foundation 呼吁依赖 PHP 的公司、云厂商、托管服务商和政府机构持续资助 PHP 的安全工作。从这次的情况来看，AI 让发现漏洞的速度变快了，但修复漏洞、协调几十家下游一起发布，靠的还是少数维护者，连 remi 源这种很多人都在用的软件源，也是志愿者在维护。

发现漏洞变快了，修复还靠少数维护者

最后问一句

你们线上的 PHP 现在是 mod_php 还是 PHP-FPM？这次升级有没有遇到什么问题，比如发行版的包还没出来，或者老项目卡在 7.4 升不上去？欢迎在评论区说说你是怎么处理的。

资料来源：

PHP 官方安全公告：https://www.php.net/archive/2026.php
PHP Foundation 事后说明：https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
Rapid7 漏洞分析：https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/
Socket.dev 关于 Chainguard 提前发布的报道：https://socket.dev/blog/php-embargo-dispute
Cloudflare WAF 拦截报道：https://ppc.land/cloudflare-blocks-php2shell-exploits-9-hours-before-php-flaws-went-public/
SANS ISC 预警：https://isc.sans.edu/diary.html?storyid=40312
「There isn't an easy exploit for this PHP vulnerability」：https://eliastaylor.com/noexploit/
Hacker News 道歉帖讨论：https://news.ycombinator.com/item?id=50193416
宝塔更新的用户反馈：https://www.v2ex.com/t/1250775
W3Techs PHP 使用率统计：https://w3techs.com/technologies/details/pl-php