所有文章
AI

PHP 漏洞 CVE-2026-109618:紧急补丁之夜,面板连夜救火

PHP 漏洞 CVE-2026-109618 与 109619 今晚评为 CVSS 9.2。RunCloud、Prostack、Cloudflare 怎么应对,以及你如何自查打补丁。

PHP CVE-2026-109618 patch: a small blue elephant figurine with a band-aid next to a tiny wrench

今晚,PHP 紧急发布了两个被称作 php2shell 的严重漏洞的修复版本。如果你在 VPS 面板上自建 WordPress、博客、AI 前端或任何 PHP 应用,PHP 漏洞 CVE-2026-109618 和 CVE-2026-109619 就是你睡前该处理的事。PHP 安全团队给出的评分是 CVSS v4.0 9.2——不是网上流传的 10.0。官方明确说没有完整的配置缓解手段,更新 PHP 才是唯一稳妥的做法。

下文按北京时间(UTC+8)梳理今晚发生了什么、公告原文怎么说、RunCloud 和 Prostack 等面板怎么连夜应对,以及你自己怎么自查。必要时会附带 UTC。

PHP 漏洞 CVE-2026-109618 时间线(北京时间)
PHP 漏洞 CVE-2026-109618 / 109619 在 2026-10-21 的时间线(北京时间)。整理于 23:00 UTC+8。

今晚发生了什么

10 月 20 日,漏洞细节在社交媒体和 Hacker News 上提前泄露,原定 10 月 22 日的披露被打乱。PHP 基金会 X 账号预告:21 日 14:00 UTC(北京时间 22:00)发布紧急版本,两个漏洞均为 CVSS v4.0 9.2。主机商和 WAF 厂商更早动手。

北京时间 11:02(03:02 UTC),Cloudflare 默认启用了面向所有套餐(含免费版)的 WAF 规则,比公开披露大约早 9 小时。15:43,Cloudflare CTO Dane Knecht 在 X 上写道:Cloudflare 后面的 PHP 站点已有针对已知利用方式的规则,“we are seeing early attacks emerging”(已看到早期攻击),并强调这只是 STOPGAP(权宜之计)(原帖)。

Cloudflare 关于 PHP 漏洞 CVE-2026-109618(php2shell)的 WAF 博客截图
Cloudflare 博客:WAF 规则自 03:02 UTC(北京时间 11:02)起对所有套餐默认生效。截取于 2026-10-21 23:00 UTC+8。

大约 16:00,RunCloud 在全部服务器上关闭了 session.upload_progress,并在 16:58(08:58 UTC)发布社区公告。截至今晚 23:00,该社区页只显示 “We are in maintenance mode due to PHP Update”;下文对 RunCloud 公告的引述来自搜索引擎缓存——原页当前不可用,Wayback Machine 也没有存档。

RunCloud 社区站因 PHP 更新维护中(CVE-2026-109618)
RunCloud 社区站处于 PHP 更新维护。截取于 2026-10-21 23:00 UTC+8。
RunCloud 关于 PHP 漏洞 CVE-2026-109618 的公告(搜索引擎缓存重建)
RunCloud 社区公告重建图(据搜索引擎缓存;原页暂不可用)。说明时间 2026-10-21 23:00 UTC+8。

托管面板的客户今晚通常还会收到产品内通知或邮件。若你用 RunCloud,请直接看控制台和来自服务商的邮件,确认自己技术栈的补丁状态——不必等社区站恢复。

大约 21:35–21:40,php.net 发布了 8.5.12、8.4.27、8.3.36、8.2.35,比原定的 22:00 更早。Prostack 随后更新(英国时间 15:30,约北京时间 22:30):所有 Cito 服务器已打补丁。各面板连夜维护,所以今晚有些后台看起来像“挂了”。

两个 CVE 到底是什么

