PHP 严重漏洞影响有多大？日本首相发出警告，pixiv、BASE 等服务紧急停机
2026 年 10 月 21 日的 PHP 严重漏洞事件，让插画社区、电商平台和托育应用接连挂出紧急维护公告。pixiv、BOOTH、BASE、CoDMON 这些名字背后，是看作品、买东西、处理订单以及家长与机构沟通等日常需求。
日本首相高市早苗也发文，要求网站运营方当晚准备修复，无法及时更新时可考虑暂时停服。这次为什么值得如此紧张？把漏洞信息和企业公告放在一起，就能看清影响。
信息截至：2026 年 10 月 21 日 22:48，UTC+8。 下文维护时段均使用日本时间（JST，比北京时间快 1 小时），是公告中的安排，并非实测停机时长；是否恢复请以服务方后续通知为准。查证时 PHP 官方已经公布修复版本，白天的预告不能直接当作当前状态。
两个漏洞为什么需要紧急处理？
PHP 团队于 10 月 20 日预告安全更新，原定发布时间为 10 月 21 日 14:00 UTC，即北京时间 22:00、日本时间 23:00。两个漏洞均被评为 CVSS v4.0 9.2，Critical。
已公开的上游说明分别是：
- CVE-2026-109618：内存不足时的异常处理，可能使尚未完整初始化的数据被后续清理过程使用，进而导致远程代码执行。上游安全公告
- CVE-2026-109619：某次请求使用的内存释放后，工作进程仍可能保留相关状态，后续请求访问这些失效状态时可能导致远程代码执行。上游安全公告
对于非技术读者，关键是：攻击者可能无需登录，就能让服务器执行其指定的代码。 具体利用仍取决于运行环境和触发条件，不能据此断言所有 PHP 网站都能被一个通用请求直接攻破。
问题出在 PHP 运行时本身。只更新某个 WordPress 插件或业务依赖，不能证明服务器上的 PHP 已经修复。
从首相提醒，到企业主动停服
高市早苗的原帖要求运营者确认公开网站是否使用 PHP，并准备及时应用补丁；难以及时修复时，可以考虑暂时停止网站，降低风险。
CERT-EU 的预警也建议，无法立即完成修复的机构，应考虑将面向互联网的应用与公共网络隔离。
停止服务会打断用户操作，也会影响业务。企业宁愿暂时停止登录、下单甚至整套系统，也要先处理风险，这比单看漏洞评分更能说明事件的紧迫性。
六组官方维护公告，影响已经延伸到日常生活
以下案例均已核对服务方自己的说明。明确提到 PHP 的公告，与只写安全维护的公告，需要分别理解；后者不能直接认定受这两个 CVE 影响。
| 网站或服务 | 官方确认的暂停范围 | 公告时间与原因 |
|---|---|---|
| pixiv、pixiv 百科、pixivFANBOX 等 | 相关网站及 App 暂不可用；依赖 pixiv 账号的其他服务也可能有部分功能受限 | 10/21 19:00 至 10/22 凌晨，原因为保障安全，未点名 PHP。官方帖子 |
| BOOTH | 新登录、商品购买等功能暂停，不宜扩大描述为所有页面全部关闭 | 10/21 19:00 至 10/22 凌晨，公告提及安全性提升，未点名 PHP。官方公告 |
| BASE／PAY ID | 店铺后台、店铺浏览及下单、PAY ID App 操作和 BASE API | 开始时间已提前至 10/21 15:50，预计到 10/22 07:00；更新说明明确提及 PHP 严重漏洞。官方公告 |
| CoDMON | 包括家长 App 在内的全部服务暂停，并提供纸质出勤记录等替代模板 | 10/21 停服，预计 10/22 清晨恢复；现行公告称所用软件存在严重漏洞，未点名 PHP。官方公告 |
| Konica Minolta tomoLinks | 教育服务暂时停止，处理完成后恢复 | 10/21 的 PHP 漏洞相关公告确认暂停服务，并链接 IPA 预警，没有固定恢复时间。官方公告 |
| CyberMates | 全部内容和服务暂停 | 10/21 起预防性停机，明确提到 PHP，待修复和安全检查完成后恢复。官方公告 |
这次影响明显，是因为多个不同行业的服务同时需要暂停操作。消费者无法正常购物，商家无法管理订单，托育机构需要启用替代记录方式；平时看不到的基础软件问题，就这样变成了用户能感受到的服务中断。
BOOTH 的公告还体现了账号系统的连带影响。即使用户只想购买商品，登录服务维护也可能让整个操作流程停下来。共用账号与基础组件带来的便利，在紧急更新时也意味着共同承受中断。
社交平台上的长名单，应当如何看？
@anywhere_otaku 的整理串列出了《碧蓝幻想》《赛马娘》、pixiv、BOOTH、BOOK☆WALKER、Niconico 等许多名字。
原作者说明这是自己的整理，收集的是已经维护或即将维护的服务。它可以作为查证线索，但不能直接当作 PHP 漏洞确认名单，更不能当作被入侵名单。上表只采用已核对的官方公告，同时保留原因和功能范围上的差别。
预防性停服，不等于已经被攻击，也不等于数据已经泄露。 pixiv、BOOTH、BASE、CoDMON 和 CyberMates 在上述各自公告中，都表示当时尚未确认相关入侵或信息泄露。网站暂时不可用，本身无法证明账号安全出了问题。
修复版本已经发布，关键是确认实际运行环境
PHP 官方安全公告列出的本次修复版本如下：
| PHP 分支 | 本次修复版本 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
如果使用 Linux 发行版或主机商提供的回补补丁，应核对供应商安全公告和软件包修订号；仍在运行旧版 PHP 的系统，需要确认维护来源，或迁移至受支持版本。
网站运维人员应确认：处理公网请求的 PHP 已修复，正在运行的工作进程已加载更新，核心功能检查通过后再恢复服务。 只看到命令行版本变化，不能证明网站实际使用的 PHP 同样完成了修复。
官方说明也强调，配置调整只能缩小某些攻击路径的暴露面，无法完整替代更新。普通用户可以关注服务方的恢复通知，避免把维护状态直接理解成个人账号已经失窃。
这次停机潮让人直观地看见：一个共用运行时的安全问题，可以同时影响内容消费、交易和日常沟通。 企业承受临时中断的成本，是为了先控制风险；这正是今天这件事值得关注的地方。
