还在跑 PHP 7.4 和 8.0？这次漏洞没有现成补丁包

这次 PHP 安全更新里，最容易被忽略的一条是：8.1 及更早的版本，官方只提供了三个分支的最小源码 backport，没有给发行版准备好的补丁包。也就是说，还在跑 7.4 或 8.0 的机器，不能像别人那样 apt upgrade 一下就完事。

老版本现在的处境

PHP 8.1 已经在 2025 年底结束支持，8.0 和 7.4 更早。项目不再为它们出常规版本；这次例外给的是 PHP-7.4、PHP-8.0、PHP-8.1 三个分支上针对这两个 CVE 的最小改动，方便你从源码编译，或者交给提供 LTS 的厂商去打。8.2 还能用到 2026 年 12 月 31 日，之后同样停下。换句话说：现在不升，下一次可能连 backport 都没有。

升级路径怎么排

跨大版本不要一步跳太远。7.4 的站先到 8.1，再考虑 8.2 或 8.3；8.0 可以直接去 8.2 或 8.3。生产环境建议这样做：先在测试环境装目标版本，跑一遍站点的核心流程（登录、下单、上传、后台操作），把报错日志收齐；再用容器或面板的版本切换功能，拿一台真实流量的机器灰度；最后再批量切换。切换前把 php.ini 备份出来，新旧版本的默认值和废弃项差别不小。

面板用户怎么升

用宝塔、cPanel 这类面板的，别自己去 yum 里硬升，先在面板的软件商店里看有没有新版 PHP 或新的补丁包；没有的话，面板一般支持装多个 PHP 版本并按站点切换，可以先把风险高的站切到 8.3，再慢慢处理其它站。切完记得重启对应的 FPM，并在站点根目录确认 phpinfo 显示的版本真的变了——面板切了但站点没生效，是挺常见的坑。

升级前必须查的兼容点

第一类是废弃与移除的函数，尤其是老项目里的 mysql_ 系列、ereg 系列；第二类是错误级别变化，8.x 把不少警告升级成了错误，以前能跑的老代码会直接白屏；第三类是扩展，像 imagick、redis、memcached 要装对应版本，别只升 PHP 本体；第四类是框架和插件的版本要求，WordPress 老插件在新 PHP 上出问题是常事；第五类是时区和浮点数相关的隐式行为差异。这五类查完，能避开绝大多数”升完就炸”的事故。

升级后怎么验证

验证不要只看首页能不能打开。先看错误日志有没有新增的 fatal；再逐条走一遍关键流程；然后跑一次上传和一次表单提交，确认 post_max_size 和 upload_max_filesize 仍符合预期；最后用 php -v 和 phpinfo 双重确认版本，并检查 opcache 是否正常启用。全部通过再放流量进来。

过渡期怎么活下来

如果一时升不上去，至少把这次官方给的缓解做上：memory_limit 用 FPM 或 Apache 配置设成 -1 且不许应用覆盖，post_max_size 压到 8M 或 32M，session.upload_progress.enabled 设 0 并重启所有 worker，跑 8.5 的再关掉 fatal_error_backtraces。同时收窄暴露面：后台路径限制来源 IP、能不用上传的站关掉上传、在网关层限制请求体大小和字段数。这些都不等于安全，只是把被利用的概率压低。

有些老站，重建比升级更划算

这两年我见过的老站里，有一部分其实已经不是”要不要升 PHP”的问题，而是整套环境都该换掉了：PHP 7.4 配 CentOS 7、面板是几年前的版本、插件一升就冲突。这种情况下逐个版本往上挪，时间成本可能比新开一台干净机器还高。比较务实的做法是：新环境装 8.3 或 8.4，把站点文件和数据迁过去，在测试域名上把流程跑通，然后切解析。老机器先留着观察一周，确认没有遗漏再下线。这样既解决了漏洞，也顺手把系统、面板、扩展的欠账一起还了。

最后说一句实在的：老版本 PHP 迟早要还这笔账，这次是 9.2 分，下次可能就是没有 backport 的 9.8 分。具体的补丁分支、受影响版本和缓解参数，以 PHP 官方安全公告为准。