漏洞在 PHP 运行时本身。只升级 WordPress、主题或插件没用。依据 php.net 安全公告 以及 GitHub 公告 GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp:

  • CVE-2026-109618——内存耗尽导致的 RCE。 PHP 在请求初始化中途内存不足时,可能留下半初始化数据,清理阶段却把它当有效数据。已确认的触发方式包括仍落在常规限制内的畸形 multipart 上传。官方认为 Apache mod_php 风险最高;FPM 仍被视为可能受影响。
  • CVE-2026-109619——残留全局状态导致的 RCE。 上一个请求的状态可能在内存释放后仍被同一个工作进程的后续请求用到。已确认的路径包括默认开启的 session 上传进度(无需调用 session_start()),以及 PHP 8.5 上的 fatal error backtraces。
php.net 关于 PHP 漏洞 CVE-2026-109618 的安全公告
php.net 安全公告列出 CVE-2026-109618 与 CVE-2026-109619。截取于 2026-10-21 23:00 UTC+8。

影响(据公告):未认证远程代码执行,权限为 web 工作进程。NVD 已收录(CVE-2026-109618),分析状态仍为 Received。截至北京时间 10 月 22 日 01:15,两个 CVE 都不在 KEV——CISA 最新目录仍是 10 月 21 日 14:04 UTC 的版本(KEV 目录)。

受影响与修复版本

请在当前大版本分支内升级到对应修复号,不必强行跳到 8.5。使用发行版软件包的,请看厂商公告里的包版本——Ubuntu 等常会保留上游版本号、只改包修订号。

分支受影响修复版本官方支持
8.5< 8.5.128.5.12至 2029-12-31
8.4< 8.4.278.4.27至 2028-12-31
8.3< 8.3.368.3.36至 2027-12-31
8.2< 8.2.358.2.35至 2026-12-31
8.1 / 8.0 / 7.4受影响无正式版;仅有最小源码补丁已停止支持
7.3 及更早 / 5.x研究者与 CERT-FR 视为受影响仅厂商回移(若有)已停止支持

来源:GHSA、php.net。NVD 结构化数据列的是 8.2–8.5;“自 PHP 5.4 起”的说法来自研究者与 CERT-FR,并非 CNA 的结构化产品列表。

AI 找出了打中大半个互联网的漏洞

对关心 AI 的读者,这一点值得单独说。据 OpenAI《Patch the Planet》 与北京时间 22:04 的 @OpenAI 帖子,OpenAI 的模型帮助该计划下的研究者发现了 PHP 的严重漏洞。合作方 Calif 使用了 GPT-5.6 Sol;Wiz 也独立发现并报告了这两个漏洞。OpenAI 称约用两个月协调维护者、研究者与厂商(含 Cloudflare、Wiz),因为引擎改动很复杂;并称与美国白宫的 Super Intelligence Force、ONCD、CISA 以及国际伙伴进行了沟通。

OpenAI 总裁 Greg Brockman 于北京时间 22:58 发布 X Article《Towards securing the internet》(帖子),称 php2shell 是近年来最严重的开源漏洞之一,并提到原定披露日是 10 月 22 日,因泄露提前到 21 日。影响面用数字说:W3Techs(2026-10-21)显示,在服务器端语言可识别的网站中,69.3% 使用 PHP——大约四分之三。使用 PHP 的网站里,约 35% 仍跑在 PHP 7 或 5(27.0% + 7.7%),今晚官方不修这些版本。

和「OpenAI 联系了白宫」这条线可以放在一起的一个事实:whitehouse.gov 是 WordPress 站点(首页 HTML 中有 200 多处 wp-content 引用),边缘响应头也符合 WordPress VIP。补丁由 Automattic 这边处理。我们不声称它今晚是否曾受影响或是否已打补丁——只陈述它跑在 WordPress/PHP、并由托管方负责升级这一点。

政府侧提醒,包括日本

北京时间 20:55:59,日本首相官方 X 账号 @takaichi_sanae 发帖:请确认公开网站是否使用 PHP,为日本时间 23:00 发布的补丁做好准备;若难以迅速打补丁,暂时停止网站也是降低风险的办法之一。账号简介写明总理在任期间部分帖子由宣传工作人员发布,因此本文表述为「首相官方账号发帖」,不臆测是谁亲手输入。我们最近一次经 X API 读取(约北京时间 23:05)的数据约为:浏览 2070 万、转发 5.24 万、点赞 17.07 万。

