研究人员借助 AI 工具，在 PHP 运行时中发现了两个潜伏多年的严重漏洞。它们可能让未认证的远程攻击者在特定条件下执行代码，或读取 PHP 进程内存中的敏感信息。PHP 团队于 2026 年 10 月 21 日发布修复版本后，网站、政府机构和安全团队迅速采取行动。

这次事件也需要把“攻击尝试”和“成功入侵”分清。BBC 报道当时没有已确认的成功攻击；AWS 后来披露，其 MadPot 蜜罐在 10 月 17 日已记录到利用尝试，但无法确认这些尝试能否在真实系统上成功。

PHP 在网站请求中做什么

PHP 的全称是 PHP: Hypertext Preprocessor，是一种开源的服务器端编程语言。它最初由 Rasmus Lerdorf 于 1994 年创建，后来发展为构建动态网站和 Web 应用的语言。用户请求页面时，Web 服务器会调用 PHP 执行业务逻辑、读取数据，再把生成的内容返回浏览器。

餐厅的比喻可以帮助理解：顾客点汉堡相当于用户访问网站，服务员接收请求相当于 Web 服务器，厨师制作汉堡相当于 PHP 生成页面，服务员把餐点端回桌边则相当于服务器返回网页。

flowchart LR
    U[用户请求页面] --> W[Web 服务器接收请求]
    W --> P[PHP处理逻辑并读取数据]
    P --> R[生成页面内容]
    R --> B[浏览器显示页面]

PHP 常见于 WordPress、Drupal、MediaWiki 等系统，也用于 Wikipedia、网店以及 Laravel、Symfony 等框架构建的应用。Wiz 估算全球约 70% 的网站由 PHP 驱动；这个数字是研究机构对覆盖面的估计，不能据此推断每个网站的版本或配置都相同。PHP Foundation 是支持 PHP 项目的非营利组织之一。

php2shell 涉及哪两个漏洞

php2shell 是这次事件中对 PHP 核心漏洞的称呼。PHP 官方公告列出 CVE-2026-109618 和 CVE-2026-109619，两项的 CVSS 4.0 评分均为 9.2。漏洞位于 PHP 运行时，因此风险不局限于某一款 CMS 或插件。

项目内容
漏洞编号CVE-2026-109618、CVE-2026-109619
严重程度PHP 官方预告给出的 CVSS 4.0 评分均为 9.2
Calif / Patch the PlanetCalif 报告了多条可导致远程代码执行的路径；OpenAI 称 Calif 团队使用 GPT-5.6 Sol 发现一项关键缺陷，Calif 的研究记录署名 Ryan Austin
Wiz Research独立发现并报告了两项漏洞
影响组件PHP 核心运行时及处理 Web 请求的部署
潜在影响特定条件下的未认证远程代码执行，或进程内存信息泄露
漏洞高层原因潜在影响
CVE-2026-109618内存不足时，请求数据可能尚未完整初始化，PHP 就进入中断和清理流程；清理过程可能错误处理无效数据内存破坏，特定条件下可能导致远程代码执行
CVE-2026-109619当前请求的内部状态可能在底层内存释放后残留，后续请求可能在状态重置前接触到它陈旧状态被复用，可能导致内存破坏或远程代码执行
flowchart LR
    A[请求处理遇到异常状态] --> B{内部状态完整吗}
    B -->|不完整 | C[清理流程可能处理无效数据]
    B -->|状态残留| D[后续请求可能接触陈旧状态]
    C --> E[内存破坏风险]
    D --> E
    E --> F[特定条件下可能代码执行或信息泄露]

Wiz 表示，相关问题可追溯到 PHP 5.4 版本。具体暴露情况仍需核对运行版本、PHP SAPI、发行版安全更新和主机商公告。仅查看 WordPress、Drupal 或插件版本，并不能判断 PHP 运行时是否已修复。

从发现到修复的时间线

