PHP2Shell 漏洞预警：CVSS 9.2 风险排查与修复指南

PHP 官方已发布严重安全更新预告，计划于 2026 年 10 月 21 日（周三）北京时间 22:00，即 UTC 14:00 发布安全更新，修复两项评分均为 CVSS v4.0 9.2 的严重漏洞。

安全研究机构将相关风险称为 PHP2Shell。运行 PHP 网站、CMS、电商系统及接口服务的用户，应立即排查运行环境，做好补丁发布后的升级准备。

本文为补丁发布前的预警与操作指南。截至发稿时，PHP 官方尚未公布完整技术细节、准确的受影响版本列表及修复版本号。请以正式安全公告为最终依据。

一、PHP2Shell 漏洞目前确认了哪些信息？

PHP 官方同时表示，如果漏洞细节提前公开，或发现实际利用证据，安全更新可能提前发布。因此，运维人员应从现在开始关注公告，不宜仅在计划发布时间上线查看。

目前流传的“PHP 5.4 及以上全部受影响”等说法来自安全研究通报，尚不能替代官方的影响范围说明。部署 Magento、Shopware、WooCommerce、WordPress 等 PHP 应用的用户，应将相关运行环境纳入排查，但不能据此认定每一种部署方式都已确认可被利用。

Sansec 预测，补丁公开后可能迅速出现自动化攻击。其提到的“15 分钟”属于风险预测，不代表存在可以放心等待的安全窗口。

二、修复重点是 PHP 运行环境

仅更新网站程序、安装安全插件或升级服务器面板，不能证明底层 PHP 漏洞已经修复。

处理此类风险，应确认网站实际使用的 PHP 运行环境已经安装官方修复，或安装了软件包维护方明确提供的对应安全补丁。

但在技术细节尚未公布时，也不宜断言“任何 WAF 或配置措施都绝对无效”。正确做法是区分两类措施：

• 漏洞修复： 安装明确包含对应漏洞修复的 PHP 版本或发行版安全更新。
• 临时缓解： 限制访问、隔离服务，或采用厂商确认有效的防护规则，降低补丁部署前的暴露风险。

尤其需要注意，disable_functions 不能替代安全补丁。禁用 exec、system、shell_exec 等函数，不应被视为已经阻断底层远程代码执行风险的证明。

三、补丁发布前，先完成环境排查

1. 查询 PHP 版本及配置路径

在服务器终端执行：

php -v
php --ini

上述命令显示的是当前命令行调用的 PHP 信息。

命令行 PHP 与网站使用的 PHP 可能不同。 一台服务器可能同时安装 PHP 7.4、8.2、8.3 等多个分支，不同网站也可能连接不同的 PHP-FPM 服务。

使用 systemd 管理 PHP-FPM 的环境，可以辅助查看服务：

systemctl list-units --type=service --all 'php*-fpm.service'

随后结合网站配置或面板设置，逐一确认：

• 每个网站实际使用的 PHP 分支和版本。
• PHP 来自系统软件源、第三方软件源、面板编译还是容器镜像。
• 是否存在仍在运行的旧 PHP-FPM 实例。
• 定时任务、队列进程和其他后台程序使用哪个 PHP 可执行文件。

容器和面板环境还需要分别检查，不能仅凭宿主机的 php -v 判断所有业务已经完成升级。

2. 准备备份与维护窗口

升级前备份网站文件、数据库、PHP 配置、Web 服务配置及扩展清单，并确认备份能够恢复。

提前检查业务对 PHP 版本和扩展的要求。跨大版本迁移时，应特别关注程序兼容性、数据库驱动和加密扩展。

如果升级失败，需要回退到存在漏洞的环境，应保持访问限制，避免直接重新对公网开放。

四、PHP 8.2—8.5 用户如何更新？

截至本文发布时，PHP 上游仍提供支持的分支包括 8.2、8.3、8.4 和 8.5。

需要强调的是：使用这些分支，不代表已经修复本次漏洞。必须安装包含此次修复的具体版本或安全软件包。

补丁发布后，先核对：

1. PHP 官方公布的受影响版本及修复版本。
2. 当前软件源是否已经提供对应更新。
3. 软件包维护方是否明确说明已修复相关 CVE。

Debian / Ubuntu 软件包安装示例

以下以通过 APT 安装 PHP 8.3-FPM 的环境为例。其他分支、面板编译版和容器环境需要使用各自的升级方式。