日本首相官方账号呼吁尽快修补 PHP 漏洞 CVE-2026-109618 的帖子
@takaichi_sanae 帖子重建图(x.com 阻止无头浏览器截图)。数据约 23:05 UTC+8。来源:X API。

帖文措辞与日本国家网络统括室账号 @cyber_forecast 当天 12:01、20:44 的两条提醒高度一致。政府首脑官方渠道在同一天转发技术侧告警,这种情况并不常见;技术内容本身来自 NCO。

各平台做了什么

关闭 session.upload_progress 只能挡住 CVE-2026-109619 已确认的一条路径,对 CVE-2026-109618 没有作用。PHP 公告写得很清楚:没有完整缓解。

平台今晚的缓解谁能打到补丁旧版本
RunCloud关闭 session.upload_progress;可选 NGINX multipart 模板8.2+ 自动推送(缓存时 Native/Docker/LSAPI 仍 pending)不提供 8.1 及更早的补丁包,需切到 8.2+
Prostack保持关闭 upload_progress;持续推送补丁Cito:全部已修;回移 5.6–8.4cPanel 路径:自 7.4 起回移;低于 7.4 必须升级
cPanelEasyApache 4 25.91ea-php74 至 ea-php85回移到 7.4
Plesk Linux8.2–8.5 的 PHP 包8.2.35 / 8.3.36 / 8.4.27 / 8.5.127.4–8.1 与 Windows:仍在开发
LaravelCloud、Vapor 自动;Forge 手动PHP 8 应用无法升级则应按官方建议关机
Cloudflare(WAF)默认托管规则 + 全事务检测含免费版在内的所有套餐权宜之计——仍须打 PHP 补丁
Prostack 关于 PHP 漏洞 CVE-2026-109618 补丁推进的更新
Prostack 10 月 21 日 15:30 更新:Cito 已打补丁并回移至 PHP 5.6。截取于 2026-10-21 23:00 UTC+8。

发行版方面(截至发稿):Debian 已为 Trixie 的 php8.4 发布 DSA-6574-1。Ubuntu 跟踪器将两 CVE 标为 Critical;不要把它和 10 月 19 日的 USN-8936-1 混为一谈,那是别的漏洞。Red Hat 在 Bugzilla 2556842 跟踪;正式 RHSA 本文未能核实。PHP 官方称 remi 源当天不会更新。

自己怎么查、怎么补

  1. 确认实际版本:php -v,再临时放一个 phpinfo()(命令行与 FPM 经常不是同一个)。目标:在本分支达到或超过 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。
  2. 查看上传进度:php -i | grep session.upload_progress.enabled,并以 Web SAPI 为准。在 php.ini 写 session.upload_progress.enabled = Off,或在 FPM pool 写 php_admin_flag[session.upload_progress.enabled] = off,然后重启工作进程。ini_set() 和 .user.ini 太晚。
  3. 仅 PHP 8.5:打补丁前再设 fatal_error_backtraces=0。
  4. 升级:apt update && apt upgrade、dnf upgrade 'php*'、EasyApache / Plesk,或面板的 PHP 重建。随后重启 Apache(mod_php)、PHP-FPM 以及 Octane、队列等长驻进程。
  5. WordPress:媒体上传、插件主题安装和许多表单都走 multipart。不要在未仔细白名单路径的情况下对整站拦截 multipart。
  6. 卡在 8.1 或更早且没有厂商回移:今晚迁移,或先下线——日本 NCO 与多家主机商的建议一致。
# 示例,包名按发行版调整
php -v
php -i | grep session.upload_progress.enabled
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.2-fpm
ps aux | grep php-fpm

OpenAI 官方自查工具:看到 UNKNOWN 别松口气

