据 ITmedia 报道，10月21日晚，日本首相高市早苗在 X 上发出紧急呼吁：请网站运营者准备尽快安装 PHP 安全补丁；如果难以及时更新，临时停止网站也是降低风险的一种办法。

风险在于，在满足利用条件的运行环境中，攻击者可能无需登录，只凭特制网络请求就读取服务器进程中的敏感信息，甚至让 PHP 或 Web 服务进程执行恶意操作。问题出在许多网站共同依赖的 PHP 核心引擎：它在服务器上组装网页、处理用户提交的数据，所以上层网站代码即便没有漏洞，也可能受到影响。攻击能造成多大损害，还取决于运行环境、服务进程的权限和隔离措施。

这次应急已经影响到政务、公共服务和日常使用的网站。据路透社的名单，荷兰国家网络安全中心、鹿特丹港、芬兰政府公共 Web 服务等采取了预防性下线措施，德国联邦 IT 服务商 ITZBund 也关闭了若干网站。日本财务省暂停部分网页与服务；ITmedia 报道列出的维护对象还包括 BASE、pixiv、Cygames 等相关网络服务。这些是当时的停站或维护记录，部分服务随后恢复，不能由此推断它们都遭到了入侵。

影响还传到了支撑这些网站的平台。维基媒体基金会主动停用了许多支撑服务，包括 Toolforge、Cloud VPS 中的相关服务，同时设法避免百科主站停机。日本多家托管服务商也紧急修补：有的暂停客户网站，有的暂停自身管理后台、保持客户服务器运行。各家的做法，决定了用户能否访问网站、登录后台或等待服务恢复。

W3Techs 的统计显示，在服务端语言能够被识别的网站中，约 70% 使用 PHP。这说明共同依赖的范围很广，并不是相应比例的网站已被攻破。在 Reddit 的一则讨论中，有用户追问自己的浏览器、邮件客户端和个人云盘是否也受影响。这里首先要分清责任：这些网站的 PHP 更新由运营方或托管商在服务器端完成；普通访客应关注所用服务的正式通知、服务恢复情况，以及服务商要求的后续账户处置。

在本次响应中，OpenAI 通过 Patch the Planet 计划参与了维护者与服务商之间的协同，并开源了用于排查受影响版本的检查工具。AI 帮助研究者验证了复杂的攻击路径，而让补丁真正保护到网站，还需要整条服务链一起行动。

AI 在漏洞研究中的实际分工：专业经验与模型辅助

根据 OpenAI 的官方说明，在 Patch the Planet 计划中，安全公司 Calif 使用 GPT-5.6 Sol 发现了严重漏洞；Wiz 团队也独立发现并报告了这两项漏洞；而最终的修复与版本发布则由 PHP 维护者主导。

回顾漏洞背景可以发现，底层隐患此前并非毫无线索。根据 PHP 基金会的复盘通告，在由主权技术机构（Sovereign Tech Agency）资助、Quarkslab 团队执行的审计中，维护人员在修复相关问题时就注意到了内存限制（OOM）路径存在异常。但在当时，尚无确凿证据证明该路径可转化为远程代码执行，加之修改核心内存管理逻辑可能影响第三方扩展的兼容性，原先依赖共识的决策方式又难以在几套取舍方案中作出选择，有限人手下的修复工作曾反复搁置。

在本次发现过程中，模型发挥了辅助分析与适配的作用。根据 Calif 研究员 Ryan Austin 的技术分析，他的初始发现使用的是公开可得的模型，关键突破在于结合了个人对多年前 Stefan Esser 历史漏洞的专业理解，主动引导模型在代码库中检索能够绕过请求限制并触发异常中断的特定模式。他指出，理解目标系统的架构历史依然不可替代，当前模型并不能仅靠简单提示直接找出所有漏洞。

而在 Wiz 的研究实践中，团队结合了内部的 Wiz Atlas 平台以及 Gemini 4 Argon 和 GPT-5.6 Sol。Wiz 在报告中称，单名研究人员在一周内完成了以往团队需要数月的工作，并自述模型协助其在数小时内完成了跨多个应用的利用适配。在实际操作中，面对不同 PHP 版本与不同应用所展现的内存布局差异，模型辅助研究人员分析运行报错并调整利用参数，降低了针对不同部署环境进行逐一适配试错的人工门槛。在 Hacker News 的讨论样本中，评论者 asbv-1qq 对公告的宣传口吻提出质疑，并追问未公开的模型搜索与利用开发计算成本。这为阅读上述提效自述提供了另一个需要关注的维度：研究花了多少时间，以及为此消耗了多少计算资源。

