毁灭吧，赶紧的：PHP 爆出 9.2 分”上古”RCE 漏洞，大家今晚 10 点熬夜打补丁吧

麻了，毁灭吧，赶紧的……感觉自己现在越来越不像个写博客的，倒像个天天打补丁的业余网管。Linux 刚消停两天，Nginx 刚升完没多久，甚至前天还被某插件的供应链攻击连累，服务器被植入远控全站回档了十几个小时（还好做了全盘镜像），这回轮到 PHP 爆雷了。

今天下午刷群消息和 RSS 阅读器，满屏都在刷 PHP 官方刚发的紧急安全预警：PHP 从 5.4 版本开始，存在两个底层核心的远程代码执行（RCE）漏洞，CVSS v4.0 评分高达 9.2 分。

给没看到消息的各位博友和读者们梳理一下现在的状况：

• 好消息：PHP 官方安全团队已经定在今晚（2026 年 10 月 21 日）北京时间 22:00（14:00 UTC）准时发布紧急修复版本。
• 坏消息：这事儿本来是保密到周四（10 月 22 日）才公开的，结果昨天有人在 Hacker News 上提前捅出来了，连内部测试用的攻击脚本截图（起名叫 PHP2Shell）都流出来了。这意味着今晚 10 点官方补丁一发，随便一个人拿到补丁代码让 AI 做个逆向，搞不好 5 分钟就搞出扫描器原型，15分钟后全网无差别扫描脚本就该满天飞了。
• 更坏的消息：PHP 官方这次，只给还在生命周期内的 PHP 8.2、8.3、8.4、8.5 四个分支发补丁。如果你还在用 PHP 8.1、8.0，或者很多 WordPress、Typecho 站长最爱的 PHP 7.4 / 5.6……官方一摊手：早停止支持咯，没补丁的说，你们自求多福吧。

1. PHP RCE 漏洞到底是个什么漏洞？

PHP 官方昨天半夜紧急发出来的原话是这样的：

The PHP security team would like to give advance notice of an upcoming security release scheduled for Wednesday, October 21, 2026 at 14:00 UTC. This release will address two critical vulnerabilities, both rated CVSS v4.0 9.2. Full details, affected versions, and the fixed versions will be published with the release. Should details of either vulnerability become public, or should evidence of active exploitation appear in the wild, the release may be brought forward.

翻译总结一下：

就是 PHP 核心底层出了两个编号为 CVE-2026-109618 和 CVE-2026-109619 的超高危远程代码执行（RCE）漏洞，满分 10 分它俩拿了 9.2 分。

蛋疼的地方在于，根据目前安全机构（watchTowr 和 Sansec）确认的泄露消息，这俩漏洞应该是属于 PHP 底层核心逻辑的问题，疑似从 PHP 5.4.0 开始往后的版本全军覆没，而且看他们的语气大概率也不需要什么太苛刻的前置条件，默认安装配置就能触发。

千万别觉得“小破站没几个人看，黑客看不上我”——自动化扫描程序可不管你是大厂还是个人博客，只要扫到 IP 返回的是 PHP 响应（甚至不管你用的是什么网站程序，哪怕只放了个探针），上来就先打一发攻击试试，打穿了直接往机器里塞挖矿木马或者拿去当肉鸡。

2. 怎么排查自己的服务器有没有风险？

先登服务器敲个命令看下自己的 PHP 版本：

php -v

当然，如果机器上装了多版本 PHP（面板的常见操作），命令行是不准的，需要看你网站实际挂载的 php-fpm 是哪个版本：

ps aux | grep php-fpm

1. 如果你在用 PHP 8.2 / 8.3 / 8.4 / 8.5：算是不幸中的万幸，今晚 10 点有官方补丁，准备好晚上更新就行。
2. 如果你在用 PHP 8.1 / 8.0 / 7.x / 5.x：高危重灾区！据统计目前公网上暴露的 150 万台 PHP 主机里，差不多有 60% 全在这些没补丁的老版本上。

3. 网传的把 session.upload_progress.enabled 设为 0 能防住吗？

各大技术群和推特上都在疯传去 php.ini 里把 session.upload_progress.enabled 改成 0（或者 Off）就可以防住这次的漏洞，也就是所谓的“一行配置免打补丁”。

这个我在群里和一些大佬交流了一下，结论是：这招挡不住所有攻击，只能帮你挡一半

因为这次爆出来的是两个漏洞

• 第一条攻击路径确实走的是 session.upload_progress（泄露出来的那份 PHP2Shell 脚本走的就是这条路）
• 但第二条攻击路径貌似是在 PHP 底层的 multipart 请求解析器。把 upload_progress 关了，甚至把 file_uploads = Off 关了（彻底禁止文件上传），但是 PHP 在收到请求时，按照设计必然需要先解析 multipart 请求体，导致触发第二条攻击路径。

PHP 的核心开发者 Gina Peter Banyard 也说了

