你受影响吗？
受影响。只要没有打上 backport，每个 PHP 7.4 构建都受影响。两个漏洞都在 PHP 本身，所以服务器上的每个站点都暴露在外，不管它跑的是什么程序。
例外是发行版或厂商给自己的 7.4 包打了补丁。Ubuntu 20.04 和 Debian 11 带的是 PHP 7.4，RHEL 8 以 AppStream 模块的形式提供它。这些厂商在各自的支持期内打补丁，有的只在 Ubuntu Pro 这类付费计划里提供。如果你的包来自这些渠道，看它们针对这两个 CVE 编号发布的安全公告，就知道是否已经覆盖。版本号仍然显示 7.4。
官方修复和它的局限
PHP 7.4 在 2022 年 11 月 28 日 结束了支持。PHP 项目不会为 PHP2Shell 发布 7.4 的新版本。
PHP 项目的做法是在 php-src 仓库里放出一个最小的源码分支 PHP-7.4-CVE-2026-109618-109619。分支里只有这两个修复，没有别的内容。
源码分支不是安装包
要使用它，你得自己编译 PHP，扩展和编译选项要和现在的构建保持一致，而且以后每出一个漏洞都要再来一遍。对大多数站点来说这不现实。这个分支面向的是发行版和厂商。
免费的出路，按工作量从小到大
1. 先查你的包是不是已经打过补丁。 在 Ubuntu 或 Debian 上这样查。
php -v
apt changelog php7.4-fpm | grep -E 'CVE-2026-10961[89]'
两个编号都出现的话，重启 PHP，这两个漏洞就算覆盖了。
sudo systemctl restart php7.4-fpm
2. 升级到受支持的分支。 8.3.36 和 8.4.27 已修复 PHP2Shell，分别支持到 2027 年和 2028 年。从 7.4 升到 8.x 是一次真正的迁移。PHP 8.0 删除和改动的内容不少，老插件和老库经常跑不起来。先在副本上测试，目标选 8.3，不要选 8.1 或 8.2。步骤见 PHP 8.3。
3. 用虚拟主机的话， 在控制面板里把 PHP 版本切到 8.3 或更高，再确认已经生效。该向服务商问哪些问题，见 情况判断。
今天还不能升级的话
官方给出的临时设置对 7.4 同样适用。它们能缩小暴露面，但不能让服务器变安全。
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M ; 站点要上传文件时用 32M
php_admin_value[upload_max_filesize] = 4M
php_admin_value[max_input_nesting_level] = 16 ; 默认 64，调低
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[log_errors] = on
php_admin_value[error_reporting] = E_ALL
把这些值写进 php.ini 或 FPM pool，不要写在 .user.ini 里，然后重启所有 worker。另外在前面的代理层限制请求。不要设置 RLIMIT_AS 或 RLIMIT_DATA。每一行的理由见 首页。
需要别人帮忙时
- 扩展支持。 TuxCare、HeroDevs、Zend 等厂商出售旧版 PHP 的补丁构建。HeroDevs 已确认它的 7.4、8.0 和 8.1 构建覆盖两个 CVE。我们检查时，Zend 和 TuxCare 在各自的网站上还没有这样的说明。对比见 旧版 PHP 的选择。
- 有计划地迁到 8.3。 我们可以 和你一起确定范围，书面约定并开具发票。
最后审阅：2026年10月22日