此外，OpenAI 公告中 提及的 10 亿美元支持，属于其面向一线防御者的 Daybreak 计划既有模型访问补贴，主要用于支持承担关键服务防护但安全资源有限的机构，并非针对本次漏洞临时拨付的专项资金。OpenAI 表示，对维护者的支持还包括模型访问、直接工程协助、Codex for OSS 订阅，以及对 Rust 基金会等项目的赞助，各项目自行决定优先事项。公告也指出，拦截恶意用途的分类器可能阻碍正当安全研究，需要在防止滥用与让防御者获得足够能力之间持续调整。

请求、中断与错乱指针：两项内存漏洞的成因与后果

若将 PHP 解释器处理网络访问的过程比作一个流水线工位，其内部运行机制便更容易理解。

在使用常驻 PHP 进程的网站中，需要 PHP 处理的网页或表单请求，会被 Web 服务器交给一个 PHP 工作进程（Worker）。Worker 会在为该请求分配的独立堆内存（即“工作台”）上放置零部件：解析提交的数据、构建内部变量索引。脚本处理完毕后，清理程序将工作台清空，常驻待命的 Worker 则接着处理下一个到来的网络请求。

本次披露的两项漏洞，分别利用了工作台上数据刚刚拼装一半、以及旧请求工作台刚被释放时的异常中断。

CVE-2026-109618：内存限制中断与未完全初始化的数据误用

根据 PHP 官方安全通告 与 CERT-EU 的技术通报，该漏洞的 CVSS 评分达到 9.2。PHP 内部设置了单次请求的内存配额限制（memory_limit），用于防范资源耗尽。当特制请求促使内存分配触及配额红线时，底层机制会直接中断当前的解析执行。

根据 CERT-EU 的分析，该漏洞的根因在于：请求被内存耗尽异常强行打断时，某些内部数据结构尚未完全初始化；而随后触发的请求清理逻辑却误将这部分未完成初始化的数据当作有效对象进行处理与释放，进而破坏了内存状态。

CVE-2026-109619：旧请求释放后的悬垂状态复用

根据 第二项官方漏洞通报 与 CERT-EU 说明，CVE-2026-109619 的根因源于跨请求的残留状态。

当一个请求发生致命错误被迫终止后，该请求占用的工作台内存会被释放。但在受影响版本中，引擎内部的部分全局状态依然保留了指向该内存区域的引用。后续由同一个 Worker 进程处理的新请求在尚未重置该状态前，便可能误用这些悬垂指针，导致访问已经失效或被新数据占用的内存。

内存错误引发的后果

这些内存错误的后果主要包括两类：

1. 敏感内存泄露（Memory Disclosure）：当失效或残留的内存指针被引擎误当作合法数据输出（例如反映在响应头或 Cookie 中）时，攻击者无需取得执行权限，便可能直接读取到进程内存片段。这些数据可能包含其他请求或服务器进程驻留的敏感信息，如会话凭证、API 密钥或密码。
2. 远程代码执行（RCE）：程序不只用内存存放用户内容，还依靠其中的对象引用等内部数据决定接下来处理哪个对象、采取什么操作。若攻击者精心构造请求数据破坏了内存结构，让可控数据被误当成有效的内部结构，后续操作就会走错；通过复杂的利用链，攻击者可进一步控制执行流程，诱导解释器执行注入的恶意逻辑。攻击者获得的是 PHP 或 Web 服务进程已有的权限；影响范围也取决于该运行身份的权限与隔离。

在网络安全机构 Wiz 的技术解析中，研究人员展示了这两类危害的演进过程：

请求中断、状态残留与 Worker 进程是否存活之间的关系，可通过下方流程进行推演：

mod_php 与 PHP-FPM：运行架构对利用路径的影响

PHP 官方与 CERT-EU 通报 指出，传统的 Apache mod_php 是风险最高的部署模式，而现代广泛采用的 PHP-FPM 则展现出不同的利用条件。

两者差异的核心在于 Worker 进程在异常后是否存活并继续承接后续请求：

