PHP2Shell：9.2 分的 PHP 引擎漏洞，今天先把 PHP 升上去
10 月 21 日，PHP 官方发了两个紧急安全版本，编号 CVE-2026-109618 和 CVE-2026-109619，圈内统称 PHP2Shell。PHP 安全团队给的评分是 CVSS v4.0 9.2，两个都是。这个漏洞值得单独写一篇，因为它踩中了几条最难受的组合：在 PHP 引擎本身（不是插件、不是框架）、无需登录、一个 POST 请求就能打、影响 PHP 5.4 以来的版本。公开 exp 已经流出来了，安全厂商的判断是"发布后 15 分钟内就会有大规模攻击"——所以这不是"找时间研究一下"的事。
先把结论放前面：能升 PHP 的，今天就去升。这类漏洞没有"改改代码"的解法，只能从基础设施层修。
一、这两个洞到底是什么
编号类型说明
CVE-2026-109618RCE内存（OOM）处理路径被破坏，可被诱导执行任意代码
CVE-2026-109619RCE全局状态残留（stale global state），跨请求数据没清干净，被拼成可利用状态
两者都能做到未认证远程代码执行，也就是直接拿 shell。触发方式是发一个特制的 multipart POST 请求——不需要账号、不需要诱导管理员点击、不需要任何交互。
特别提一句 109619：在 PHP-FPM 模式下，它可以通过 session.upload_progress 这条路径打进去，而这个特性默认是开启的。很多人做加固时盯着 disable_functions、盯着上传目录权限，却从没看过这个开关。
二、影响范围：先看版本号
公开情报口径是 PHP 5.4 及以上均可能受影响。不止新站，一批跑着老版本的存量业务也在射程内。
官方修复版本：
分支修复版本
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35
8.68.6.0 RC4（预发布分支）
8.1 及以下的实际情况要分开说（这里容易传错）：
· 官方对 8.1 及以下不再发正式版本；
· 但安全团队额外维护了 7.4 / 8.0 / 8.1 的源码 backport 分支，会自己编译的可以跟；
· 部分发行版和 LTS 厂商也会 backport，值得去对应厂商的安全公告里确认；
· 7.3 及以下确实没有任何官方或 backport 来源——只能升级或做临时缓解。
另外，风险面跟 Server API 有关：mod_php（Apache 处理器模式）风险最高，FPM 相对低但不是安全区，php-cgi 一并按暴露处理。所以别因为自己是 FPM 就放松。
三、第一步：确认自己跑的是哪个版本
php -v
输出第一行就是版本，例如：
PHP 8.3.6 (cli) (built: Sep2 2026 12:56:02) (NTS)
⚠️ 这里有个大坑：命令行看到的 PHP 版本，不一定等于网站实际用的版本。宝塔、cPanel、多版本共存的环境里，nginx/Apache 挂的往往是另一个 php-fpm。稳妥的做法是看 web 实际那一个：
# 看 fpm 进程和它的可执行文件路径
ps aux | grep -E 'php-fpm|php-cgi' | grep -v grep
或者直接问网站自己（临时放一个文件，看完立刻删）：
echo '<?php echo PHP_VERSION;' > /www/wwwroot/你的站点/v.php
curl -s https://你的域名/v.php; echo
rm -f /www/wwwroot/你的站点/v.php
同时看一眼 phpinfo() 里的 Server API 那一行，确认是 mod_php 还是 FPM。
四、第二步：升级
Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli
php -v && sudo systemctl restart php8.3-fpm
（把 8.3 换成你在用的分支；用 ondrej PPA 的话先确认源里已经出了新版本。）
RHEL / CentOS / Rocky
⚠️ 注意：Remi 源在发布当天并不保证同步更新，官方明确建议优先用发行版自身的包或源码编译。硬跑 dnf --enablerepo=remi-php83 update php 很可能白跑一趟，先看发行版公告。
# 以发行版仓库为主
sudo dnf update php
sudo systemctl restart php-fpm
宝塔面板：软件商店 → 对应 PHP 版本 → 升级。升级前先记下装了哪些自编译扩展（redis、swoole 之类），升完确认扩展还在，不然站点会 502。
源码编译：拉对应 tag 重新编译安装。注意 php（CLI）和 php-fpm 是两个二进制，两个都要换。
不能升级的容器/托管环境：找服务商要书面确认他们的 PHP 什么时候打上补丁。
五、第三步：升完必须验证
# 1. 版本到位
php -v | head -1
# 2. fpm 真的重启过（看启动时间）
systemctl status php8.3-fpm --no-pager | head -5
# 3. 站点还在跑
curl -sI https://你的域名 | head -1
升级 PHP 最容易翻车的不是升级本身，而是扩展丢失和兼容问题。先在一个站点验证，再全量推——尤其是跑着老框架（ThinkPHP5、Discuz、老版 WordPress）的站。
六、升不了怎么办
现实是很多业务卡在老版本上，程序升不了、框架不兼容。这种时候能做的是按官方口径做临时缓解，把攻击面收窄。
要讲清楚：缓解不是修复。它能挡掉批量扫描和现成 exp，挡不住定向攻击。具体怎么改、每条配置写在哪、怎么验证——下一篇写细的。
小结
· PHP2Shell = CVE-2026-109618 + CVE-2026-109619，CVSS 9.2，未认证 RCE
· 影响 PHP 5.4+，修复版本 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12
· 8.1 及以下没有正式版本，但有 7.4/8.0/8.1 的源码 backport（自编译）；7.3 及以下什么都没有
· mod_php 风险最高，FPM 也不是安全区
· 升完三验证：版本、fpm 重启、站点可用
这类洞的窗口期很短。今天查一遍版本，比下周在日志里看到一堆可疑 POST 强。
页:
[1]