一句话结论：截图是真的，事件是真的，多国政府发紧急通告也是真的——但"各国政府联合行动"这个说法是假的，它是各国 CERT 各发各的，只是日本首相和韩国副总理亲自下场，把这件事推到了罕见的政治层级。

---

一、先回答你问的两件事

1.1 那张截图：真事，而且中文翻译基本准确

我按"逐条主张 → 核查结论 → 依据"的方式过了一遍：

翻译上只有两处小偏差，不影响判断：

1. "国家网络统筹室"是「国家サイバー統括室」（National Cybersecurity Office, NCO）的直译。这是 2025 年才设立的机构，把原 NISC 的职能收了进去；所以英文媒体至今还混着写 "NISC" 和 "NCO"，两说的是同一家。
2. "发布注意提醒"严格说分两步：10 月 20 日先发的是预警（只说"两个漏洞、CVSS 9.2、21 日发补丁"，不给细节），完整技术公告 10 月 21 日才公开。帖文写在 20 日晚上，说的是前者，不算错。

需要说明的核查局限：X 原帖我这边打不开（x.com 请求失败），所以是以多家通讯社逐字引述的同一段内容互相比对来确认的。这比"看截图"可靠，但严格讲属于二手印证。

1.2 "各国政府在为 PHP 漏洞下紧急通知"：真，但别说成"联合行动"

这是两件不同的事，混在一起就容易变成阴谋论：

所以准确的说法是：这是一次全球网络安全社区的同步应急响应——各国 CERT 的常规动作，恰好撞上一个"影响面按亿计、且补丁前细节已泄露"的事件，于是被拉到了政府首脑层级。它没有任何"联合声明"或"统一指令"的成分。

顺带一个细节能佐证这种"各干各的"：英国预算责任办公室（OBR）把网站下线了，芬兰临时关闭政府公共网络服务，荷兰网络安全中心带头把自己的网站下线，鹿特丹港、DigiD、众议院、NOS、RTL 跟着下——没有统一时间表，都是各自拍板。

---

二、这两个漏洞到底怎么回事

2.1 编号与基本盘

2.2 CVE-2026-109618：longjmp() 挖的坑

PHP 限制内存用 memory_limit，一旦超限，它不抛异常，而是用 longjmp() 直接把执行流"跳"回上层——相当于从函数中间强行弹栈。

问题就出在这个"跳"上：某些时刻，请求相关的内存还没初始化完就已经可达。这时候如果恰有一次内存分配失败，longjmp() 一走了之，却没人把这份"半成品内存"标成无效。紧接着请求关闭流程（request shutdown）照常跑，把这块垃圾当合法数据读、当合法指针释放——释放一块从未初始化的内存，而那块地址上可能还留着上一个请求里攻击者控制的数据。

攻击者怎么造这个"恰好"？官方公告给得很直白：构造一个 multipart 请求，塞大量请求头、嵌套字段名、空文件控件，让表面没超 post_max_size、实际解析时撑爆 memory_limit。

2.3 CVE-2026-109619：跨请求的"鬼魂"

第二个更阴。PHP 的 worker 进程是复用的：一个进程处理完请求 A，接着处理请求 B。设计上，A 的全局状态（错误状态、会话状态、对象状态、扩展状态）应该在 A 结束前清干净。

但 A 如果是因为致命错误（比如 OOM）非正常退出的，清理可能不完整——session.upload_progress 这条路径就被官方点名是"可利用路径之一"。等 B 进来，如果某些解析/配置/会话/错误处理逻辑在正常初始化之前就跑了，它读到的是 A 留下的、指向已释放内存的"鬼魂指针"。

于是攻击者可以自己当生产者、自己当消费者：请求 A 布置堆布局，请求 B 触发使用。两个请求落在同一个 worker 上即可，不需要登录。

2.4 为什么这次"特别脏"：三个位置特征

第一条是全网最难受的地方：你网站代码写得再干净也没用。一次 HTTP 请求，在 index.php 第一行执行之前，代码就已经在服务器上跑了。

2.5 9.2 分，但别误读这个分数

这一点很多中文报道漏了。CVSS v4.0 的向量是：

AV:N / AC:H / AT:P / PR:N / UI:N / VC:H / VI:H / VA:H

• PR:N UI:N：不需要任何账号，不需要骗人点击——这是它可怕的地方
• AC:H AT:P：利用复杂度高，且依赖特定部署前提（build、扩展、前端行为、分配器布局都要对得上）

翻译成人话：这不是"扫一圈全网一键 getshell"，而是一个需要针对目标调参的高难度利用。Wiz 自己的说法是"处在人类研究者实际能力的边缘"，是前沿模型把这道门槛压下来的。