• 在 Apache mod_php 架构下，PHP 作为 Apache 子进程内部模块运行。官方通报指出，在默认配置下，未经身份验证的请求可在任何应用代码执行前触发启动阶段的内存错误并演示远程代码执行。在该模式下，即使启动解析发生异常中断，请求注销流程仍会执行，存活的子进程可能继续复用受损状态。但这属于特定演示路径，并不意味着任意易受攻击的 mod_php 都会被单个请求必然接管。
• 在 PHP-FPM 架构下，独立进程池管理 Worker。若在请求启动早期发生致命错误，FPM 的机制会使当前 Worker 进程直接退出，阻断了部分基于启动期状态残留的利用路径。然而，如果请求通过了启动阶段，在业务执行阶段（如应用内部特定的数据反序列化或错误处理逻辑）触发内存中断，Worker 仍可能继续存活并处理下一个请求，研究人员同样证实了 PHP-FPM 下应用执行阶段的远程代码执行路径。

协调披露过程与披露前后的应对

负责任的协调披露旨在为开源维护者、Linux 发行版与基础设施服务商预留准备防护和测试补丁的时间。这一流程并不等同于所有参与方均签署保密协议，也无法保证在细节公开的一刻所有用户都能无缝升级。

根据 PHP 基金会的事件记录 与行业媒体梳理，本次协调披露经历了多次时间调整与突发状况：

1. 编号与评分流传：在原定公开时间的两天前，两个 CVE 编号与 10.0 的威胁评分（实际评分为 9.2）在技术论坛与社交平台开始流传，但当时并未泄漏具体技术细节。
2. 发布时间提前：为应对外界关注并平衡分发准备时间，PHP 团队提前发布了预公告，并将正式补丁发布时间提前了一天。
3. 演示视频误发：在预告发出后，参与挖掘的安全公司 Calif 误公开了一段验证漏洞的演示视频；尽管随后被删除，但视频已被第三方留存并传播，展示了部分漏洞细节。
4. 镜像提前发布：在协调发布时间前约六小时，容器服务商 Chainguard 构建并推送了包含修复的容器镜像。
   • PHP 基金会立场：基金会在复盘中指出，提前公开修复后的二进制文件使攻击者得以通过二进制比对分析具体修补位置，打破了多方协同的步调。
   • Chainguard 回应：根据 The Register 的报道，Chainguard 首席执行官在看到 PoC 扩散与相关攻击活动报告后，决定提前向用户发布补丁以提供保护，并在发布的同时通报了协调群组。

在攻击态势方面，路透社引述亚马逊安全主管 CJ Moses 的说法 指出，在漏洞公开披露前数日，其部署的蜜罐系统便捕获到了匿名探测尝试。虽然安全团队发现漏洞的时间更早，且尚无法确定早期探测是否曾成功侵入真实站点，但这表明在正式披露前网络上已有尝试性攻击。随后，Cloudflare 官方技术博客记录 表明，其防护系统在披露前后持续监测到攻击流量，并观察到攻击者不断变换载荷试图绕过防护规则。

五阶段全球协同与长期安全路径

面对跨越整个互联网生态的基础软件漏洞，OpenAI 在公告中 表示本次 PHP 漏洞只是其已发现并正在着手修复的多个重大安全隐患之一；该机构预期未来由 AI 辅助发现的漏洞将大幅增加，因此需要一套能够重复执行、随能力提升而扩大覆盖的协同响应机制，并据此提出了“五阶段响应”流程，以反映从一份代码修改到全球网站实际获得防护的完整链条：

1. 验证并修复上游漏洞：由维护者与研究团队确认问题成因，并测试防御方案。这不仅需要验证补丁本身的有效性，还要进行对抗性测试以排查变体和潜在绕过方式。
2. 为关键防护方留出准备时间：由维护者依据各组织的防护职责、采取行动所需时间以及处理敏感信息的能力决定受邀对象。分发方需将补丁适配至旧版本，托管商需测试缓解方案，安全厂商需验证 Web 应用防火墙（WAF）的拦截规则。参与方获得的信息视需求而定，范围从包含失陷指标的网络日志到更敏感的可运行验证程序；由于共享细节可能反向泄露漏洞线索，扩大覆盖范围与防范泄密风险之间需要审慎权衡。
3. 联合政府机构保护关键系统：协调各国网络安全机构，协助将防御指导传达至关键基础设施和公共部门。
4. 推动下游产品准备就绪：随着补丁趋于稳定，扩大至更多下游厂商与托管平台，准备可直接部署的更新包以弥补覆盖缺口。
5. 发布公开指导并支持实施：正式公开漏洞信息与补丁，并持续指导运维人员进行升级验证和应急处理。

