PHP 核心两个 9.2 分 RCE 漏洞今晚 22 点补丁：只有 8.2 以上能修，8.1 及以下永久裸奔

一、结论先说：今晚 22:00 前必须准备好

PHP 官方在 10 月 20 日发出提前预警，将于北京时间 10 月 21 日（周三）22:00（14:00 UTC）发布紧急安全版本，修复两个 CVSS v4.0 9.2 分的核心漏洞：CVE-2026-109618 与 CVE-2026-109619。官方明确说这是 critical 级别，并保留"细节再泄露或在野利用出现就提前发版"的权利。

这两个漏洞在 PHP 核心本身，不在某个面板、框架或插件里。也就是说，宝塔、cPanel、Plesk 的代码写得再干净也没用——只要底下的 PHP 解释器有洞，攻击面就在。安全公司 watchTowr 已确认两者都是远程代码执行（RCE），并复现了 CVE-2026-109618；Sansec 则给出一个很不客气的预测：补丁发布后 15 分钟内就会出现大规模扫描和攻击。

二、这场预警本来是"不该提前"的

按原计划，这批漏洞应在本周四（10 月 22 日）美东时间 11:00 解禁。但 10 月 20 日 15:20 UTC，Hacker News 上出现一条自称"可靠信源"的 Tell HN 帖，点名两个 PHP RCE、评分 10.0、"影响 PHP 5 以来所有版本"，随后截图在 X 和 Mastodon 扩散，帖子本身被删但信息已经出去了。

watchTowr 在约一小时内确认"漏洞是真的"，同时纠正了两处流传的错误：CVE 年份一度被错写成 CVE-2926，披露日期也被传成了周四。PHP 官方随即把发版时间从周四提前到周三，也就是今晚。

目前的状态是：两个 CVE 仍处于 reserved 状态，没有任何技术细节、PoC 或利用代码公开，watchTowr 表示尚未观测到在野利用，CISA KEV 目录里也没有。但社区已在传一个叫 "PHP2Shell" 的利用工具视频，声称能打 WordPress、MediaWiki、phpBB、Magento、Joomla、Laravel、Drupal、WHMCS——该视频真实性未经证实，引用时请留个心眼。

三、版本范围：8.2 及以上能修，8.1 及以下没人管

这是本次预警最要命的地方。PHP 官方目前只维护 4 个分支：8.2、8.3、8.4、8.5，只有它们会收到官方补丁。8.1 及更早（包括还在大量运行的 5.6、7.x）属于 EOL，官方不会修——漏洞会长期留在那里。

watchTowr 认为受影响范围可能上溯到 PHP 5、6、7、8 全系，但这仍是未经官方确认的说法，最终以今晚的 release notes 为准。另外提醒一句：8.2 本身将在 2026 年 12 月 31 日结束安全支持，把 8.2 当终点站是短视的。

暴露面有多大？基于 Shodan 的一项统计（单一信源，仅作方向参考）：约 223 万台主机在响应头里暴露 X-Powered-By: PHP，其中约 150 万台带版本号；带版本号的主机里有 883,717 台（约 59%）跑在拿不到补丁的分支上，仅 PHP 5.x/7.x 就占 697,928 台。另有约 74 万台隐藏版本号，真实规模只会更大。国家分布上，美国 228,770 台居首，中国、日本（55,460）、德国（45,835）紧随其后；托管商里 Amazon、Hostinger、阿里云承载的 PHP 主机最多。

四、今晚该做什么：一张可执行的清单

第一步，把 PHP 全部找出来（现在就能做）。CLI 和 Web 走的可能不是同一个 PHP，必须分开查：

• php -v 看命令行版本；php-fpm -v 或 php-fpm8.3 -v 看 FPM 池实际用的二进制；临时 phpinfo() 页面看 Web SAPI（用完立刻删）；
• Debian/Ubuntu 多版本共存：ls /etc/php/ + systemctl list-units --type=service 'php*-fpm*'；
• Plesk：plesk bin php_handler --list；cPanel：whmapi1 php_get_installed_versions——面板管理的每个 handler 都要更，不是只更默认那个；
• 容器：grep -rn "FROM php:" --include="Dockerfile*" . 和 docker ps --format '{{.Image}}' | grep -i php，基础镜像要重新构建，光改 tag 不重建没用。

第二步，分清两条处置线。8.2/8.3/8.4/8.5 的机器等补丁发布后立即升级；8.1 及以下的机器今晚等不到补丁，只能走迁移或隔离——上 VPN/IP 白名单、挪到加固过的反向代理后面，或者干脆先下线。

第三步，22:00 一到，按暴露面排序打补丁。先公网可访问、接受用户输入的站点，再管理后台和内部工具。升级后必须重启 PHP-FPM 和 Web 服务器，否则跑的还是旧解释器。容器要走正常流水线重建镜像（禁用缓存层）再发布，最后每个站点抽一个真实页面验证——"修好了但站挂了"是另一起事故。

第四步，确认补丁真的生效。Debian/Ubuntu 打补丁常常不改版本号，php -v 看着还是旧版，要用 apt changelog php8.3-fpm 查变更记录里有没有这两个 CVE；跟上游版本号走的仓库（比如 Sury PPA）和容器镜像则应该能直接看到新版本号。有传闻说修复版本是 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35，单一信源、未经官方确认，别当依据。

第五步，补丁没到时能做的临时动作。WAF 规则提前备好（机制未公开前的通用规则用处有限，别指望它）；关掉用不到的 PHP 端点和 SAPI；跑 php-cgi（不是 PHP-FPM）的环境建议设置 cgi.fix_pathinfo=0 并加 try_files $fastcgi_script_name =404;——这条老经验源自 CVE-2019-11043，与本次两个 CVE 尚无确认关联，但值得先做。

另外两件容易被忽略的小事：一是先备份（网站文件 + 数据库），批量升级 PHP 翻车的概率不比被打低；二是如果你是托管商或帮客户运维，提前发一条"今晚更新 PHP"的通知，能省掉事后一半的工单。

五、各方目前的态度

watchTowr 确认漏洞真实、已复现其一，但技术细节压到补丁发布；Sansec 直接给了"15 分钟开扫"的时间表；Webfence、Huntress 各自发了告警；BlueOnyx 表示会在官方补丁一发布就为旗下平台构建 PHP 包。而 PHP 官方自己的表述很克制：只给 9.2 分，只承诺 8 分支，只说了"请现在就开始准备"。

至于面板和主机商，各家打包渠道的节奏一定慢于 php.net 源码发布——Debian/Ubuntu 回移要时间，Plesk/cPanel 走自己的更新通道，共享主机用户只能等主机商。所以如果你用的是虚拟主机，今晚要问的不是"有没有补丁"，而是"你们什么时候重启 FPM"。

写在最后

这是 PHP 少见的"两个 9.2 分同时落地"的窗口，而它偏偏是在信息提前泄露、防守方时间被压缩的情况下发生的。真正决定损失的不会是漏洞本身有多精巧，而是今晚 22:00 之后的几个小时内，有多少台机器完成了升级并重启。清单已经给你了，今晚照着做就行——本文发布时官方补丁尚未上线，最终版本范围与修复版本请以 php.net 公告为准。

参考来源：php.net 安全公告（2026-10-20 预警）、watchTowr 官方声明、Sansec 预警、BleepingComputer / Ars Technica 报道、Phoenix Security 与 PrivateDevOps 处置指南、Shodan 暴露面统计。