但反过来也成立：一次成功就等于服务器沦陷（以 Web worker 账户身份执行任意代码），而且它还能只读内存不执行代码——把进程里的密码、Token、API Key 直接捞走。这个"低配版攻击"的门槛低得多。

---

三、96 小时时间线（以及一场崩掉的协调披露）

这条时间线里最值得记的不是"漏洞多严重"，而是"披露流程崩了"：

1. 细节在补丁前夜泄露（CVE 编号、技术原理、演示视频都出来了）；
2. PHP 团队被迫把发布从 22 日提前到 21 日；
3. 又有厂商（Chainguard）在禁运解除前 6 小时把修补后的镜像推了出去；
4. 结果是一个公开的、无补丁可打的窗口期——从 20 日泄露到 21 日 21:30 发补丁，约 20 小时裸奔。

高市那条帖子本质上是在填这个窗口：既然补丁还没到，那唯一确定有效的动作就是把站关了。

---

四、那一晚，谁关了站

日本（公开可查的部分）

安全博客 piyolog 汇总到 22 日凌晨 2 点，能从公开告知确认的紧急维护单位有 211 家。这个数字是民间汇总，不是官方统计，引用时要说清。

欧洲

• 🇳🇱 荷兰：国家网络安全中心带头下线；DigiD 统一登录、众议院网站、鹿特丹港、Overheid.nl、NOS、RTL、足协 KNVB、五大政党网站、若干医院
• 🇫🇮 芬兰：政府公共网络服务临时关闭，面向公众的网站下线
• 🇩🇰 丹麦：市政 IT 公司 Kombit 关闭含国家学校通信平台在内的多项服务
• 🇬🇧 英国：预算责任办公室（OBR）网站下线

这一节的意义：停站不是"过度反应"，而是在被证明可行之前，唯一不赌概率的选项。对一个跑着几十万台服务器、补丁无法在同一秒打完的生态来说，"先关门、升完再开"是成本最确定的一条路。

---

五、为什么 PHP 一咳嗽，半个互联网就肺炎

三个"藏得比你想的深"的地方：

1. 控制面板和虚拟主机。cPanel、Plesk、宝塔这类面板自带的 PHP，很多站长根本不知道它在。当晚 HN 上有人吐槽"面板厂商一声没吭"。
2. 容器基础镜像。你 FROM php:8.3-fpm 的那一刻，版本就锁死了。应用代码再新也没用。
3. 嵌入 PHP 的设备和商业软件。工业路由器、防火墙 Web 界面、储能设备、门禁系统、老旧 OA——这些既不进资产表，也不进渗透测试范围。PHP 官方和荷兰 NCSC 都点名要按清单排查第三方产品。

补丁本身不难，难的是"找到所有 PHP"和"重启每一个 worker"。

---

六、AI 第一次同时当发现者和武器化者

这是我认为整件事最该被记住的部分，比漏洞本身重要。

• 缺陷存在了十余年，2020 年有人摸到过，2024 年审计又露头，都没修——原因是"无法证明可利用"。这个理由，在前沿模型面前失效了。
• Wiz 用的工具：Wiz Atlas + Gemini 4 Argon + GPT-5.6 Sol。用他们的话说，Gemini 4 Argon 在"发现漏洞、开发利用、攻击检测、验证补丁"四个环节都有关键贡献。
• 另一条独立路径：Calif 的 Ryan Austin 在 OpenAI「Patch the Planet」项目下审计 PHP，用 GPT-5.6 Sol 几周内跑完全程。Calif 的记录是：8 月 1 日确认 OOM fatal，8 月 11 日报给 PHP，8 月 15 日项目确认可利用。
• Wiz 的原话值得抄下来："这些发现属于 PHP 有史以来最严重的漏洞之列，也堪称软件史上最严重的漏洞之一。" 以及"证明可利用性需要一条异常复杂的步骤链，处在人类研究者实际能做到的边缘"。

它改变的是默认假设：

过去我们默认"存在多年没人利用 = 大概不好利用，可以慢慢来"。
现在这个推论不成立了。老漏洞的"可利用性折扣"正在被 AI 抹平。

Cloudflare CTO Dane Knecht 的判断也差不多：这不会是最后一次，AI 会持续在广泛使用的软件里挖出这类东西，"软件维护者、研究者、服务商和政府需要一套新的共同响应方案"。

而攻击侧的效率提升同样明显——Cloudflare CEO Matthew Prince 公开的曲线是：公告前"数千次"尝试 → 公告后 45 分钟"数万次" → 2 小时"数十万次" → 现在"数百万次"。

