昨晚这个 PHP 漏洞，最麻烦的不是 9.2 分，是它不看你的代码

原创

simeon的文章
simeon的文章

小兵搞安全

2026年10月22日 10:12
北京

去阅读

昨晚十点（北京时间 10 月 21 日 22:00，UTC 14:00），PHP 官方发布了紧急安全更新：两个 CVSS v4.0 均为 9.2 分的未认证远程代码执行漏洞，编号 CVE-2026-109618 和 CVE-2026-109619，研究圈给这对组合起了个名字，叫 php2shell（PHP 官方公告原文见文末来源）。

一晚上过去，你的时间线上大概已经刷过五六篇通告了。CVE 编号、影响版本、升级命令，每篇都差不多。所以这篇不重复通告，讲几个通告里没有的判断。这些判断，决定了你的服务器是\"打了补丁就完事\"，还是\"这三周天天悬着\"。

1.先把事实摆清楚

时间线值得记一笔，因为它是这次事件性质的来源：

• 8 月 27 日：多个研究团队的报告送到 PHP 安全团队；
• 9 月 25 日：修复 PR 开出，最后一次提交在 10 月 18 日；
• 10 月 20 日：细节与可用 PoC 在 Hacker News 泄露，官方当天发预通告，把发布提前一天；
• 10 月 21 日 08:36 UTC：有厂商蜜罐收到第一个 php2shell 请求——比补丁公开早五个半小时；
• 10 月 21 日 14:00 UTC：四个修复版本发布。

计划内的协调披露，变成了计划外的抢跑。这三周的窗口期就是这么来的。

（一）判断一：它在你的业务代码之前就结束了

官方公告里有一句话，是这次事件最该被引用的：mod\_php 的风险最高，因为已演示的攻击可以在任何应用代码运行之前触发。

翻译一下：你花预算做的代码审计、登录加固、参数过滤、业务逻辑层的鉴权——这些应用层的东西，在这个漏洞面前全部不参与。请求到 PHP 引擎那一层就结束了，你的业务代码还没开始跑。所以很多单位自查时说\"我的代码是外包写的、我用的开源系统没这漏洞\"——问错了对象。这次坏的不是代码，是发动机。

这个\"抢在业务代码之前\"的结论，官方是在 mod\_php 上完整演示的；FPM 上前置程度弱一些，具体分层放在判断三。

但另一头也得说清，否则容易走到\"什么都没用\"的极端：官方给出的临时措施里，明确包括在 Web 服务器或代理层限制请求体大小、字段数、multipart 分片数、header 数量和嵌套深度——也就是说，网络层对\"请求形状\"的限制仍然有效。Cloudflare 也针对已知攻击向量上了 WAF 规则，但同时说明那只是权宜之计，覆盖不到走别处的流量。

准确的说法是：应用层的\"逻辑型\"防护全部失效，网络层的\"形状型\"限制还能减压。这两句话差一个字，处置动作差很多。

（二）判断二：两个洞的开关是反的，很多人第一反应会调错

这是本篇最想讲的一点，因为我核对时发现，第一批中文报道里就有把两个洞的缓解措施混着写的。

109619（陈旧全局状态）：走的是\"上一次请求留下的状态，被同一 worker 的下一次请求读到\"。已确认的读取路径有两条，一条是 PHP 8.5 上的致命错误回溯，一条是会话上传进度。

这个\"会话上传进度\"值得单独说：它从 PHP 5.4（2011 年）起默认开启，作用是给上传页面显示进度条。而官方公告里自己写了一句很实在的话——这个功能\"很少被使用和测试\"。一个开了十四年、很少有人用、连官方都承认很少被测的默认开关，昨天成了入口之一。

所以 109619 的临时措施是：session.upload_progress.enabled=0，PHP 8.5 再加 fatal_error_backtraces=0，改完必须重启所有 worker（不能靠 ini_set() 或 .user.ini，那些生效太晚）。

