一个模型一周干完团队几个月的活：PHP 十年老洞被 AI 挖出，七成网站连夜打补丁

10 月 21 日，PHP 基金会一次性发出四个安全版本：8.5.12、8.4.27、8.3.36、8.2.35。对应的是两个被统称为 PHP2Shell 的漏洞，编号 CVE-2026-109618 与 CVE-2026-109619，CVSS v4.0 评分都是 9.2——在这个评分体系里，9.0 以上属于「严重」。

严重在哪？未登录的攻击者就能在受影响服务器上远程执行代码。不需要账号、不需要钓鱼、不需要用户点开附件，只要你的站点跑在受影响的版本上，并且暴露在公网，就可能被直接拿下。篡改页面、读取数据库、把服务器当成跳板，都是这条链路上的后续动作。

影响范围是这件事最麻烦的地方：从 PHP 5.4（2012 年发布）到 8.5，十余年的版本几乎无一幸免。业界估计约七成的网站依赖 PHP 运行，其中大量是 WordPress、Drupal、Joomla 搭的企业官网、商城与内容站——也就是说，这不像某个插件出问题，而是地基出问题。

从公开信息看，这两个漏洞属于内存安全缺陷，类型是 use-after-free 与 type confusion，出问题的部分是 PHP 用 C 写的引擎核心。用人话解释：当一个请求崩溃或者耗尽内存时，PHP 可能留下指向已释放内存的引用；同一个 worker 进程处理下一个请求时，仍然把这块内存当成有效数据使用。

攻击者可以精心构造请求，让这块「已经不属于自己」的内存被填入可控内容，进而劫持执行流程。Wiz 不仅演示了在 WordPress、Drupal、Joomla 上未登录执行代码，也演示了不执行代码、仅读取服务器内存的攻击方式——后者同样危险，因为内存里往往躺着数据库口令与会话密钥。

值得注意的是，PHP 基金会的研究员早在 2024 年就察觉到这里可能有问题，但一直没能构造出可用的利用路径。缺陷从「可疑」变成「可利用」，中间隔了两年，最后被模型补上了这一跳。

为什么这类缺陷在 PHP 上格外难缠？因为 PHP 常以 php-fpm 的常驻 worker 方式运行，一个进程要连续处理成百上千个请求。如果某个崩溃请求留下的悬垂引用没有被彻底清理，下一个请求就会在同一块内存上继续工作——两个本来互不相干的访问者，就这样被放进了同一间屋子。这也是为什么修复必须覆盖到每一个 worker，而不是重启一次就算完。

第一个漏洞的报告来自安全公司 Calif。他们用 OpenAI 的 GPT-5.6 Sol 做代码审计，8 月 11 日提交报告，8 月 12 日就确认可以对 Drupal 实现未授权代码执行，8 月 21 日在 WordPress 上复现。第二个漏洞由 Alphabet 旗下的 Wiz 在 8 月 24 日独立上报，用的是 Gemini 4 Argon 与 GPT-5.6 Sol 交叉验证。

Wiz 事后给出的评价很重：这些发现「属于 PHP 历史上最严重的漏洞，可能也是软件史上最严重的之一」，并称单个研究员借助前沿模型，用大约一周时间完成了过去需要一支专家团队数月才能完成的工作，是一个「AI 拐点」。

这句话要分两面听。一面是效率：代码审计这种过去靠人海与经验的活，现在可以被模型放大；另一面是门槛：同样的模型，攻击者也能用。OpenAI 自己在公告里承认了这一点——AI 既能帮防御方抢时间，也能帮攻击方缩短从漏洞到武器化的周期。

按行业惯例，这类漏洞会走协调披露：发现方、维护方、云厂商与 CERT 在非公开渠道协作，修好、验证完、准备好防护，再同时公开。这次原本计划了约两个月的窗口，PHP 团队 9 月 21 日确认报告后进入修复阶段，Cloudflare、Quarkslab 等参与验证与缓解方案准备。

但 10 月 20 日，细节在社交平台上泄露；据 PHP 基金会说法，Calif 又误发布了一段演示视频，视频在攻击论坛扩散。原本的节奏被打断，补丁提前一天，于 10 月 21 日发出。Cloudflare 在当天 03:02 UTC 开启默认防护，比原计划早了约九小时，并公开表示随后观察到攻击者修改 payload 以规避规则。

这段插曲对所有做安全响应的人都是一个提醒：协调披露的前提是「没人泄露」。一旦细节流出，防守方的时间窗就会从「两个月」压缩到「几小时」，而绝大多数企业根本没有为几小时准备过流程。

更现实的问题是，这几小时往往不是花在技术上，而是花在「谁批准停机」「谁签字升级」「外包方几点上班」上。技术动作可以提前演练，决策链条却很少被演练——这正是很多企业在同类事件里吃亏的地方。