---

七、PHP 基金会自己承认：这是结构性失败

这段我建议完整读一遍，因为它比任何外部批评都狠。PHP 基金会 10 月 21 日的博客里写：

为了修这个 OOM 问题，安全团队开发了几个互相竞争的方案，每个都有代价：破坏向后兼容、引入新的 DoS 风险、或者需要改动大量第三方扩展——而后者看起来根本协调不动。团队靠共识运作，在这些方案之间迟迟选不出来，又害怕选错。
再加上当时没有已知的 RCE 路径，而掌握引擎深层知识的核心开发者只有那么几个人、还都身兼数职——这个决策过程让修复工作在几个月里反复停滞又重启。
我们不装作别的：这次拖延是结构性失败，既来自安全团队的决定流程，也来自资源不足。

配套事实：2024 年的外部审计就露出过苗头；支撑七成互联网的语言，安全工作仍靠基金会资助的一小群开发者。

这条脉络和 2024 年的 XZ 后门事件是同一个母题：关键基础设施的维护者长期处于"人少、钱少、责任无限"的状态。区别是 XZ 有个英雄偶然发现，这次没有英雄——只有停在半路几个月的修复方案，和一整晚的停服。

---

八、给你的处置清单（中国开发者向）

先说一句：如果你用宝塔/虚拟主机/建站面板，先别急着 php -v，那个结果可能不是你站点实际跑的版本。

8.1 五分钟自查

# 1) CLI 版本（最不可信的一个，但先看）
php -v | head -1

