各分支的支持截止日期和 PHP2Shell 修复
PHP2Shell 指的是 CVE-2026-109618 和 CVE-2026-109619，两个位于 PHP 本身的严重漏洞。PHP 项目在 2026 年 10 月 21 日修复了它们。下表是各分支目前的状态。
| 分支 | 官方支持截止 | PHP 项目提供的 PHP2Shell 修复 | 页面 |
|---|---|---|---|
| 8.5 | 2029-12-31 | 发布版本 8.5.12 | |
| 8.4 | 2028-12-31 | 发布版本 8.4.27 | |
| 8.3 | 2027-12-31 | 发布版本 8.3.36 | PHP 8.3 |
| 8.2 | 2026-12-31 | 发布版本 8.2.35 | PHP 8.2 |
| 8.1 | 2025-12-31 | 只有源码 backport | PHP 8.1 |
| 8.0 | 2023-11-26 | 只有源码 backport | 旧版本 |
| 7.4 | 2022-11-28 | 只有源码 backport | PHP 7.4 |
| 7.3 | 2021-12-06 | 无 | 旧版本 |
| 7.2 | 2020-11-30 | 无 | 旧版本 |
| 7.1 | 2019-12-01 | 无 | 旧版本 |
| 7.0 | 2019-01-10 | 无 | 旧版本 |
| 5.6 | 2018-12-31 | 无 | PHP 5 |
日期来自 php.net 的受支持版本页和不再支持分支页。8.2 和 8.3 处于只修安全问题的阶段，8.4 和 8.5 仍在积极支持期内。
“源码 backport”是指 PHP 项目发布了一个类似 PHP-7.4-CVE-2026-109618-109619 这样命名的分支，里面只有这两个修复。它只是源码，没有发布版本，也没有安装包，需要有人去编译。详情见 PHP 7.4 页面。
官方停止支持，不等于没人打补丁
PHP 项目结束一个分支后，就不再发布新版本。其他人仍然可以给自己的构建打补丁。发行版、控制面板厂商和付费支持公司，往往会在自己的版本支持期内一直修复它们自带的 PHP。
所以一台服务器显示 PHP 7.4 或 8.1，也可能已经修复。显示的版本号低于 8.2.35 的服务器同样如此。光看版本号判断不了，要看软件包的更新日志。
我们在 2026 年 10 月 21 日最后一次检查时的状态如下。
| 来源 | 旧分支 | 最后一次检查时的状态 |
|---|---|---|
| Ubuntu | 22.04 php8.1 | 已在常规仓库中修复（USN-8948-1） |
| Ubuntu Pro（ESM） | 20.04 php7.4、18.04 php7.2 | 已修复（USN-8948-2）。16.04 和 14.04 需要 Pro 加上 Legacy Support 附加服务 |
| Debian | 12 php8.2（LTS） | 已在 8.2.35-1~deb12u1 中修复（DLA-4848-1）。11 的 php7.4 未出现在跟踪器中 |
| Red Hat Enterprise Linux | 8 的 php:7.4 模块 | 已修复（RHSA-2026:87080）。php:8.2 以及 RHEL 9 和 10 还没有修复 |
| CloudLinux alt-php | 5.2 到 8.5 | “准备中”。只有 alt-php74 的构建标为已发布 |
| cPanel EasyApache 4 | ea-php74、80、81 | 25.91 中包含 backport 修复，列出了两个 CVE |
| Plesk | 7.4、8.0、8.1 | 还没有修复 |
| Sury | Ubuntu 22.04 和 24.04 上的 8.1、8.0、7.4 | 10 月 21 日已发布。8.1 和 8.0 的更新日志我们没有核实 |
| Docker 官方镜像 | 8.1 及更早 | 未修复 |
| Windows 构建 | 8.1.34、8.0.30、7.4.33 | 未修复 |
| Homebrew | php@8.1 | 未修复 |
有两点要注意。厂商经常更新这些页面，依赖表中某一行之前，先打开各发行版指南里链接的厂商页面核对。另外，“no fix planned”这类说明，比如 Amazon Linux 对 Amazon Linux 2023 上 PHP 8.1 的标注，意思是这个包会一直有漏洞。
检查发行版的包要看它的更新日志，然后重启 PHP。
apt changelog php8.1-fpm | grep -m1 -E 'CVE-2026-10961[89]' # Debian, Ubuntu
rpm -q --changelog php-fpm | grep -m1 -E 'CVE-2026-10961[89]' # RHEL family
Remi 仓库和 Sury 的更新日志里可能不写 CVE 编号。遇到这种情况，就拿已安装的版本和已修复的版本对比。怎么查看正在运行的版本，见 打补丁之后。
付费扩展支持
TuxCare、HeroDevs、Zend 等公司在官方停止支持后继续出售打过补丁的 PHP 构建。我们最后一次检查时，HeroDevs 在自己的页面上针对 PHP 7.4、8.0 和 8.1 列出了这两个 CVE。Zend 为其长期支持构建提供修复的消息，我们只看到了二手报道。TuxCare 那边我们什么也没找到。付钱之前，请厂商书面确认两个 CVE 编号都在覆盖范围内。对比见 旧版 PHP 的选择。
你的选择
1. 升级。 只有这条路能连下一个漏洞一起解决。我们推荐 PHP 8.4，如果某个插件或扩展还不支持，就用 8.3。不建议换到 8.2，它在 2026 年 12 月 31 日就结束支持。指南见 7.4 升到 8.4、8.1 升到 8.4、8.2 升到 8.4，也可以看 全部升级指南。
2. 用发行版的 backport。 免费或包含在订阅里，一直能用到你的操作系统版本结束支持。版本号还是旧的，所以要按上面的方法查更新日志。
3. 购买厂商的扩展支持。 适合暂时还迁不走的代码。选一家能书面确认两个 CVE 的厂商。见 旧版 PHP 的选择。
4. 交给主机商处理。 在虚拟主机和托管主机上，PHP 由主机商运行。问清楚你的站点用的是哪个构建，worker 是什么时候重启的。三个问题见 情况判断 和 虚拟主机指南。很多主机商允许你在面板里选更新的 PHP 版本，这在虚拟主机上是最快的修复方式。各家主机商的说明见 主机商。
如果这周以上办法对某个站点都行不通，就把它从公网撤下来，或者在代理上加 VPN 或登录保护。这样能缩小暴露面，但并没有修复漏洞。官方的临时设置见 暂时还不能升级。
选择你的分支
- PHP 8.3，已在 8.3.36 中修复，支持到 2027 年。
- PHP 8.2，已在 8.2.35 中修复，2026 年 12 月 31 日结束支持。
- PHP 8.1，源码 backport，已于 2025 年 12 月 31 日结束支持。
- PHP 7.4，源码 backport，已于 2022 年 11 月 28 日结束支持。
- PHP 5，PHP 项目没有提供任何东西。
- 旧版本和扩展支持，8.0、7.x 和各家厂商。
最后审阅：2026年10月22日