一个在 PHP 内核里的"后门"，不需要账号就能触发
这次出问题的是两个编号分别为 CVE-2026-109618 和 CVE-2026-109619 的漏洞，CVSS 4.0 评分都是 9.2（严重级），类型是"未经认证的远程代码执行（RCE）"。
翻译成人话：攻击者不需要任何账号、不需要进后台，只要朝你的服务器发一个精心构造的请求，就有可能在服务器上运行他自己的代码。能拿到什么？数据库密码、API 密钥、整站内容，甚至整台服务器的控制权。
图：PHP 核心漏洞示意（本文配图由 AI 生成）
更麻烦的是，这两个漏洞不在某个插件、某个框架里，而是在 PHP 解释器本身的内核。这意味着不管你用的是 WordPress、Drupal、Joomla、Laravel 还是 Magento，只要底层的 PHP 没修，风险就一直存在——PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP、LiteSpeed 这些运行模式全都中招。
漏洞原理各有不同：一个来自内存耗尽（OOM）报错时触发的内存破坏，另一个来自"过期的全局状态"——上一个请求释放了内存，残留状态却没清干净，下一个请求在还没初始化时就踩了这块雷。
为什么是"七成网站"？因为 PHP 就是 Web 的地基
安全公司 Wiz 的估算在圈内被广泛引用：PHP 支撑着全球约 70% 的网站。CNET 援引《华尔街日报》的说法也指向同一数字——"全球 70% 的网站可能受影响"。
这不是夸张。WordPress 一个建站系统就占了互联网可探测资产的 7200 万以上，而它本身就是 PHP 写的；加上 Drupal、Joomla、Laravel、MediaWiki、Symfony、WHMCS……基本覆盖了你能想到的绝大多数内容型网站和电商系统。
互联网扫描机构 Censys 在 10 月 21 日当天监测到约 258 万个可从公网访问的 PHP 主机，其中约 158 万个能识别出版本号，而这 158 万里又有约 157.6 万个报告的版本早于这次修复版本。当然，其中一部分可能已经在打补丁了，不能直接等同于"正在被黑"，但量级已经足够吓人。
这次是 AI 先发现漏洞，攻击者紧跟其后
这次事件最值得玩味的一点，是漏洞的发现过程。
据外媒披露，PHP 核心开发者早在 2024 年就注意到了相关内存问题的苗头，但一直没找到具体的利用路径，修复一度卡住。真正的突破发生在 2026 年 8 月：加州安全公司 Calif 的研究员 Ryan Austin 在审计 PHP 源码时，借助 OpenAI 的 GPT-5.6 Sol 模型，把这个埋了十多年的缺陷转化成了可用的远程代码执行链。几乎同时，Wiz 用自家的 AI 代理（结合 Gemini 4 Argon 与 GPT-5.6 Sol）独立发现了相关漏洞，并在 8 月 19 日就实现了针对 Drupal 的未授权代码执行。
Wiz 联合创始人 Ami Luttwak 说，这是"迄今为止发现的最严重的人工智能相关漏洞"，复杂程度高到"如果没有 AI 的帮助，这个漏洞很可能根本不会被发现"。
讽刺的是，AI 帮防守方找到了漏洞，也帮攻击方缩短了武器化时间。有研究显示，AI 能把一个安全补丁反向推导成可用利用代码，耗时不到一小时、成本仅几千美元算力。当补丁公开的那一刻，攻击者立刻就能用 AI 比对新旧代码、定位缺陷、生成载荷——传统"先发补丁、慢慢分析"的防守节奏，在 AI 时代正在失效。
图：AI 审计代码发现漏洞示意（本文配图由 AI 生成）
披露被"剧透"，全球在一个没有缓冲的窗口里起跑
原本计划 10 月 22 日才做协调披露，但 10 月 20 日，匿名消息就开始在 Hacker News 和社交平台上流传，附带两个 CVE 编号；随后"php2shell"攻击链的演示视频出现，安全公司 watchTowr 也确认复现了 CVE-2026-109618。
面对细节已经公开的局面，PHP 安全团队被迫把补丁发布时间提前了一天，到 10 月 21 日 14:00 UTC。而 watchTowr 在补丁落地前后就已经观察到真实利用尝试，Cloudflare 也报告了攻击流量——防守方和攻击者这次几乎是同时起跑的。
多国政府和企业，选择"先关机再说"
漏洞细节一出来，不少机构的第一反应不是打补丁，而是直接下线。
荷兰暂时关闭了政府门户网站、鹿特丹港网站，以及部分医院和政党网站；芬兰国家 IT 服务机构 Valtori 暂停了部分政府公共服务；法国一些地方行政机构网站进入维护状态；德国联邦 IT 服务商 ITZBund 也关闭了部分网站。日本那边更热闹：全日空暂停了网站和 App 服务，野村证券、三菱 UFJ 金融集团暂停了部分非核心业务，朝日集团、京阪控股、世嘉、万代南梦宫也都因预防原因停了部分系统。
欧盟网络安全局（ENISA）、美国 CISA、英国 NCSC、澳大利亚网络安全中心接连发布紧急警告。美国国安局（NSA）说得最直接：要么立刻升级，要么在能打补丁之前把暴露在互联网上的系统先撤下来。
唯一的彻底解法：升级，然后重启
PHP 官方已经在 10 月 21 日发布了修复版本。唯一彻底安全的办法是升级到以下任一版本：
| PHP 分支 | 安全版本 |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
如果你用的是 PHP 8.1 及更早版本，情况要糟一些：这些版本早已停止官方支持，不会拿到正式更新。PHP 团队只为 7.4、8.0、8.1 提供了最小化的源码向后移植补丁，给有能力自己编译的人用；用 Linux 发行版或 LTS 厂商打包版本的用户，得联系对应厂商要移植补丁。
还有两个容易踩的坑：
- 打补丁后必须重启。 Apache、PHP-FPM 以及所有长期运行的 PHP 工作进程都要重启，否则内存里残留的旧进程仍然脆弱。
- 临时缓解措施不是安全边界。 比如关掉
session.upload_progress.enabled、上 WAF 规则，只能挡住一部分已知攻击路径。PHP 基金会明确说过，这些措施"并不能使安装变得安全"，最多当补丁上线前的减速带。Cloudflare 的 WAF 能拦已知载荷，但攻击者已经在改手法绕规则了。
真正的麻烦在"长尾"
即便补丁已经发布，这事儿也没完。几个长尾风险值得每一个运维心里有数：
- 补丁窗口没了。 过去防守方通常有几天时间在攻击者逆向补丁前完成升级，但这次漏洞细节和利用工具在补丁发布前就公开了，有判断认为补丁落地后约 15 分钟就可能开始大规模攻击。
- 大量"被遗忘的 PHP"永远打不上补丁。 PHP 8.1 及更早版本没有官方安全更新，而现实里仍有海量服务器跑在这些旧分支上。互联网扫描显示，可识别版本的 PHP 实例里，7.4 是占比最高的单一分支——它们往往藏在遗留应用、共享主机、被人遗忘的虚拟机里，运维者甚至不知道自己有一台 PHP 服务器在跑。
- AI 改写了攻防的时间经济学。 补丁一公开，攻击者用 AI 比对新旧代码、生成载荷几乎是即时的事。依赖"发补丁后慢慢分析"的老节奏，已经不灵了。
普通站长和开发者现在该做什么
如果你只是跑个个人博客或小企业站，先别慌，但别装看不见：
- 查版本。 看一眼你的服务器 PHP 到底是哪个分支、哪个小版本。
- 能升就升。 对照上面的表，升到对应安全版本；用虚拟主机或面板（比如宝塔、cPanel）的，等厂商推送更新或直接一键升级。
- 升级后务必重启服务。 这是最容易漏的一步。
- 老版本别侥幸。 跑 7.4、8.0、8.1 的，去要厂商的移植补丁或安排迁移，别指望临时配置能保平安。
- 上 WAF 当缓冲，但不当保险。 在补丁到位前，WAF 能帮你挡掉一批自动化扫描和已知载荷，争取时间。
写在最后
这次事件像一面镜子：互联网最底层的一处旧伤口，被 AI 的放大镜照了出来，又借着"剧透式披露"在一夜之间把全球拖进了一场没有缓冲的攻防赛跑。AI 既帮我们提前看到了危险，也让危险来得更快、更猛。
对绝大多数网站来说，结论其实很朴素——及时升级、重启服务、别拿临时措施当免死金牌。技术再花哨，根基还是那句老话：补丁早打一天，风险就少一分。