在这一链条中，各环节之所以需要时间，是因为仓促推送未充分验证的补丁可能破坏广泛的业务兼容性。若在此期间发生利用在野传播、信息意外泄露、公开补丁暴露缺陷或修复推进受阻导致风险上升，协调团队便需要重新评估并调整披露时间表。

从长远来看，OpenAI 公告中 提出了四项基础安全演进方向：一是在开发源头采用更安全的默认配置并规避高风险模式；二是将关键组件迁移至内存安全语言，以从根本上消除常见类别的内存安全错误；三是通过形式化验证，在明确假设下以数学证明关键组件满足指定的安全属性；四是建立更严格的沙箱隔离机制，使处理不可信文件或媒体的软件受限运行，即便处理程序被攻破，也能限制其造成的损害。AI 可以在辅助代码理解、生成迁移草稿与编写测试用例中提供支持，但依然需要工程测试与专家审查来确保业务行为一致。此外，公告还就极端场景征询意见：对于政府或其他运维方拥有或获授权管理的系统，如果已失去管理员访问权限，是否应在特定条件与保障措施下利用漏洞进行紧急修补。这仍是需要讨论授权与安全边界的设想。

与此同时，PHP 基金会强调，虽然 AI 工具大幅提升了漏洞报告的产出速度，但团队还处理了百余份无效、重复或无法复现的报告；报告筛选、补丁的架构权衡以及兼容性评审依然依靠经验丰富的核心维护者。随着报告数量增加，开源项目在人工审查与工程维护上的资源瓶颈愈发突出，持续的资助与人力投入依然是维持基础软件安全的基石。

从官方补丁到站点安全：版本支持与缓解措施的局限

当官方发布安全补丁后，还要经过下游打包、托管商部署，最后确认真正对外服务的 PHP 已经更新。Hacker News 用户 spenvo 描述过等待镜像的经历：即使新版本标签已经出现，所需架构的官方容器镜像也可能尚未构建完成。这个当时的个人经历，具体说明了“上游已发布”和“我的部署能用上”之间的时差。

托管商的维护也会产生不同影响。IDC Frontier 的 Zenlogic 公告计划在日本时间10月21日22时至22日18时升级 PHP、安装补丁。作业期间会停止 Apache，因此客户网站与 Roundcube 网页邮箱无法访问，邮件软件收发和 FTP 不受这次维护影响。GMO Pepabo 旗下 Lolipop 的维护页也列出了传统托管产品的客户站点、用户专用页面、FTP、旧网页邮箱等暂停项目；其其他产品的可用功能则分别说明。

XServer 的公告展示了另一种情况：暂停自身官网、管理后台等功能，同时保持客户托管服务器运行并推进修补。10月22日日本时间9:30的进展称，管理功能已部分恢复；此前6:45的进展称，PHP 8.2—8.5 的目标服务器已完成补丁应用，旧版本另行处理。因此，看到“服务商维护”，还要继续看它停的是管理入口，还是客户实际使用的服务。

控制权分散也会拉长恢复时间。维基媒体基金会说明，Toolforge、Cloud VPS 内部分服务由志愿开发者管理，使用者能够选择 PHP 版本；基金会需要联系相应服务所有者协同修补，这些服务可能恢复得更慢。

1. 活跃版本与遗留环境的差异

PHP 官方为当前处于受支持生命周期的四个分支发布了正式安全版本：8.2.35、8.3.36、8.4.27 与 8.5.12。

对于已结束生命周期（EOL）的旧版本，官方不再提供常规安全维护。根据 路透社引述 Censys 的测绘数据，在观察到且能够识别出 PHP 版本的 260 万台主机样本中，约 150 万台在当时运行着没有官方现成修复版本的分支。在技术社区的早期讨论中，V2EX 讨论区有开发者 针对大量仍运行在 PHP 7 环境中的老旧业务表达了现实焦虑。虽然官方不再为已停更分支提供常规安全发布，但这并不等同于任何修补都没有：面对此次严重威胁，PHP 安全团队破例为自行编译的用户发布了针对 PHP 7.4、8.0 与 8.1 的最小源码回移（Backport）补丁，部分 Linux 发行版与长期支持（LTS）供应商也会按发行版和支持范围提供维护包；但在缺乏持续运维的遗留系统上，跨大版本升级涉及语法废弃、扩展失效及应用依赖等兼容性负担，难以在短时间内迅速落地。