时间研究方事件
2026 年 7 月 30 日Calif / Patch the PlanetCalif 通过 OpenAI 的 Patch the Planet 计划开始 PHP 研究
2026 年 8 月 1 日CalifCalif 表示，当天发现了最初的内存不足致命错误路径和中断点，并据此找到更多远程代码执行路径
2026 年 8 月 11 日Calif向 PHP 报告第一项漏洞，并开始协调披露
2026 年 8 月 14 日Calif向 PHP 提交远程代码执行 PoC
2026 年 8 月 15 日PHP确认 Calif 提交的 PoC 按预期有效
2026 年 8 月 19 日Wiz记录发现第一项 PHP 漏洞
2026 年 8 月 20 日Wiz确认 Drupal 上存在未认证远程代码执行
2026 年 8 月 21 日Wiz确认 WordPress 上存在未认证远程代码执行
2026 年 8 月 21 日Calif向 PHP 报告第二项漏洞
2026 年 8 月 24 日Wiz向 PHP 安全团队报告漏洞
2026 年 9 月 21 日Wiz / PHPPHP 确认收到相关报告，并开始协调修复
2026 年 10 月 17 日AWSMadPot 蜜罐观察到一次疑似利用尝试，早于公开披露四天；AWS 表示尚不清楚该尝试能否在真实系统成功
2026 年 10 月 21 日PHP发布修复版本并公开披露两个 CVE
2026 年 10 月 23 日PHP发布与另一项 CVE-2026-115560 有关的信息提示，适用条件更窄

预防性下线不等于已经被攻破

根据学习笔记转述的 BBC 报道，10 月 21 日警报发布后，一些机构选择暂时关闭系统或暂停服务。这些行动属于风险控制，并不能证明它们已经遭到攻击。

机构或服务报道中的行动
Wikimedia预防性下线部分系统
芬兰政府、爱丁堡市议会、荷兰网络安全机构、日内瓦大学报道称采取预防措施
英国政府32 个网站预防性下线；报道指出它们不是大型公共服务
Orange在全球暂停部分服务
BBC部分页面下线
SoftBank暂停地震、海啸等灾害预警；报道说服务于周一恢复

报道还提到，美国 NSA 建议无法及时修补的系统考虑下线；欧盟、新加坡和澳大利亚发布了类似警报；日本首相高市早苗在 X 上呼吁当晚采取行动；Amazon 在公开披露前几天已经遇到多次攻击尝试，但网站仍正常运行。上述表述按 BBC 报道及学习笔记转述。

Cloudflare CEO Matthew Prince 的观察也由 BBC 报道转述：公开前有数千次攻击尝试，披露后 45 分钟达到数万次，两小时内达到数十万次，之后增长到数百万次。这里的数字表示观察到的尝试量，不是成功入侵量，也不是已确认受影响的站点数量。

AWS 在 10 月 17 日的蜜罐记录说明，攻击尝试可能早于公开披露。AWS 同时指出，目前无法确认这些尝试是否能在真实系统中成功。因此，BBC 报道时“没有成功攻击报告”和后来观察到攻击尝试，两者并不冲突。

AI 改变了漏洞研究的成本

Calif 的记录描述了另一条独立研究线。Ryan Austin 利用自己对 PHP 漏洞历史的了解，请 LLM 协助寻找触发可控内存不足错误的方法，再用 AI 研究助手检查内存分配、致命错误和清理路径。Calif 表示，这些工作归纳出了可复用的中断模式，并帮助发现更多问题。OpenAI 称 Calif 团队通过 Patch the Planet 项目使用 GPT-5.6 Sol 发现一项关键缺陷；Calif 的研究记录署名 Ryan Austin。Wiz 则独立发现并报告两项漏洞，研究中使用了 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol；Wiz 称 Gemini 4 Argon 帮助完成漏洞发现、利用研究、攻击检测和补丁验证。

以上内容来自研究方和厂商的披露，并非对不同 AI 模型的受控比较。AI 没有独自完成研究：研究人员提供历史背景、引导分析、验证发现、判断影响、与 PHP 维护者协调披露，并检查修复结果。加速代码分析的能力同样可能帮助攻击者更快把漏洞信息转成攻击工具。

漏洞本身并不新，变化的是我们发现它们的能力。

Ryan Ko 在报道中谈到的老问题也在这里显现：不少旧软件最初优先满足功能需求，安全性投入不足。旧代码不会因为运行多年就自动变安全；AI 让过去难以发现或验证的问题更容易进入现实风险。

资产清单不能只看网站

PHP 还可能被打包在网络设备、负载均衡器、嵌入式设备和管理界面中。NCSC 也提醒组织检查可能包含 PHP 的第三方设备和服务，并持续关注供应商公告。

flowchart LR
    A[网站与 CMS] --> P[PHP 运行时]
    B[内部业务系统] --> P
    C[网络设备与负载均衡器] --> P
    D[嵌入式管理界面] --> P
    E[托管服务与第三方产品] --> P
    P --> F[核对版本、补丁与厂商公告]

