如何修复 PHP2Shell：升级 PHP 并重启工作进程

目标版本

• 8.5 分支的 PHP 8.5.12 或更新版本
• 8.4 分支的 PHP 8.4.27 或更新版本
• 8.3 分支的 PHP 8.3.36 或更新版本
• 8.2 分支的 PHP 8.2.35 或更新版本
• 更老的版本：迁到上述之一，或确认厂商回移植，并把回移植当作过渡。CISA 称如果无法更新，就把未修补的 PHP 下线，并明确包括 PHP 8.1 及更早版本。

源码包和 Windows 构建在 PHP 下载页。php.net 称 Linux 发行版和 LTS 厂商在公开释放之前就拿到了补丁，因此发行版软件包往往是正确路径。同一则说明称，志愿者维护的 Remi 仓库 rpms.remirepo.net 在 10 月 21 日不会有这些更新，并敦促依赖它的人改用发行版软件包或从源码构建。

Debian、Ubuntu 及其他 apt 系统

刷新元数据，并安装你的软件源实际发布的 php 更新。包名跟随次版本（php8.3-fpm、php8.3-cli、php8.3-common，若使用 mod_php 还有 Apache 模块包）。如果候选版本仍低于修复版本，你是在等发行版，而不是少打了一个参数。

sudo apt-get update
apt-cache policy php8.3-cli php8.3-fpm php8.3-common
sudo apt-get install --only-upgrade php8.3-cli php8.3-fpm php8.3-common
php8.3 -v
# 看 Web SAPI，而不只是命令行：
php-fpm8.3 -v
sudo systemctl restart php8.3-fpm
# 若 Apache 加载了 mod_php，也要重启 Apache：
sudo systemctl restart apache2

RHEL、Alma、Rocky、Fedora：dnf 或 yum

sudo dnf clean expire-cache
sudo dnf update php php-cli php-fpm php-common
php -v
php-fpm -v
sudo systemctl restart php-fpm
# httpd 下的 mod_php：
sudo systemctl restart httpd

Docker 及其他镜像

重新构建并重新部署。拉取新的基础镜像，在替换掉真正提供流量的工作负载之前不会生效。官方镜像标签通常跟随 PHP 版本；固定标签之前，先在 Docker Hub 上确认它存在。Google Cloud 对 Cloud Run 和 GKE 的说明是同一件事：重建你部署的镜像，除非你用的是 Google 说它正在替你更换的无服务器基础镜像。

FROM php:8.3.36-fpm
# 或者：php:8.3.36-apache、php:8.4.27-fpm、php:8.2.35-fpm、php:8.5.12-cli

# 然后在主机上：
# docker pull php:8.3.36-fpm
# docker build -t your-app:php2shell-fix .
# 重新部署，并确认正在运行的容器中的 PHP 版本

cPanel

1. 先更新 cPanel 本身，让 EasyApache 能够提供已修补的 PHP 构建。菜单会变；如果标签不同，以 cPanel 文档为准。
2. 在 WHM 中打开 EasyApache 4，配置不低于该分支修复版本的 PHP。MultiPHP Manager 用来把域名指向特定 PHP 版本。
3. 把面向互联网的域名从 PHP 8.1 或更老的处理程序上移开，除非厂商明确说该构建包含回移植。
4. 在 WHM 中重启 Apache 和 PHP-FPM，然后用检查进程池的同一方式核对域名的 PHP 版本，并删除临时探测页面。

Plesk

1. 安装 Plesk 和系统软件包更新。当前的点击路径见 Plesk 文档。
2. 在“工具与设置”中查看更新和 PHP 处理程序列表。域名的 PHP 设置显示订阅实际运行的版本。
3. 选择已修补的处理程序（8.2.35、8.3.36、8.4.27 或 8.5.12，或你已核实的厂商构建）。先应用到公开站点。
4. 重启 Plesk 正在使用的 PHP 服务，并对着域名而不是仅仅对着面板主机做版本确认。

宝塔面板

