一句话结论：截图是真的，事件是真的，多国政府发紧急通告也是真的——但"各国政府联合行动"这个说法是假的，它是各国 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. 服务	动作
   コドモン（保育园联络 App）	14:00 起全服务停，22 日 03:22 逐步恢复；家长端一起停，公立保育园改电话联系
   BASE（网店平台）	15:50 起维护，约 15 小时
   Creema / pictSQUARE / Xserver / さくらインターネット	陆续维护，部分功能停
   pixiv / niconico	19:00 起维护，pixiv 约 4.5 小时后恢复
   Cygames《赛马娘》《碧蓝幻想》《影之诗》	23:00 停服；影之诗明确"进行中的对局全部作废"
   静岡銀行 / 瑞穂銀行 / 七十七銀行	网银或部分服务暂停
   厚生労働省 / 財務省	部分公开页面暂停
   京阪控股 / 阪急電鉄	网站下线

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

   欧洲

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

   ---

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

   指标	数值	来源口径
   使用 PHP 的网站占比	69.3% ~ 75%	W3Techs 约 75%；Wiz 称约 70%；共同社引欧洲机构 69.3%——口径不同，别当矛盾
   公网暴露的 PHP 主机	510 万台以上	VirusTotal 估算
   受影响的 PHP 版本跨度	PHP 5.4 起	Wiz
   官方已停止支持的版本	8.1 及更早	PHP 官方（8.2 也将在 2026-12-31 EOL）

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

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

   ---

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

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

   它改变的是默认假设：

   过去我们默认"存在多年没人利用 = 大概不好利用，可以慢慢来"。
   现在这个推论不成立了。老漏洞的"可利用性折扣"正在被 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 升级路径

   你现在的版本	目标
   8.5.x	8.5.12
   8.4.x	8.4.27
   8.3.x	8.3.36
   8.2.x	8.2.35（注意：12 月 31 日 EOL，顺手规划升级）
   8.1 / 8.0 / 7.4	官方只给源码回移植补丁，需自行编译，或找发行版/LTS 厂商的后移植包

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

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

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

   措施	针对	关键注意
   memory_limit=-1，用 php_admin_value 在 FPM pool / Apache 配置里设	109618（OOM 路径）	应用层能不能覆盖？要确认没有任何 pool / 目录 / 应用设置把有限值加回来
   收紧 post_max_size（无上传 8M，有上传 32M），并保持 upload_max_filesize < post_max_size	109618	在 Web 服务器/代理层独立再限一次解码后体积
   session.upload_progress.enabled=0	109619	必须在请求解析前生效（php.ini / pool / 服务器配置），不能靠 ini_set() 或 .user.ini
   PHP 8.5 上 fatal_error_backtraces=0	109619	同样要重启所有 worker
   降低 max_input_nesting_level，限制输入变量数 / multipart 段数 / 每段头数 / 上传数	两条	主要是压 DoS 面，补丁后也该做
   容器 / cgroup 内存上限（memory.max）	109618	绝对不要用 RLIMIT_AS / RLIMIT_DATA——它们会让 mmap() 失败，反而触发那条 longjmp() 路径
   不用 multipart 表单的站，前端直接拦掉 multipart 请求	两条	简单有效，前提是确认真不用

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

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

   8.5 七个常见坑

   ---

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

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

   来源	说法
   CISA	发布时未观测到在野利用
   watchTowr	蜜罐在补丁落地前后记录到首次在野利用尝试，但没有成功案例；"这不代表会一直如此"
   Hadrian	补丁前数小时就报"已在大规模利用"，主要走 session upload-progress 路径
   Amazon（MadPot 蜜罐）	10 月 17 日首次尝试；PoC 公开后"几乎立刻"被用于攻击自家传感器；结论"正在被广泛利用"
   Cloudflare	Prince 公开的量级曲线：数千 → 数十万 → 数百万次
   Chainguard	蜜罐抓到来自中国和俄罗斯的 IP 在打
   Patchstack / Vega	均观测到利用尝试，Vega 称用的是公开 PoC

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

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

   这意味着：如果你跑 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曝出存在严重漏洞 高市称暂停网站也是选项》

• 时事通信 / 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 每日简报）

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

• 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

• 官方公告：源码分析"支持 FPM 可受影响"，但完整 FPM 利用未演示

• 独立分析（CyberSecBrief 等）也指出：RCE 确认在 mod_php，FPM / php-cgi / FrankenPHP / LiteSpeed 属"在风险范围内但未演示"

• PHP worker 进程拉起 shell、下载工具、写定时任务、加用户

• web 根目录里新出现的 .php 文件（webshell 典型手法）

• 访问日志里密集的 multipart POST、异常大的请求头数量

• 出站连接异常（打点回连）

• 已升级也要查——升级不等于没被打过

• 缺陷存在了十余年，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 有史以来最严重的漏洞之列，也堪称软件史上最严重的漏洞之一。" 以及"证明可利用性需要一条异常复杂的步骤链，处在人类研究者实际能做到的边缘"。

• 🇳🇱 荷兰：国家网络安全中心带头下线；DigiD 统一登录、众议院网站、鹿特丹港、Overheid.nl、NOS、RTL、足协 KNVB、五大政党网站、若干医院

• 🇫🇮 芬兰：政府公共网络服务临时关闭，面向公众的网站下线

• 🇩🇰 丹麦：市政 IT 公司 Kombit 关闭含国家学校通信平台在内的多项服务

• 🇬🇧 英国：预算责任办公室（OBR）网站下线

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）尚无官方确认的"被打穿"案例。

5. 只升了 CLI，没升 FPM。php -v 是 8.3.36，站点还跑着 8.3.25。

6. 只重启 nginx。nginx 重启跟 PHP 进程半毛钱关系没有。

7. 面板里的 PHP 版本没切。宝塔站点 conf 里 include enable-php-74.conf 一天不改，切了也没用。

8. 容器镜像没重建。改 docker-compose.yml 的 tag 之后 up -d 不一定重拉，加 --pull always 或先 docker pull。

9. rpms.remirepo.net 用户。PHP 官方明说这个志愿者仓库发布当日不会有更新，建议换发行版包或自己编译。

10. 8.1 及以下以为"总会有包"。没有。只有源码补丁。

11. 下载来路不明的 PoC 验证脚本。韩国 KISA 专门警告：网上流传的所谓 PoC 大量是带恶意代码的假货。

12. 重启每一个 PHP 进程。systemctl restart php-fpm / service php-fpm restart / 容器重建。不重启 = 老代码还在内存里跑。

13. 清 OPcache（如果启用了且没随进程重启失效）。

14. 控制面板和虚拟主机。cPanel、Plesk、宝塔这类面板自带的 PHP，很多站长根本不知道它在。当晚 HN 上有人吐槽"面板厂商一声没吭"。

15. 容器基础镜像。你 FROM php:8.3-fpm 的那一刻，版本就锁死了。应用代码再新也没用。

16. 嵌入 PHP 的设备和商业软件。工业路由器、防火墙 Web 界面、储能设备、门禁系统、老旧 OA——这些既不进资产表，也不进渗透测试范围。PHP 官方和荷兰 NCSC 都点名要按清单排查第三方产品。