109618（OOM 路径）：它的开关方向是反的。这个洞的触发前提是\"请求能在你的内存限额内把内存耗尽\"，所以官方临时措施的第一条是——

把 memory_limit 设为 -1。

不是调小，是放开。而且要确保没有任何池、目录或应用的设置又把它设回有限值。

我知道这条反直觉到什么程度：绝大多数安全加固清单里写的都是\"限制内存、限制上传大小\"，而这次内存要放开。所以你会看到两种人：一种是照着老经验把 memory_limit 从 256M 调到 64M，觉得更安全了，其实正好把可利用窗口留得更宽；另一种是看到官方这条直接照做。同一份通告，两种读法，处置效果相反。

post_max_size 那条才是收紧（无上传 8M / 有上传 32M），而且官方特意提醒：只限总大小不够，还得限字段数、分片数、header 数，否则请求体不超限也能把内存吃掉。

一句话记法：老经验防的是\"太大\"，这次要防的是\"刚好卡在限额上\"。

（三）判断三：9.2 分不等于到处都是 9.2 分

这条是通告不会写的，但办案的人会先问。

CVSS 9.2 是官方给的分数，可它的向量里写着攻击复杂度为高（AC:H），还带一个\"攻击前提条件存在（AT:P）\"——意思是这个洞要打穿，得凑齐一些部署条件。具体分层是这样的：

• Apache mod\_php：官方确认在默认输入与内存限制、常规 prefork 配置下完整验证过 RCE；
• PHP-FPM：源码分析判定\"易感\"，但官方明确说没有完整的 FPM 利用被演示（FPM 在请求启动失败时直接杀掉子进程，恰好躲掉了一条路径）；
• FrankenPHP：机制与 mod\_php 类似，官方判定\"很可能同样易感\"；
• LiteSpeed（LSAPI）：行为接近 FPM，应用相关的利用\"可能但未验证\"。

再往外一层，公开的第三方分析（研究者 Jackalsyn 那篇流传较广）还提出：109618 可能存在结构性限制，109619 要稳定复现堆破坏，需要 Apache prefork 加上 glibc 2.39 这个特定版本。这类分析值得看，但要记住它是单点复现结论，不是官方口径。

这些都不是\"可以等\"的理由，官方和各国 CERT 的口径仍然是立即升级——因为细节已经公开，研究者的起跑线被提前了。但这些分层解释了一个你一定会在接下来两周看到的现象：有人拖了几天没打补丁，什么也没发生，于是觉得没那么严重。

那不是判断，那是运气。你没法知道自己的部署刚好落在哪一层，而攻击者只要猜中一次。

（四）判断四：你很可能打不上这个补丁

通告说\"立即升级\"，听起来一分钟的事。按我这些年的经验，至少有五种情况会让升级卡住：

一、版本停在 8.1 以下。 官方不再为这些分支发版，但这次破例给 7.4 / 8.0 / 8.1 出了最小化源码回溯补丁——意思是这三条线只能自己从源码编译，或者等发行版与 LTS 厂商的包。老 MIS、老 CMS 还在 7.x 上跑的，升级要动代码兼容性，不是换个包的事。

二、包源当天没更新。 这次有个很具体的坑：依赖 rpms.remirepo.net 这个第三方仓库的用户，发布当天那个仓库没有更新包，官方公告里专门点名让这批人改用发行版官方包或自己编译。\"我 yum update 过了\"和\"我升到了修复版本\"是两件事。

三、以为升级了，其实没生效。 发行版、宝塔/cPanel 这类面板、部分商业产品的修复包版本号可能不变，只变构建号；更常见的是装了新包但 worker 进程没重启，内存里跑的还是旧代码。官方在两条缓解措施里都专门写了\"重启所有 worker\"，原因就在这。

四、一台机器多套 PHP。 站点、计划任务、命令行 CLI、容器镜像，各有一份。修了网站那份，漏了容器里的和 crontab 用的。容器要重建镜像，docker restart 不解决。

