宝塔面板修复 PHP2Shell 漏洞 - 文章

2026 年 10 月 21 日，PHP 官方发布紧急安全更新，修复了两个被合称为 PHP2Shell 的远程代码执行漏洞：CVE-2026-109618（内存耗尽引发的内存破坏）和 CVE-2026-109619（跨请求残留全局状态导致的释放后使用）。两者 CVSS v4.0 均为 9.2，攻击者无需登录，构造恶意 HTTP 请求就可能拿到服务器权限。

更麻烦的是时间线。Amazon Threat Intelligence 称在公开披露前的 10 月 17 日就观测到了利用尝试，公开后扫描和攻击迅速铺开。对于还在用旧版 PHP 的站点，这不是“找时间再升”的问题，而是应当按应急事件处理。

这篇文章不谈漏洞利用细节，只讲一件事：在宝塔面板上，怎么把 PHP 升到安全版本，以及升不动时怎么把风险压下来。

先搞清楚：哪些版本算安全

受影响的是所有对外提供 Web 请求的 PHP 运行方式，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。其中 mod_php 风险最高，恶意请求可能在应用代码执行前就触发漏洞。

对照下面这张表，低于修复版本的就是风险版本：

PHP 分支	修复版本	说明
8.5	8.5.12	官方安全版
8.4	8.4.27	官方安全版
8.3	8.3.36	官方安全版
8.2	8.2.35	官方安全版
8.1	8.1.35	宝塔打包的 Linux 修复版
8.0	8.0.31	宝塔打包的 Linux 修复版
7.4	7.4.34	宝塔打包的 Linux 修复版
7.3 / 7.2 / 7.1 / 7.0	7.3.34 / 7.2.35 / 7.1.34 / 7.0.34	宝塔自建 Linux 修复版

注意，PHP 7.4 到 8.1 官方早已停止安全维护，这些版本由宝塔基于官方回补补丁重新打包；7.0 到 7.3 则是宝塔逐行回移适配的版本，官方明确建议先在测试环境验证。

第一步：确认站点实际跑的版本

宝塔上经常同时装着好几个 PHP 分支，最容易犯的错是只升了其中一个。

先看面板：进入「网站」→ 选中站点 →「PHP 版本」，这里显示的是该站点真正调用的版本。再去「软件商店」→「已安装」，核对所有还在运行的 PHP 分支。

命令行再复核一次，CLI 和 Web 可能不是同一个版本：

php -v
php-fpm -v
# 宝塔编译安装的 PHP 通常在 /www/server/php/ 下
ls /www/server/php/

如果有多个站点、多个分支，把「站点 → PHP 版本」列成清单，逐个处理，别只看 php -v 的结果就收工。

第二步：升级 PHP 8.2 及以上

PHP 7.4 及以上在 Linux 面板上可以直接走软件商店，这是最省事的一条路径。安装安全补丁不需要先升级宝塔面板本身。

先备份站点、数据库和 PHP 配置，条件允许直接给服务器打快照。
进入「软件商店」→「已安装」。
点右上角的「更新软件列表 / 支付状态」，拉取最新软件信息。
找到站点正在使用的 PHP 分支，点「更新」，等待安装完成。
确认该 PHP 服务已经重启；如果没有自动重启，手动重启一次，让所有工作进程换成修复后的二进制。
回到站点确认 PHP 版本，再验证登录、上传、数据库连接等核心功能。

在宝塔软件商店更新 PHP

如果开启了系统加固，更新时提示规则拦截，按提示临时关闭相关防护，升级完成后再恢复。不要为了省事长期关掉。

还有一个细节：升级完成后，旧的工作进程可能还在内存里跑旧版本。必须重启 PHP 服务，不能只刷新页面。

第三步：PHP 7.0 到 7.3 走修复脚本

这几个分支在宝塔里不能只靠点「更新」解决，官方给了单独的安装命令。操作前务必备份站点、数据库、PHP 环境和配置，或者直接创建服务器快照；脚本会重启 PHP，站点会短暂不可用，放在业务低峰期执行。

在宝塔面板的「终端」里，按站点实际版本选一条执行：

# PHP 7.0 -> 7.0.34
curl -fL -o php7_cve.sh https://download.bt.cn/install/php7_cve.sh && bash php7_cve.sh install 70

# PHP 7.1 -> 7.1.34
curl -fL -o php7_cve.sh https://download.bt.cn/install/php7_cve.sh && bash php7_cve.sh install 71

# PHP 7.2 -> 7.2.35
curl -fL -o php7_cve.sh https://download.bt.cn/install/php7_cve.sh && bash php7_cve.sh install 72