这次事件的公开反应很罕见。美国国家安全局发布了一份不常见的公开警告，建议无法立即升级的站点先下线；英国国家网络安全中心给出类似建议。随后，法国多个省府网站、德国数字部、荷兰议会、芬兰中央政府、英国预算责任办公室（OBR）与 NHS Scotland 等，都出现了短暂停站或限制访问。

停站不是小题大做，而是权衡后的选择：一个正在跑的旧版本，暴露在公网每小时都在被扫描；临时下线虽然丢面子，但至少不会丢数据。维基媒体旗下站点与多款日本游戏也一度暂停服务，原因相同。

云侧的观察更能说明攻击密度：Cloudflare 首席执行官表示，披露后其网络看到数百万次针对 PHP2Shell 的利用尝试，亚马逊也报告了类似情况。好消息是目前没有看到大规模成功利用的迹象——这既归功于补丁发得快，也归功于多数站点在窗口期内做了缓解。

不过，停站对政府机构来说是一种可承受的选择，对中小企业未必。一个电商站停两小时，损失的是当天的订单与搜索权重；一个招聘页停半天，可能错过一整批投递。中小企业更需要的是「降级而不是停机」：先关掉不必要的入口与上传功能，把 WAF 规则调严，把后台访问限制到固定 IP，再安排低峰期升级。

这件事传到最后，很多老板的第一反应是「我们不用 PHP」。但问题在于：你知道自己不用吗？企业官网、招聘页、活动落地页、老商城、某个部门三年前找人做的小工具——这些往往由外包或建站公司托管，技术栈从来没人登记过。

PHP 的分布恰好集中在这些「边缘资产」上：它们不在核心系统的监控里，不在等保的清单里，甚至不在 IT 部门的台账里。可一旦被拿下，攻击者拿到的是同一台服务器上的数据库、同一套域名下的 cookie、同一条内网通道。

所以这次事件真正考的，不是谁会用 yum 升级，而是三件事：你有多少对外暴露的站点、每个站点跑什么版本、出问题时能联系到谁。这三件事答不上来，补丁发得再快也落不到你头上。

第一步，盘点。把所有对公网提供服务的域名列出来，逐个确认技术栈与托管方；对托管在外部服务商那里的站点，直接发函要求书面确认 PHP 版本与补丁状态。别接受「我们用的是最新版」这种口头答复，要版本号。

第二步，升级。能自己控制的服务器，按 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 的目标版本升级；跑在 8.1 及更早版本的，官方已不再修复，必须规划迁移，短期先用 WAF 规则与访问控制顶住。升级前务必备份数据库与站点目录，并确认备份能恢复——只备份不验证，等于没有备份。

第三步，验证与观察。升级后用版本检查工具确认版本号，但要注意它只能识别版本、无法判断补丁是否被厂商回移；随后盯 72 小时的异常登录、异常进程与对外连接。Cloudflare 已经提醒攻击者在改写 payload，规则命中率下降是正常现象，不能据此判断「没人打我们」。

第四步，留证据。把这次盘点的结果、升级的时间点、谁批准的、回滚方案写成一份记录。下次再遇到同类事件，这份记录能省下的不是时间，是决策摩擦。

还有一条常被忽略的责任边界：如果站点由建站公司或托管商维护，补丁该谁打、多久内打完、打之前要不要通知你，这些都应该写在合同或服务协议里。很多企业在出事时才发现，自己只有一个销售微信，没有运维联系人；而对方一句「我们用的是云服务，云厂商会处理」，就把责任推得干干净净。

OpenAI 把这次协作称为「防御者之窗」：在攻击者之前发现漏洞，为维护者争取修复时间。为此它提出了一套五阶段的关键漏洞响应框架，并宣布投入 10 亿美元，通过「Daybreak for Frontline Defenders」为资源有限、守护关键服务的组织补贴 AI 安全能力。

但同一篇公告里也写了另一句：同样的能力可能被攻击者用来更快开发攻击工具与利用程序。这不是客套，而是这次事件已经验证过的事实——从泄露到数百万次尝试，中间只隔了几个小时。

对普通企业来说，结论不是「赶紧去买 AI 安全产品」，而是承认一个趋势：漏洞被发现的速度会越来越快，留给修补的窗口会越来越短。能适应这个节奏的，不是工具最多的公司，而是资产最清楚、流程最短、备份最可靠的公司。

如果你只有一个人负责 IT，优先级可以这样排：先处理对公网开放、且能触达客户数据的站点；再处理只展示信息的官网；最后处理纯内网系统。排序依据不是「哪个业务更重要」，而是「被拿下之后能碰到什么」。这条原则，比任何一次应急都管用。