PHP 爆出 PHP2Shell 组合高危漏洞！附应急解决修复方法

PHP 开发团队发现了两处严重漏洞，并因此计划发布一次紧急安全更新。这两个漏洞的 CVSS 4.0 评分均为 9.2 分，一旦被利用，攻击者可在存在漏洞的服务器上实现远程代码执行。安全研究员将该漏洞组合命名为 PHP2Shell，使用 PHP 的系统管理员需要尽快做好应急处置准备。

该漏洞之所以影响重大，首要原因是 PHP 的普及程度极高。PHP 诞生于 1995 年，至今仍是开发动态 Web 应用的主流技术之一，是 WordPress、Drupal、Joomla、Magento 等建站平台，以及大量企业业务软件、主机控制面板的底层组件。因此，PHP 引擎本身的漏洞，其波及范围远大于单个 CMS 或插件的漏洞。

PHP 爆出 PHP2Shell 组合高危漏洞

2026 年 10 月 20 日发布的官方公告确认了这两个高危问题，并宣布补丁将于意大利当地时间 10 月 21 日（周三）16 时推出。本次打破常规更新节奏、紧急发布补丁，是因为部分保密信息提前外泄。

PHP2Shell：目前已知的两个高危漏洞

这两个漏洞对应的 CVE 编号为 CVE-2026-109618、CVE-2026-109619，相关信息最早通过非官方渠道流出，随后被安全研究团队跟进证实。

根据 watchTowr 和 Huntress 收集的情报，漏洞属于远程代码执行（RCE）类型：这类漏洞允许攻击者在不物理接触服务器的前提下，在目标设备上运行任意代码。

不过现阶段还有很多信息尚未公开：受影响的 PHP 组件、漏洞触发条件、是否依赖特定扩展、特殊配置或运行模式，都没有明确披露。

9.2 的 CVSS 高分代表风险等级极高，但这个分值本身不会透露具体的攻击链路。

哪些 PHP 版本存在风险

早期消息称受影响版本可追溯至 PHP5 系列。但结合 PHP 官方维护周期来看，目前官方仅维护 4 个分支：8.2、8.3、8.4、8.5。

• PHP 8.2、8.3 仅接收安全补丁；

• PHP 8.4、8.5 仍处于全功能活跃支持阶段。

已经停止生命周期的版本（PHP 8.1、8.0、全部 7.x 及更早版本），开发团队不会再提供官方补丁。

安全厂商 Mallory 基于 Shodan（互联网服务测绘搜索引擎）的数据做了统计：截至 2026 年 10 月 20 日，公网有约 88.4 万台主机上报的 PHP 版本为 8.1 或更老版本；在主动暴露 PHP 版本标识的 150 万台主机里，这部分占比接近 59%。

这个数据也印证运维圈长期面临的痛点：大量 PHP 环境版本老旧，很多是配套业务系统无法轻易升级，升级会引发兼容性故障。 比如多年前开发的企业内部管理系统，可能依赖新版 PHP 已经移除的特性。直接升级 PHP 而不做业务测试，极易导致核心服务瘫痪；但长期运行无支持的旧版本，会持续累积安全风险，并且再也等不到官方修复。

为什么 PHP 引擎漏洞比 WordPress 插件漏洞更危险

WordPress 插件漏洞通常只影响安装了该插件、且是特定版本/配置的站点。而 PHP 引擎的漏洞完全不同：PHP 负责解析、执行 Web 应用代码，处理变量、对象、HTTP 请求、文件读写和数据库交互。

在大量 Linux 服务器上，Nginx 通过 PHP-FPM 和 PHP 通信，由 PHP-FPM 进程执行脚本；Apache 既可以直接加载 PHP 模块，也能转发请求给 PHP-FPM。除此之外还有 PHP-CGI、Windows 平台的 mod_php 等运行方式。

如果漏洞位于 Web 请求正常处理流程中就可触达的模块，那么所有用到该模块的应用都会被波及，不需要 WordPress、Drupal 或是自研代码本身存在程序 bug。

不过 PHP2Shell 的具体利用机制还没有公开，暂时无法确定上述全部运行模式都会受影响，或是漏洞有更苛刻的触发条件。

PHP-FPM 一般使用非 root 的普通用户运行业务进程；漏洞成功利用后，攻击者通常只能拿到该运行用户对应的文件、数据库凭据等权限，不一定直接拿到服务器最高管理员权限。 但如果多个站点共用同一个运行账号、网页目录存放明文密码文件，或是进程权限配置过大，危害会进一步放大。在漏洞修复前，做好权限隔离可以有效缩小攻击造成的损失。

PHP 服务器与 WordPress 主机应当立刻执行的操作

第一件事：梳理线上业务实际在用的 PHP 版本。

在 Linux 终端执行 php -v 只能查看 Shell 环境下的 CLI 版本，不代表 Web 服务正在使用的 PHP。一台服务器上并存多 PHP 版本时，CLI 调用的二进制程序，和各个站点对应的 PHP-FPM 池很可能不是同一个。需要核对正在运行的服务、各个 PHP-FPM 池、程序路径与 Web 服务配置。

使用 cPanel、Plesk 等主机面板的用户，需要单独查看每个域名绑定的 PHP 版本。同一台服务器上，不同网站可能分别跑着 PHP8.4、8.2 甚至老旧 7.x 版本，适配不同业务。

WordPress 站点可以在后台【工具 → 站点健康 → 信息 → 服务器】查看站点 PHP 版本。这个方法很方便，但不能替代服务器上其他 PHP 环境的资产盘点。

第二件事：提前准备部署官方补丁。

使用 Linux 发行版包管理器的服务器，留意发行方软件源和安全公告：部分发行版会采用回移植补丁，在不改动主版本号的情况下修复漏洞。

容器化环境要检查镜像，使用修复后的镜像重建容器；仅仅升级宿主机上的 PHP，不会自动更新 Docker 容器内部的 PHP 解释器。

虚拟主机/托管主机用户，优先联系服务商确认更新计划；在自行修改配置之前，先确认服务商是否已经安排安全更新。

补丁到来之前：php.ini 临时缓解配置

修改 php.ini，修改后重载 PHP 配置：

1
2
3
4
5
6
7
8
9
10
11
; 关闭上传进度 session 存储，直接封堵最主流利用链
session.upload_progress = Off

; 强制 session id 仅从 Cookie 读取，禁止 POST/GET 里携带 SID（阻断 SID 绕过）
session.use_only_cookies = On

; 开启 session 严格模式，拒绝未初始化的 session ID
session.use_strict_mode = On

; 禁止 session 自动注入，减少可控写入机会
session.auto_start = Off

注意：关闭 session.upload_progress 的副作用：业务中依赖上传进度条的功能会失效，需要评估业务影响