“The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much.”
我唯一能说的是，唯一的缓解办法就是打补丁/升级 PHP。很遗憾我知道得太多了。

4. 目前可能有点用的临时保命两招

影响是这几个小时里你自己没法在博客后台传图片和更新插件了，不过下边这些都是网传措施，有说有效，也有说没效的，不过能确定的一条是 session.upload_progress.enabled = 0确实已经被宣布无效化了。

4.1 session.upload_progress.enabled = 0 先改上

虽然防不住第二个攻击路径，但起码能先拦住一些脚本是不，起码先把脚本小子防住

• 宝塔 / 1Panel 面板党：去面板的「PHP 管理」->「配置文件」，搜索 session.upload_progress.enabled，把后面的 On 或 1 都改成 0，保存并重载配置。
• 手动党：在对应的 php.ini 里加上 session.upload_progress.enabled = 0，保存并重载配置。

4.2 在 Nginx 直接阻断 multipart 请求

既然网传的两条攻击路径都必须通过发送 multipart/form-data 格式的请求体来触发，那最直接的缓解办法就是：在请求到答 PHP-FPM 之前，让 Nginx 直接干死所有带 multipart 头的请求！
在你站点的 Nginx 主配置文件的 server {} 块里塞入这三行：

if ($http_content_type ~* "multipart") {
    return 403;
}

宝塔面板可以在这里配置：

• 直接打开你的/www/server/nginx/conf/pathinfo.conf文件

• 把前边三行代码写在，文件的第一行，大概是这样的感觉

if ($http_content_type ~* "multipart") {
    return 403;
}
set $real_script_name $fastcgi_script_name;
if ($fastcgi_script_name ~ "^(.+?\.php)(/.+)$") {
        set $real_script_name $1;
        set $path_info $2;
 }
fastcgi_param SCRIPT_FILENAME $document_root$real_script_name;
fastcgi_param SCRIPT_NAME $real_script_name;
fastcgi_param PATH_INFO $path_info;

• 重载Nginx配置，然后在本地测试一下curl -i -F "test=1" https://网站域名/index.php 如果返回是HTTP/1.1 403 Forbidden 就是缓解措施生效了

5. 今晚 10 点怎么打补丁？

等今晚 22:00 官方发版后，第一时间把 PHP 升到 8.2 ~ 8.5 各自最新的小版本（具体版本号以今晚发布的为准）。

具体怎么升，要看你当初是怎么装的 PHP 了：

情况一：走系统源、第三方源装的 PHP

如果是 Ubuntu / Debian 用 ondrej/php 源，或者 Rocky / AlmaLinux 用 Remi 源装的，等源同步之后直接更新就行（虽然 Debian 系的系统一般默认开了无人值守自动安全更新，每天会自动帮你检查并安装 2 次安全补丁，但今晚这情况还是强烈建议手动敲一下，尤其是用服务商自带镜像的，鬼知道他们怎么配置的）：

# Ubuntu / Debian
sudo apt update && sudo apt --only-upgrade install php8.2-* -y  # 把这里 8.2 换成你自己的版本
sudo systemctl restart php8.2-fpm

# Rocky / Alma / RHEL
sudo dnf upgrade --security php\* -y
sudo systemctl restart php-fpm

情况二：宝塔 / 1Panel 的 PHP 更新

独立博客圈里用 1P 和宝塔的博友应该占一大半：

• 宝塔面板：去面板的「软件商店」找到你正在用的 PHP。重点敲黑板：如果过了 10 点进去发现没提示更新，八成是本地软件列表缓存没刷新！先点右上角的 「更新软件列表/支付状态」，等它拉取完最新的列表，PHP 后面就会出现「更新」按钮了。

• 1Panel：直接去「应用商店」-「已安装」里检查更新，拉取最新镜像重装容器就行。

很多人会选的“极速安装”往往要等面板官方打包，起码会比源码慢个把小时；如果你服务器性能好（满血 2 核及以上的），着急的话建议直接切“编译安装”更新。

情况三：LNMP 一键安装包

因为我已经很久很久都不用这种一键包了，下边的命令不一定百分百对，仅供参考：

# 先进入你的 LNMP 安装包目录
cd /root/lnmp2.0/

# 运行升级脚本，指定升级目标为 php
sudo ./upgrade.sh php

# 脚本就会问你要升到哪个版本，去官网看一眼今晚刚发的版本号填进去就行

6. 还在用 PHP 7.4 / 5.x？没补丁又死活升不了级怎么办？

肯定有不少博友还在死守 PHP 7.4 和 5.6 的，懂得都懂——手里有些祖传的 WordPress 主题、老插件，或者一些年久失修的开源小项目，一升 PHP 8.2 直接满屏 Fatal Error 白屏给你看。

如果确实没法立刻升级到 PHP 8.2+，那只能想办法在外部把攻击路径给堵死了：