五、供应商产品里捆绑的 PHP。 一体机、运维平台、第三方 appliance、监控系统，内部带着 php.exe/php-cgi，厂商不发补丁你动不了它。CERT-EU 和多个国家 CERT 都在提醒这件事——影响面不止网站。

所以升级这个动作的真实难度，不在\"敲升级命令\"，在先有一份版本台账。如果你现在答不出\"我环境里到底有几份 PHP、各是什么版本、跑在哪些机器上\"——那你的问题比这个漏洞大。

2.今天该做的五件事

（一）第五件事展开说：这三周，日志会替谁说话

从今天算起，细节公开、攻击已经出现，而补丁覆盖到全行业至少要几周。这三周是一个天然的\"窗口期\"——所有在这期间出的安全事件，都会被问同一个问题：你们是哪天补的？

我在公安办了十年案，这种\"补丁窗口期\"里的事故，最后定性就取决于两样东西：你什么时候打的补丁，和补丁之前的那段时间里，日志能不能说清楚发生了什么。

补得早，出过事也叫\"已按规范处置\"；补得晚还没日志，性质就完全不一样了。所以第五件事别省：

• 把 10 月 20 日（细节泄露那天）以来的 Web 日志、PHP-FPM 日志过一遍，重点看 PHP 进程的异常子进程、非预期文件写入、可疑外联；
• 升级重启这件事本身，记下准确时间，留档——它是你将来证明\"已尽责\"的证据；
• 公网还没来得及补的系统，日志先单独归档一份到攻击者够不到的地方，别等出事时发现日志可以被人删。

顺带一句：官方在缓解建议里也提到，可以用 pm.max_requests=1 这种\"每个 worker 只处理一个请求\"的极端方式压缩状态残留的空间——它不是给生产用的，但它说明了一件事：这次的问题本质是\"状态在请求之间活得太久\"。而日志，恰恰是唯一不能被这种状态污染的东西。

这个判断我在另一篇讲日志的文章里写过，这里再说一遍：一个正常运转的系统不会突然停止记录。这三周，请替你的服务器把\"记录\"这件事盯紧。

部队 8 年，公安网安 10 年，阿里安全 P8。20 余年一线攻防，11 本安全书作者。

这篇是应急判断，不是通告合集——通告网上有的是，判断只有这里有。系列会继续从攻、守、判三个角度写下去。

回复「PHP」领本次应急的自查清单（版本盘点 + 两个洞分别对应的配置核验 + 日志回查，可打印发给运维）。

参考来源

1. PHP 官方安全公告：《Security advisory: Critical remote code execution vulnerabilities, update now》，2026-10-21 —— https://www.php.net/archive/2026.php
2. GHSA-w8hw-w9fx-j79w（CVE-2026-109618，RCE via OOM corruption）—— https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
3. GHSA-6wmf-4rv5-p3rp（CVE-2026-109619，RCE via stale global state）—— https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
4. CERT-EU 安全公告 2026-018 及配套操作信息（NCSC-NL 维护，TLP:CLEAR）—— https://github.com/NCSC-NL/php2shell
5. Tenable：《php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions》，2026-10-20 —— https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
6. BleepingComputer：《PHP warns admins of two critical flaws, emergency patches coming tomorrow》，2026-10-20 —— https://www.bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow/
7. Huntress：《Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities》 —— https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
8. ELLIO：《PHP2Shell: what we observed and what to do》（补丁前攻击时间点与完整时间线）—— https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do
9. Aviatrix：《php2shell: Two Critical PHP RCEs, a Pre-Patch Leak...》（汇总 Jackalsyn 等第三方技术分析）—— https://aviatrix.ai/threat-research-center/research-insights/php2shell-two-critical-php-rces-a-pre-patch-leak-and-the-php-you-didnt-know-you-had/