2. 临时缓解措施的适用条件与局限

对于无法立即完成补丁升级的生产环境，CERT-EU 与安全建议提出了一些临时配置调整，但这些手段各自具备严格的适用前提，不能替代完整升级：

• 禁用上传进度（session.upload_progress.enabled = 0）：此项设置能够阻断已确认的基于 Session 上传进度的攻击链，但必须在请求解析前生效并重启所有工作进程，且不能覆盖其他变体。
• 取消单请求内存配额（memory_limit = -1）：该设置通过移除单个请求的内存上限，避免执行流程因触发配额而陷入异常中断清理路径，但这是以牺牲可用性保护为代价的。一旦取消单请求配额，异常请求失去了 PHP 单请求配额的约束，运维团队必须在系统层结合容器配额或 cgroup 内存边界来防范整机资源耗尽。这种边界不能随意替换为 RLIMIT_AS 或 RLIMIT_DATA 限制，因为它们同样会在进程级别触发底层的内存分配失败；并且若物理内存耗尽导致底层系统分配失败，仍可能触及脆弱的异常清理路径。

生产配置的调整需要专业评估与测试；临时措施减少特定路径的暴露，完整修复仍要更新 PHP。

版本检测工具的使用定位与盲区

在披露同时，OpenAI 开源了一款轻量级的 PHP 版本检测工具 php2shell-checker。该工具主要用于对单个 URL 或本地环境的 PHP 二进制进行初步版本分诊，并不具备自动化摸排全网或大批量资产的功能。

其网络探测机制默认仅发送 HTTP HEAD 请求，仅当服务端返回 405 或 501 状态码时才会回退到 GET；工具不跟随 HTTP 重定向，也不读取或解析响应正文。若连接失败、目标未暴露版本标头、或遇到未收录的版本分支，工具均会返回 UNKNOWN。

拿到旧版本、修复版、没有版本、或供应商回移补丁的信息时，版本工具会给出不同结果。它们对应的证据强度也不同。

工具的使用入口

在需要核验自身管理的站点时，读者可在支持 Codex 的环境中按照仓库说明安装对应技能：使用 phpcheck-url 检测公开 URL，或在具备服务器权限时使用 phpcheck-server 核对实际承接 Web 流量的 PHP 版本。

如果选择在本地直接通过 Node.js 运行，需先获取完整仓库代码并在终端进入该仓库根目录，确保本地已安装可用的 Node.js 环境，随后针对自身管理的域名或本地环境执行命令（https://example.com 仅为占位示例，需替换为自身维护的站点；该工具仅进行版本比对，不会向目标发起实际漏洞探测）：

node phpcheck.js "https://example.com" --json
node phpcheck.js --local --json

版本比对的四个客观盲区

在实际运维评估中，版本比对结果不能直接等同于系统的安全证明，需要注意以下盲区：

1. 响应头隐藏与未暴露：生产系统常关闭 expose_php 或在网关层剥离版本标头，导致工具因无法提取版本信息而返回 UNKNOWN。UNKNOWN 代表当前信息不足以判断补丁状态。
2. 发行版源码回移（Backporting）：Linux 发行版回移补丁时，可能保留原上游版本号，通过完整软件包修订号区分更新。工具只比较上游版本，可能将已修补的包误报为 VULNERABLE；应结合供应商公告核对完整修订号。
3. CLI 命令行与 Web 运行时差异：在终端直接执行 php -v 获取的是当前命令行环境调用的二进制版本，而 Web 服务器（如 Nginx/Apache）后端实际调用的可能由不同 PHP-FPM 进程池或独立容器驱动，两者的具体版本与构建可能并不一致。
4. OK 状态仅代表版本号高于内置阈值：该状态基于“后续稳定补丁已包含修复”的假设，工具本身并不对漏洞是否可在实际内存中被触发进行独立检验。

运维团队应依据操作系统或发行商的官方安全公告，核对完整软件包版本与承接 Web 流量的实际运行构建。完成升级后，按供应商流程重启相关 PHP-FPM 或 Apache 进程，或重新部署容器镜像，确保服务已切换到修复版本。

软件升级用于堵住漏洞；此前若已被入侵，仍需排查并处理遗留痕迹。修复期间，服务商的全事务 Web 应用防火墙规则有助于缓解已知载荷，但不能替代底层补丁。若无法及时更新且风险较高，可结合自身网络架构，考虑将受影响服务暂时与公网隔离。