Tensor Ray

外观

CVE-2026-109618 影响 WordPress 吗？PHP 9.2 分漏洞，出海站长今晚该做的 5 件事

创建时间：2026/10/21
更新时间：2026/10/21
PHPWordPress安全CVEWooCommerce宝塔服务器运维

今天下午，PHP 官方放出了一条不多见的预告：将在 2026-10-21 14:00 UTC（北京时间今晚 22:00） 发布安全版本，修复两个漏洞，CVSS v4.0 都是 9.2。

9.2 这个数字意味着什么？满分 10，9 分以上基本就是"能远程把你服务器拿走"的那一档。在 PHP 的语境里，通常意味着别人不需要你的后台密码，只要能让你的服务器解析一个精心构造的请求，就能在你的机器上跑代码。

而 WordPress 跑在 PHP 上。所以哪怕你只是开着一家卖宠物用品的 WooCommerce 小店，这件事也和你有关。

我写这篇不是为了让你今晚别睡。恰恰相反，在你拿不准的时候，最贵的东西是慌乱。我把已知的、未知的、今晚能做的、和千万别做的，分成几块讲清楚，你看完大概花五分钟，然后该干嘛干嘛。

这次的 CVE，现在确认了什么，还差什么？ ​

网上已经开始传了，各种说法混在一起。目前的可靠程度是这样的：

已确认的部分 ​

  • PHP 官方公告：两个漏洞，CVSS v4.0 均为 9.2，即将发布修复版本。
  • 发布时间：官方计划 2026-10-21 14:00 UTC，也就是北京时间今晚 22:00，可能提前。
  • 编号 CVE-2026-109618 与 CVE-2026-109619 已由 CERT-EU 等第三方通告使用。

还没确认的部分 ​

说法当前状态
可导致未认证的远程代码执行通报与研究者的描述，官方技术细节未公开
与 Session 上传进度（session.upload_progress）有关日本 GMO Flatt Security 的独立推测，未获官方确认
从 PHP 5.x 起所有版本都受影响属于待确认范围，不是准确的受影响清单
关掉 Session 上传进度就能完全阻断不成立的安全保证，研究已提示可能仍可攻击

注意最后几行。截至我写这段话，PHP 官方只说了"有两个 9.2 的洞，今晚发补丁"，根因、影响分支、最低修复版本全部没公布。所以今晚之前，任何告诉你"你的版本一定中招"或"你的版本一定安全"的文章，都是在猜。

为什么 PHP 的洞比插件漏洞麻烦？ ​

我们做 WordPress 的，对漏洞其实不陌生：某个插件出洞了，后台点一下更新，喝口水就过去了。

PHP 的洞不是这个层级的东西。它在你所有插件、主题、WordPress 核心的下面。插件更新一百次也碰不到它。我在第九章：网站安全防御与备份恢复里写过怎么配 Wordfence、怎么定备份策略——那些依然是正确的做法，但它们全部建立在"运行时是安全的"这个前提上。今晚这个前提被动了。

更麻烦的一点是：大部分站长根本不知道自己跑的是哪个 PHP 版本。

共享主机上一个按钮切换、宝塔面板里点一下安装、Docker 里 FROM php:7.4-fpm 写死——三种情况的维护责任人完全不同，而这恰恰决定了今晚你需不需要做任何事。

你的 WordPress 到底在跑哪个 PHP 版本？ ​

别猜，去查。而且要查网站实际在跑的那个，不是命令行里的那个。

用 php -v 是最常见的误判来源：CLI 和 FPM 经常读不同的配置文件、甚至是两个二进制。你有宝塔的话更明显——面板升级了 PHP，站点还在用老 pool。

最靠谱的方式，是在网站根目录放一个临时文件：

php
<?php
// 临时文件，仅限自己访问；看完立刻删掉
echo PHP_VERSION;

打开 https://你的域名/check.php，看一眼版本，然后立刻删除这个文件。这个文件本身也是信息泄露，别留着。

顺手记下你用的是哪种环境：

  • 共享主机（SiteGround、Hostinger、Cloudways、Kinsta、WP Engine）：版本通常能在控制面板的 PHP / MultiPHP Manager 里看到。
  • 宝塔 / 1Panel 自建：面板"网站 - 站点 - PHP 版本"那一栏才是真相。
  • Docker 部署：看 docker ps 里跑的是哪个镜像 tag。php:7.4-fpm 这种写着小版本号的，几乎必然是老镜像。
  • WordPress 后台：工具 - 站点健康 - 信息，也能看到一个版本号，但它是 PHP 自己报的，仅供参考。

谁负责给你的站打补丁？ ​

这一步决定了你今晚是"等邮件"还是"熬通宵"。先看你的版本在不在上游维护范围里：

你的 PHP 版本php.net 是否还维护现状与对策
8.2 / 8.3 / 8.4 / 8.5是等官方新版本发布，测试后升级即可
8.0 / 8.1否（已 End of Life）只能找发行版或商业供应商的回移补丁
7.x（7.2 / 7.4 最常见）否同上；Docker 自建镜像需自行重建
5.x否同上，且应列为首要迁移对象

然后再看是谁在替你干活：

如果你用大厂共享主机：SiteGround、Kinsta、WP Engine 这些基本会自己跟进底层补丁，你不需要动手。但"基本会"不等于"你今晚就安全了"。明天上班第一件事应该是去它们的状态页或者工单里问一句："PHP 这次的两个 CVE 打了没？"一封工单三十秒，比你在群里问一小时有用。