北京时间 10 月 22 日 00:35,OpenAI 发布了官方的 PHP2Shell 自查工具。它不发任何攻击请求,只读取网站在 HTTP 响应头里本来就暴露的 PHP 版本(X-Powered-By 和 Server);加上 --local 则读本机 php -v 的结果。只要有 Node.js 就能跑,不用装别的包。

GitHubopenai/php2shell-checkerJavaScript39 星标1 复刻更新于 2026-10-21

查网站用 node phpcheck.js "https://example.com",在服务器上查本机用 node phpcheck.js --local。结果只有三种:OK、VULNERABLE、UNKNOWN。

要注意的是:大多数虚拟主机和面板都会隐藏 PHP 版本头,所以很多站跑出来就是 UNKNOWN。UNKNOWN 不等于安全,README 里也是这么写的。你还是得登录面板看一眼,或者直接跑 php -v,然后在自己的分支内升级到 8.5.12、8.4.27、8.3.36 或 8.2.35。就算显示 OK,也只是版本号比对,并不能证明补丁真的打上了。

托管面板 vs 自己管

今晚像一场对照实验。会自动编 PHP 的托管面板上,你多半是盯仪表盘,并避免在某个 .user.ini 里把 session.upload_progress 又打开。自己搭的 VPS 上,你就是发布工程师:盘点每个 PHP 二进制(CLI、FPM、容器、奇怪的 chroot),装厂商包,重启工作进程,再证明线上跑的就是新版本。AI 相关的启示不是“AI 让托管变轻松”,而是 AI 在你栈底层的语言里挖出了十四年级别的洞——今晚睡得着的,多半是主机已经有补丁流水线的人。

利用情况:能说什么

  • 以下为截至北京时间 10 月 22 日 01:15 的情况。公开的概念验证(PoC)代码已经出现:GitHub 上已有多个针对 CVE-2026-109618/109619 的 PoC 仓库,X 上也在转发。我们没有测试这些代码,文中也不提供链接。
  • 安全厂商已看到攻击者拿这些公开代码来尝试。Vega Threat Research 于北京时间 10 月 21 日 23:01 表示,正在野外看到利用公开 PoC 的攻击尝试。watchTowr 对 SecurityWeek 表示,补丁发布前后它的传感器就记录到首批野外利用尝试,但目前没有一次成功。Cloudflare 也报告有攻击流量与不断变化的载荷(博客、Knecht)。
  • 目前仍没有确认的入侵案例:上面说的都是扫描和利用尝试,我们没有查到任何经确认的、网站真的因这两个漏洞被攻破的报告。
  • 截至北京时间 01:15,两个 CVE 仍未进入 CISA KEV(最新目录为 10 月 21 日 14:04 UTC 版本,KEV 目录)。

常见问题

关掉 session.upload_progress 就够了吗?

不够。它只挡住 CVE-2026-109619 已确认的一条路径,对 CVE-2026-109618 无效。PHP 说没有完整缓解。

Cloudflare 能护住我吗?

若流量经 Cloudflare 代理且托管规则为拦截模式,你从今天北京时间 11:02 起就有默认权宜防护。PHP 补丁仍要打。

我还在 PHP 8.1,安全吗?

php.net 不修。只有会回移的主机(例如 Prostack Cito 回移到 5.6,或 cPanel 自 7.4)能覆盖你。否则迁到 8.2+,或先下线。

升级 WordPress 插件有用吗?

没有。漏洞在 PHP 运行时,插件更新替不了 PHP 升级。

为什么有人说 CVSS 10.0?

早期二手文章用过 10.0。PHP 安全团队、GHSA 与 NVD 记录使用的是 CVSS v4.0 9.2(攻击复杂度 High,攻击要求 Present)。

OpenAI 自己被打了吗?

没有这方面的公开证据。OpenAI 在此事中的公开角色是发现与协调方(Patch the Planet),不是“受害 SaaS”叙事。

来源

站内相关:Claude Code 报错速查,以及 Mac 发烫时如何自查挖矿进程——问题不同,都是先核实再动手。

留下你的想法

你的邮箱不会公开。