# 2) FPM 实际版本（宝塔：站点 conf 里 include 的是哪个）
grep -r "enable-php" /www/server/panel/vhost/nginx/*.conf

# 3) 进程实际在跑什么
ps aux | grep -E "php-fpm|httpd|frankenphp|litespeed" | grep -v grep

# 4) 容器镜像（最容易漏）
docker ps --format '{{.Names}}\t{{.Image}}'
docker images | grep -i php

# 5) 面板自带的 PHP（宝塔常见 74/80/81/82/83 并存）
ls /www/server/php/

判定标准：只要低于 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 中对应分支的版本号，就是受影响。8.1 及更早一律受影响且无官方包。

8.2 升级路径

升级后必须做的两件事（最多人栽在这）：

1. 重启每一个 PHP 进程。systemctl restart php-fpm / service php-fpm restart / 容器重建。不重启 = 老代码还在内存里跑。
2. 清 OPcache（如果启用了且没随进程重启失效）。

8.3 实在升不了：官方临时缓解

官方明确写了：只有升级是完整方案，下面这些只降低特定攻击路径的暴露，不能让安装变安全。

8.4 事后排查：假设已经被打过

窗口期是 10 月 17 日至今（Amazon 蜜罐的最早记录）。看这几样：

• PHP worker 进程拉起 shell、下载工具、写定时任务、加用户
• web 根目录里新出现的 .php 文件（webshell 典型手法）
• 访问日志里密集的 multipart POST、异常大的请求头数量
• 出站连接异常（打点回连）
• 已升级也要查——升级不等于没被打过

8.5 七个常见坑

1. 只升了 CLI，没升 FPM。php -v 是 8.3.36，站点还跑着 8.3.25。
2. 只重启 nginx。nginx 重启跟 PHP 进程半毛钱关系没有。
3. 面板里的 PHP 版本没切。宝塔站点 conf 里 include enable-php-74.conf 一天不改，切了也没用。
4. 容器镜像没重建。改 docker-compose.yml 的 tag 之后 up -d 不一定重拉，加 --pull always 或先 docker pull。
5. rpms.remirepo.net 用户。PHP 官方明说这个志愿者仓库发布当日不会有更新，建议换发行版包或自己编译。
6. 8.1 及以下以为"总会有包"。没有。只有源码补丁。
7. 下载来路不明的 PoC 验证脚本。韩国 KISA 专门警告：网上流传的所谓 PoC 大量是带恶意代码的假货。

---

九、还没定论的三件事（别被单方面说法带走）

9.1 到底被打了没有？口径差得很远

我的判断：大规模扫描和尝试是真的，"大规模成功打穿"目前没有可靠证据。这两件事经常被中文自媒体混成一句"全球网站已被大规模攻陷"，属于夸大。

9.2 PHP-FPM 到底能不能无认证打？

• 官方公告：源码分析"支持 FPM 可受影响"，但完整 FPM 利用未演示
• 独立分析（CyberSecBrief 等）也指出：RCE 确认在 mod_php，FPM / php-cgi / FrankenPHP / LiteSpeed 属"在风险范围内但未演示"

这意味着：如果你跑 FPM，"立刻会死"的概率低于 mod_php，但没有任何理由拖。而且 FPM 那条路只要有应用特定条件（比如攻击者能触达致命错误）就可能成立。

9.3 影响面数字别混着用

69.3% / 70% / 75% / 80% 都在流传。区别在分母：是"全部网站"还是"能识别出服务端语言的网站"，以及采样时间。写文章时挑一个来源标注清楚，不要四个数字混着说。

---

十、写在最后

第一，这次真正被暴露的不是 PHP，是"补丁前的那 20 小时"。

漏洞存在了十几年，但杀死你的窗口只有一晚：细节泄露 → 补丁未发 → 全网裸奔。传统漏洞管理节奏（"等官方公告 → 评估 → 下周排期"）在这个窗口里完全没有意义。NCSC 的博客标题起得很准："为'补丁洪峰'做准备"。

第二，"用不用 PHP"是个伪问题。 你用的是 WordPress、是 Discuz、是某个建站工具、是某台工业设备的 Web 面板——PHP 就在下面。真正的问题是：你有没有一份完整的运行时清单。

第三，AI 让"老漏洞"重新变成新威胁。 这次的根因 2020 年就被摸到、2024 年被写进审计报告，都因为"没法证明可利用"而搁置。模型把这个理由作废了。以后看到"存在十年、无法利用"的结论，得默认它可能明天就被推翻。

最后一句给普通用户：不用慌。PHP 跑在服务器上，不在你手机电脑里。某个网站忽然打不开，很可能是它在主动避险。真正要盯的是后续公告——如果哪家过几天发"确认遭到不正当访问"，再按它的指引改密码、查订单。至于"因停机请你重新登录验证账户"的短信和邮件，一律别点，去官方 App 里看。

---

参考来源

一手（官方公告/公告页）

• PHP 官方安全公告：https://www.php.net/archive/2026.php#2026-10-21-5
• GHSA-w8hw-w9fx-j79w（CVE-2026-109618）：https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）：https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• PHP Foundation《Today's PHP Security Release, and How We're Strengthening PHP Security》(2026-10-21)
• 英国 NCSC：https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
• 美国 CISA 公告（2026-10-21）
• 欧盟 CERT-EU Security Advisory 2026-018：https://cert.europa.eu/publications/security-advisories/2026-018
• 加拿大 Cyber Centre AL26-026
• 新加坡 CSA AL-2026-151
• 日本 IPA《【事前準備のお願い】PHPのセキュリティリリース公開予定について》(2026-10-21)
• 中国 CNVD-2026-41674 / CNVD-2026-41675；CNCERT 风险提示；工信部 NVDB 通报
• 阿里云公告：https://www.aliyun.com/notice/118746
• 腾讯云公告：https://intl.cloud.tencent.com/announce/detail/101577

技术分析

• Wiz Research《PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet》：https://www.wiz.io/blog/php2shell-php-rce

媒体报道

• 共同社《详讯：PHP曝出存在严重漏洞 高市称暂停网站也是选项》
• 时事通信 / Japan Times《Bank, business and ministry websites halted after PHP vulnerabilities announced》
• 中央社《PHP爆重大資安漏洞 歐洲多地政府網站緊急下線防駭》《PHP釋出緊急安全更新 資安署籲機關及企業儘速完成修補》
• 新华社《PHP存在严重安全漏洞 多国机构网站临时下线》
• ANI / Deccan Chronicle《Japan PM, FBI Warn of Critical PHP Security Flaws as Major Websites Go Offline》
• 首尔经济日报《Korea Raises Cyber Alert Level Over Critical PHP Flaws》
• SecurityWeek / The Register / CyberSecBrief（2026-10-22 每日简报）

---

附：核查方法与局限

1. 截图真伪：X 原帖页面无法直接访问（x.com 请求失败），改为比对共同社、时事通信、ANI、中央社、Japan Times、首尔经济日报对同一帖文的逐段引述；时间戳按 UTC+8 → JST 换算后与日媒记录（21:55 JST）一致。
2. 技术细节：以 PHP 官方公告与两个 GHSA 页面为准；CVSS 向量、CWE、受影响 SAPI 的判断全部取自 GHSA 原文，不采信二手转述。
3. 政府动作：优先引官方站点（NCSC / CERT-EU / CISA / IPA / CSA / Cyber Centre），媒体报道只作旁证。
4. 明确标注的不确定项：①"211 家停服单位"来自 piyolog 民间汇总；②在野利用的"规模"各家口径差异极大，见 9.1；③发文时（2026-10-22）尚无官方确认的"被打穿"案例。