如果你自己维护 VPS：那你就是"供应商"。宝塔软件商店里的 PHP 不会因为上游发了补丁就自动变安全——注意，这里和日常巡检 SOP里"看到更新提示别乱点"的保守原则不冲突，安全补丁是唯一值得破例去升的东西。而 Docker 官方镜像更不会自己长大：php:7.4-fpm 永远停在它构建的那天。

如果你在 PHP 8.2 及以上：理论上属于上游还在维护的分支，等官方版本出来直接升就行。

这里有个反直觉的点：回移补丁通常不改主版本号。你打完之后 php -v 还是显示 7.4.x，看着像没打，其实打了。所以判断有没有修，只能看供应商的安全公告和软件包 changelog，不能看版本号。

关掉 session.upload_progress 有用吗？ ​

官方细节没出来之前，这是唯一被公开讨论、且风险很低的缓解手段。

ini
session.upload_progress.enabled = Off

这个选项默认是开的，作用是让 PHP 把 multipart 上传的进度写进 $_SESSION，供另一个请求轮询读取。绝大多数网站——包括你，很可能——根本没用过它。

先把你最担心的那件事排除掉：关掉它不影响文件上传。WordPress 媒体库、WooCommerce 商品图、Contact Form 7 的表单附件、$_FILES、move_uploaded_file()，全都照常。它也不影响登录和 Session 本身。浏览器端那个上传进度条走的是 XMLHttpRequest.upload.onprogress，跟 PHP 无关。

改法看你环境：

普通 FPM，改 php.ini：

ini
session.upload_progress.enabled = Off

想只在某个站点生效，写进对应的 pool：

ini
; 例：/etc/php/7.4/fpm/pool.d/www.conf，实际路径看你的发行版
php_admin_flag[session.upload_progress.enabled] = off

Docker 的话，在 Dockerfile 里加一行再重建：

dockerfile
RUN printf 'session.upload_progress.enabled=Off\n' \
    > /usr/local/etc/php/conf.d/disable-upload-progress.ini

然后重启 FPM，并且去网站上验证真的生效了。还是那个临时文件：

php
<?php
var_dump(ini_get('session.upload_progress.enabled')); // 期望看到 string(1) "0"

但我必须把话说重一点：这不是修复。公开研究已经明确提示，关掉这个选项可能只是降低风险，不能保证挡住这次攻击。它是"反正没成本，顺手关掉"级别的措施，不是"做完就可以睡了"级别。

你的源站是不是在裸奔？ ​

这条跟 PHP 没关系，但跟"出海站长"这个身份关系很大。

很多人的架构是：域名 → Cloudflare → 源站 IP。Cloudflare 开了 WAF，觉得挺安全。问题是，源站的 IP 早就因为各种原因泄露了——历史 DNS 记录、邮件头、SSL 证书透明度日志。攻击者绕过 Cloudflare 直连你的 IP，WAF 规则一条都不会触发。

今晚值得花两分钟做的：确认源站防火墙只允许 Cloudflare 的 IP 段访问，或者至少确认你知道这个口子是敞着的。

至于 WAF 本身：指望一条通用规则挡住一个还没公布细节的漏洞，是不现实的。规则可以加，但它是"多一层网"，不是"墙"。

今晚哪些事千万别做？ ​

  • 别为了安全就冲去后台升级 PHP 大版本。 你上周刚稳定下来的 WooCommerce 环境，换个 8.x 可能直接白屏。这不是修漏洞，这是给自己制造新故障。要升，等补丁出来、在测试站验过再说。
  • 别信"没上传接口就没事"。 漏洞在 PHP 解析请求的阶段，可能在你的 WordPress 代码执行之前就已经发生。你站上有没有上传功能，不构成安全保证。
  • 别以为更新插件就能解决。 底层运行时的问题，插件市场帮不了你。
  • 别急着从日志里"抓到攻击者"。 单个异常日志不说明任何问题，先保全日志，等官方公布 IOC 再回头看。

补丁出来后按什么顺序走？ ​

  1. 读官方公告，确认真实根因和最低修复版本。别读二手文章。
  2. 旧版本用户，去问你用的发行版或商业支持方要安全公告，确认他们真的回移了这两个 CVE。
  3. 有备份再动手。数据库和全站备份这件事，平时是省空间，今天是救命。PHP 版本变动是少数能把 WordPress 整个搞挂的操作之一。
  4. 在测试环境跑一遍：商品上传、下单、支付回调、表单提交、登录。这五条过了再上生产。
  5. 灰度、观察错误日志和 PHP-FPM 有没有异常重启，留好记录。日常怎么盯，可以照着巡检 SOP 走一遍。

最后 ​

我见过太多人在这类日子里的两种极端：一种是完全不当回事，觉得"我这种小站谁看得上"；另一种是当晚就动手改配置、升版本，第二天网站挂了，损失比漏洞本身大得多。

真相是，绝大多数站长该做的事就三件：查清版本、找对责任人、把该关的关了。剩下的，等补丁和官方细节出来再说。

今晚看情况，明天再修。这两件事不冲突。

附：今晚的清单

  • [ ] 确认网站实际在跑的 PHP 版本（临时文件法，看完即删）
  • [ ] 记下你的维护方：共享主机 / 自建 VPS / Docker
  • [ ] 共享主机用户：明天发工单问一句补丁情况
  • [ ] 关掉 session.upload_progress.enabled，并从 Web 路径验证
  • [ ] 确认源站没有绕过 CDN 的直连口子
  • [ ] 检查最近一次备份是不是成功的
  • [ ] 把 PHP 7.4/7.2 这类 EOL 版本的站点列个表，标记出来
  • [ ] 关注 php.net 官方公告，等修复版本号