宝塔于 2026 年 10 月 22 日更新的公告称，Linux 与 Windows 面板已同步 8.2.35、8.3.36、8.4.27 和 8.5.12。仅 Linux 的 7.4.34、8.0.31 和 8.1.35 是宝塔自己的包，不是 PHP 项目的发行版。点击路径和 Windows 上并不完整的设置写在宝塔页面。

mod_php 与 PHP-FPM 的差别

两者都在 PHP 项目的风险名单上。mod_php 风险最高，因为已演示的未授权路径在应用代码之前触发。重启 Apache 才会重新加载 mod_php。PHP-FPM 是单独的进程：重启每一个进程池（systemctl restart php8.3-fpm，或对应的单元），并记住进程池可以固定自己的二进制文件。shell 的 PATH 上的 php 可能与进程池不是同一个构建。FrankenPHP、php-cgi 和 LiteSpeed 被 PHP 列为提供网页请求，因此在范围内；请遵照这些厂商自己的升级说明，不要假定一个 apt 的 php-fpm 包覆盖了它们。

临时措施：PHP 称它们并不完整

只把这些当作从 php.net 公告抄来的过渡。它们降低特定路径的暴露，不能让主机变得安全。把它们放进 php.ini，或放进管理员级别的进程池或 Apache 设置（php_admin_value）。按照 PHP 的说法，对 session 上传这条路径，ini_set() 和目录级 .user.ini 发生得太晚。

CVE-2026-109618

• memory_limit=-1，并锁住，使应用不能再设回有限值。PHP 称这去掉了可控的内存限制失败，但底层分配失败仍然可能走到这个缺陷。
• 较低的 post_max_size。PHP 建议：应用不需要上传时用 8M，需要时用 32M，并使 upload_max_filesize 低于 post_max_size。
• 在 Web 服务器或代理上限制请求大小，包括没有可用 Content-Length 的请求。PHP 列出了解码后的请求大小、输入字段数、multipart 部件数、头数量和嵌套深度。
• 用容器或 cgroup 限制作为可用性边界，只杀掉受影响的工作进程。PHP 称不要用 RLIMIT_AS 或 RLIMIT_DATA 代替，因为它们本身可能造成那个有漏洞的分配失败。

CVE-2026-109619

• session.upload_progress.enabled=0，然后重启每一个工作进程。PHP 称这只挡住已确认的 session 路径，挡不住其他变体。
• 仅在 PHP 8.5 上设置 fatal_error_backtraces=0，然后重启。PHP 称这只挡住已确认的 fatal backtrace 路径。
• 去掉会在初始化前发出诊断的无效或已弃用的按请求设置。用 error_reporting、display_errors 或 @ 把错误藏起来并不能关上这个缺陷。
• 修复攻击者能够碰到的致命错误和执行超时，包括回调以及上传或导入清理中的失败。这是项目的原话；它是加固提示，不是在说应用代码没有 bug 就能让 FPM 安全。

Web 应用防火墙

CISA 称，在系统完成更新之前，Web 应用防火墙可能提供一些保护。Cloudflare 称覆盖此问题的托管规则自 2026 年 10 月 21 日 03:02 UTC 起对免费和付费 WAF 客户部署，是在禁运期内与 PHP Foundation 等一起开发的，并且仍然要求客户修补。规则可以被绕过。Cloudflare 自己的文章称，它看到载荷在变化，攻击者试图绕过规则。保留 WAF。不要把它当作修复。

升级之后

• 在回答 HTTP 请求的那个 SAPI 上确认版本，然后重启它。Expel 和多伦多大学通告都强调这次重启。
• 优先处理面向互联网的系统，然后是处理不可信上传或导入的系统，然后是设备。英国 NCSC 和加拿大网络安全中心都说，捆绑 PHP 的第三方产品需要各自厂商的更新。
• 如果主机曾经暴露且你无法迅速修补，CISA 建议留意 PHP 工作进程启动 shell 或下载工具。英国 NCSC 称，在信任一台曾经暴露、后来才升级的主机之前，要查找后门；当团队做不到这种检查时，英国机构可联系其认可的事件响应服务商。我们没有一份经过核实的指标清单可以加到这条建议上。
• 英国通告所链的 NCSC-NL 笔记是产品清单的起点，不是未列入产品就安全的证明。