刷新软件包索引并查看候选版本：

sudo apt-get update
apt-cache policy php8.3-fpm php8.3-cli php8.3-common

确认候选软件包包含本次漏洞修复后，才能将其作为修复更新安装。 “已经是最新版本”仅说明当前软件源没有更高候选版本，并不自动证明漏洞已修复。

下面展示核心软件包的升级方式。执行前，应将本机已安装、需要同步更新的同分支扩展包，例如 php8.3-mysql、php8.3-curl、php8.3-xml 等，一并纳入升级：

sudo apt-get install --only-upgrade \
  php8.3-fpm php8.3-cli php8.3-common

检查安装过程是否存在依赖冲突、软件包被保留或更新失败。

面板与容器环境

面板安装的 PHP： 使用面板对应的 PHP 更新渠道，并核对更新说明和实际安装版本。仅更新面板程序，不代表 PHP 已经更新。

容器运行的 PHP： 确认镜像包含修复后，拉取或重新构建镜像，再重新创建 PHP 容器。单纯重启旧容器不会自动替换其中的 PHP。重新创建前，应确认数据库、上传文件及其他持久化数据已有正确挂载和备份。

五、升级后，需要重启哪个服务？

安装更新后，应让实际处理请求的 PHP 进程加载修复后的程序。重启可能短暂影响请求，应按预先安排的维护流程执行。

对于示例中的 PHP 8.3-FPM：

sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager

请根据实际部署替换服务名称。

不同运行方式需要分别处理：

仅重启 Nginx，不能使仍在运行的旧 PHP-FPM 进程自动完成更新。

六、PHP 8.1 及以下版本怎么办？

PHP 8.1、7.x、5.x 等分支已经结束 PHP 上游的常规安全支持，应尽快安排迁移。

但需要区分“PHP 上游停止支持”和“发行版是否仍提供维护”：部分 Linux 发行版或商业维护服务可能向旧版本回移安全补丁。因此，应查询当前软件包维护方的正式公告，不能只看 PHP 主版本号判断修复状态，也不能默认所有旧版本都能获得补丁。

如果当前环境没有明确可用的修复，建议：

1. 限制公网对相关 PHP 应用的访问，必要时暂时隔离服务。
2. 在兼容性验证后，迁移至受支持且已经修复的 PHP 版本。
3. 核对实际运行环境与补丁状态，再恢复正常访问。

新迁移项目还应考虑支持期限：PHP 8.2 的上游安全支持将于 2026 年 12 月 31 日结束。可根据业务兼容性选择支持周期更长的分支。

七、暂时无法升级，如何降低风险？

CERT-EU 建议，在无法立即修复时，考虑将面向互联网的应用与公共网络隔离。

可根据业务情况采取以下措施：

• 将必要访问限定为可信 IP 或 VPN 用户。
• 在反向代理层提供静态维护页，暂时停止向 PHP 应用转发公网请求。
• 同时限制源站直接访问，避免绕过前置防护。
• 关注安全厂商是否发布经过确认的临时防护规则。

只限制 SSH、面板或网站后台登录，并不等于限制了公网 PHP 请求。 如果网站前台仍然能够调用存在风险的 PHP 环境，相关暴露面可能仍然存在。

在官方确认触发条件前，不应将某个网上流传的配置修改视为通用修复方案。

八、如何确认修复已经生效？

完成升级后，应核对以下结果：

• 已安装的软件包版本与官方或维护方的修复公告一致。
• 所有承载网站的 PHP 实例均已处理，没有遗漏旧分支。
• PHP-FPM、Apache 模块或容器已经加载修复后的程序。
• 常驻队列和后台任务已经重新启动。
• 网站登录、数据库连接、上传及交易等关键功能正常。

发行版可能通过回移补丁修复漏洞，版本显示未必与 PHP 上游最新版本完全一致。判断时，应结合软件包完整版本号和维护方安全公告。

如需通过网站检查 PHP 运行信息，应使用仅本机或可信运维地址可访问的诊断入口，检查后及时删除，避免公开暴露 phpinfo() 页面。

如果已经发现异常文件、未知进程或可疑请求，应同时开展入侵排查。安装补丁不会自动清除已经植入的后门。

官方信息入口：

• PHP 安全更新预告
• PHP 版本支持周期
• CERT-EU 安全通报
• Ubuntu 安全公告