先备份一下服务器，做好最坏的打算，然后把前边临时保命的两招缓解措施先部署上。

方法 1：直接升级 PHP 8.2 碰碰运气（推荐先试）

面板党其实可以趁现在还没到 10 点，在软件商店里先装一个 PHP 8.2 或 8.3 备用。然后把网站的 PHP 版本切过去试一下。现在的 WordPress 核心和主流插件其实早就兼容 PHP 8.2 了，万一能跑通，今晚就能直接打上官方补丁，一劳永逸是不。万一不行，炸了，切回来就好了。

方法 2：套上 Cloudflare 或商业 WAF 蹭“虚拟补丁”

根据安全公司 Sansec 的说法，由于漏洞出在 PHP 底层解析阶段，还没走到你网站的业务代码（比如 WordPress 的防护插件 Wordfence）那一步，攻击就已经触发了，所以指望网站后台的安全插件拦住它是没戏的。

看起来唯一有戏能拦的地方就是前端反代和 WAF——这招也叫“WAF 虚拟补丁”，漏洞修不了就先把攻击流量挡在门外。今晚 10 点漏洞细节一公布，像 Cloudflare、阿里云、腾讯云这种带 WAF 的 CDN，雷池、南墙这些商业 WAF，宝塔、1Panel 面板内置的 WAF，这些厂商的 WAF 肯定会连夜更新拦截规则。先开起来，或者盯紧今晚社区放出来的拦截正则，扔到前端的防火墙里，先把问题请求拦在 PHP-FPM 门外。

方法 3：等操作系统发行版的向后移植

如果你用的是 Ubuntu Pro（开启了 ESM）或者 Debian LTS 的系统原生 PHP 包（比如 Debian 自带的旧版 PHP），这种重大安全漏洞，发行版维护团队大概率会把这次的安全补丁移植回旧版本 PHP 里。这几天勤快点跑 apt update && apt upgrade，看系统源有没有推送安全更新包。

方法 4：终极物理防御大法

要是你既没套 CDN/WAF、用的是早就停更的 PHP 7.x、跑的又是裸奔在公网上的玩具站点，今晚 10 点又不想熬夜运维……

那不如：今晚 10 点前直接把 php-fpm 停了，或者干脆关机睡大觉！

管他呢，我就没 PHP，你能攻击个啥。等明天一觉睡醒，再看安全圈放出来的具体触发条件（比如是不是特定模块、特定运行模式才会触发）以及 Nginx 层的通用屏蔽规则，配好防护再启动 PHP。毕竟停机一晚上最多掉点爬虫流量，真要是被脚本刷穿拿去挖矿或者删库，那才叫纯纯的无妄之灾。

（反正我是打算这么办，虽然所谓的网传缓解措施也做了，但是反正我是前后端动静分离的架构，PHP 停了，只是无法评论和外链跳转罢了，不影响看文章和爬虫访问。 「只要我没有PHP，针对PHP的攻击就奈何不了我」）

写在最后

最后还是忍不住吐槽一句：原本今晚打算早点休息的，结果半路杀出这么个 9.2 分的王炸级漏洞，看来今晚 10 点全球起码有一半的站长和运维得守在电脑前抢着更新服务器了（合理怀疑到时候各大软件源和面板更新节点又要被挤爆卡死咯😂）。

等今晚 22:00 官方具体细节和修复版本号放出来之后，如果有什么可以在 Nginx 配置文件里直接“一行代码阻断漏洞”的奇技淫巧，我再在本文更新补充。各位站长先赶紧去检查一下自家的机器吧！

一些动态更新

• 刚才收到邮件，一向佛系的 CloudCone 居然宣布要主动强制给大家打 PHP 补丁

• 一些博客貌似开始关机了，开始访问不到了

• PHP准时放出补丁，目前最新安全版本是

php_82=‘8.2.35’
php_83=‘8.3.36’
php_84=‘8.4.27’
php_85=‘8.5.12’

• 好消息：缓解措施被 cloudflare 证明有效，目前观测到的全部攻击流量都集中在 multipart 请求。只要你前端 web 服务器不是Apache + mod_php模式，基本就没事，被打了基本只会让 PHP 进程崩溃。

• Ubuntu / Debian 已经做好了 PHP 补丁，直接sudo apt update && sudo apt upgrade就行，甚至连 Ubuntu 20 都可以通过 Ubuntu Pro（ESM）获得 PHP 官方都没提供的 PHP 7.4 的补丁……

• 宝塔面板的 PHP 也更新了，不过宝塔如果你死活刷不出来新版本，你需要先看下/www/server/panel/install/php.sh里面是否列的版本号是不是最新版，如果不是，手动改成最新版号，保存。然后终端里执行 bash /www/server/panel/install/php.sh update 8.2（8.2换成你实际要的版本），直接调用脚本安装（面板其实就是帮你执行的这个脚本罢了）