# PHP 7.3 -> 7.3.34
curl -fL -o php7_cve.sh https://download.bt.cn/install/php7_cve.sh && bash php7_cve.sh install 73

升级后检查 PHP 扩展是否正常加载、站点能否访问、上传和登录是否正常。发现扩展异常，及时用快照或备份回滚。多个旧分支同时在跑，就要分别升级、分别验证。

Windows 面板的情况不一样：PHP 8.2 及以上可以通过软件商店升级；8.1 及更早版本目前没有对应修复包，只能先做临时缓解，并尽快规划迁移到受支持的分支。

升不动时：先做临时加固

如果因为兼容性、业务窗口或旧系统绑定，暂时没法升级，宝塔提供了几层缓解手段。但要说清楚：这些都不能替代补丁。

企业版一键加固

宝塔 Linux 企业版 13.1 及以上版本，可以在「安全中心」→「安全概览」→「首页风险」里点「查看」，重新扫描后找到 CVE-2026-109618、CVE-2026-109619 对应的 PHP 风险项，点「修复」。

修复完成后，必须重启结果里列出的每一个 PHP 服务，然后重新扫描，并测试上传、登录等功能。这个功能只降低部分攻击路径的风险，扫描显示“已修复”也不等于 PHP 已经是安全版本，仍然要核对实际版本号。

修改 PHP 配置

在「软件商店」→ 对应 PHP →「设置」→「配置修改」中，可以按官方建议调整：

; 缓解 CVE-2026-109618：移除可预测的单请求内存限制
; 注意：这会放开单请求内存上限，必须配合容器或系统层内存限制
memory_limit = -1

; 缓解 CVE-2026-109619 的已确认路径
session.upload_progress.enabled = 0

; PHP 8.5 可同时关闭致命错误回溯
fatal_error_backtraces = 0

改完要重启全部 PHP 工作进程。memory_limit = -1 不是常规配置，只是应急手段；如果不加 cgroup 或系统层面的内存边界，单个失控请求可能把整台机器拖垮。另外可以把 FPM 的 pm.max_requests 设为 1，切断跨请求状态传递，但性能代价明显，只适合短时间兜底。

WAF 与主机防护

宝塔 Nginx 防火墙 9.9.0 及以上版本已经加入 PHP2Shell 攻击拦截规则。进入「WAF」确认总开关和站点防护已开启，再在「防护事件 → 拦截记录」里观察是否有命中 php2shell攻击 过滤器的请求。

宝塔 WAF 拦截记录

WAF 能挡住已知攻击形状，但绕过的可能性始终存在，只能用来争取时间。系统加固、堡塔防入侵、PHP 网站安全告警也是同样的定位：纵深防御，不是漏洞修复。

升级后的验收清单

每个仍在使用的 PHP 分支都达到对应修复版本，而不是只升了主站那一个。
Web 实际使用的版本已确认，CLI 版本也单独核对过。
PHP 服务已重启，旧进程没有继续驻留。
站点首页、后台登录、文件上传、数据库连接均正常。
PHP 扩展加载正常，错误日志没有新增异常。
WAF、系统加固、防入侵的开关状态符合预期，没有被升级流程顺手关掉。

几个容易踩的坑

第一，只升级了 PHP 版本号，没有重启服务。旧 worker 还在跑，漏洞就还在。

第二，只处理了一个分支。宝塔多版本共存很常见，一个站点用 8.2，另一个还在 7.4，就要分别升级。

第三，把 WAF 或“一键加固”当成最终修复。官方文档写得很明确：补丁升级仍是必要步骤。

第四，从网上找来源不明的“一键修复脚本”。这次漏洞热度高，投毒脚本也跟着多，优先使用宝塔官方文档里的命令和面板入口。

第五，忽略 PHP 8.2 的生命周期。8.2 的安全支持将在 2026 年 12 月 31 日结束，这次升完只是过关，长期还是应该规划到 8.3 或 8.4。

小结

这次 PHP2Shell 的关键点在于：漏洞在 PHP 运行时内部，升级 WordPress、Drupal 或加一条 WAF 规则都修不掉，唯一完整的修复是把 PHP 升到 8.2.35、8.3.36、8.4.27 或 8.5.12。宝塔已经把这些版本以及旧分支的修复包同步到了面板里，剩下要做的是确认版本、备份、升级、重启、验证。

如果服务器上还有 7.x 甚至 5.6 的老站点，建议借这次机会做一次版本盘点。补丁能解决眼前的问题，但停止维护的分支迟早还会遇到下一次。