因此，资产盘点要覆盖自有服务器、容器镜像、共享主机、网络设备和第三方服务。对于托管环境，运营者还需要向服务商确认实际运行的 PHP 版本及补丁来源。

个人用户与网站所有者分别要做什么

对象应对方式
普通用户通常不需要自行操作；留意服务提供方通过官方渠道发出的安全通知，例如要求重设密码的通知，并警惕借漏洞名义索要密码或验证码的钓鱼信息
网站所有者与运维团队盘点所有处理 Web 请求的 PHP 部署，优先修补公网系统；确认实际运行版本，不只看配置文件或代码仓库
WordPress 等 CMS 站点更新 CMS 或插件不能替代 PHP 运行时补丁；向主机商确认已打补丁，并确认工作进程已经重启
旧版本或设备产品PHP 8.1 及更早版本不再由 PHP 项目常规维护。PHP 为自行编译或没有长期支持供应商的用户提供了 7.4、8.0 和 8.1 的最小源码回补；使用发行版软件包的团队仍需确认供应商是否包含 PHP2Shell 修复
暂时无法修复的系统官方缓解措施只能降低部分攻击路径的风险，不能代替完整修复；无法有效缓解时，考虑隔离或临时下线

PHP 安全公告列出的修复版本为 8.5.12、8.4.27、8.3.36 和 8.2.35。PHP 在 10 月 26 日重新构建的 Windows 软件包增加了 -1 后缀，用于修复另一项 Brotli 漏洞 CVE-2026-111497；PHP 运行时版本没有变化。使用发行版或长期支持版本的团队，应确认供应商已包含 PHP2Shell 修复。PHP 官方说明，升级至修复版本才是完整修复。

安全研究员 Ken Munro 将更新 PHP 比作运行一次 Windows 更新。对托管站点来说，通常需要联系主机商确认运行时已经修补，而不是只更新网站后台。

学习笔记指出，全球补丁部署速度虽在提升，实际推进仍比预期慢；随着技术细节公开，之后几周的攻击尝试可能继续增加。

英国 NCSC 建议组织盘点所有运行 PHP 的系统、优先更新公网服务；若暂时不能更新，也无法落实临时缓解，应考虑让系统离线。修复前还应评估是否存在入侵迹象。AWS 建议调查起点至少回看至 10 月 17 日。

flowchart LR
    A[盘点 PHP 运行位置] --> B[核对版本与补丁来源]
    B --> C[优先修补公网服务]
    C --> D[重启工作进程或设备]
    D --> E[确认实际运行版本]
    E --> F[检查日志与异常变更]
    F --> G[跟进供应商更新]

PHP 后续提示（10 月 23 日）

PHP 在 10 月 23 日发布了关于 session 上传进度的提示，涉及另一个编号 CVE-2026-115560。只有在应用将 session.serialize_handler 配置为 php_binary 或 php_serialize，之后又在调用 session_start() 前通过 ini_set() 于运行时切换为 php，并且仍启用 session 上传进度时，才可能触发该问题。PHP 当时建议相关部署临时关闭 session 上传进度；完整公告计划随下一次常规修复发布。

这不是最初两个漏洞的第三个名称。是否受影响，应依据 PHP 后续公告和自身配置判断。

这起事件留下的提醒

php2shell 同时揭示了基础运行时漏洞、AI 改变漏洞研究与利用成本、以及组织资产可见性不足这几个问题。修补 PHP 本身是首要动作；确认补丁已经进入正在处理请求的运行时，并检查设备、托管服务和第三方产品，才能避免只更新了表层应用却遗漏真正受影响的组件。

常见问题

PHP2Shell 是否意味着所有 PHP 网站都已被入侵？

不是。漏洞影响面广，不等于每个网站都遭到成功攻击。应先确认运行时版本与补丁状态，再按日志和资产范围调查可疑活动。

只更新 WordPress 或插件够吗？

不够。修复位于 PHP 运行时。还要确认主机、容器或设备上实际处理请求的 PHP 版本已更新，并按需重启工作进程。

AWS 记录到利用尝试，能证明攻击成功了吗？

不能。AWS 记录的是蜜罐上的尝试，并表示无法确认这些尝试能否在真实系统中成功。运维团队可从 2026 年 10 月 17 日起检查相关日志和变更记录。

参考资料

安全测试白盒测试背靠背测试本地化测试边界测试
分享