PHP2Shell 代码执行漏洞影响面测绘分析与处置建议（CVE-2026-109618/CVE-2026-109619）
华顺信安威胁情报中心
2026年10月21日 16:20
湖南
去阅读
*▌事件背景*
2026 年 10 月 20 日，公开渠道出现匿名披露帖，称 PHP 存在两处远程代码执行漏洞，原定于 10 月 22 日协调披露。该帖随后被删除，但相关内容已在社交平台扩散。
同日，安全研究机构对外确认漏洞真实存在，编号为 CVE-2026-109618、CVE-2026-109619，并表示已完成其中 CVE-2026-109618 的复现。
随后 PHP 官方发布安全更新预告，明确修复版本发布时间为 2026 年 10 月 21 日 14:00 UTC（北京时间 22:00），两处漏洞官方评级均为 CVSS v4.0 9.2。公告中另有一句不常见的表述：若漏洞细节被公开、或出现野外利用证据，官方保留提前发布的权利。
**▌漏洞基本信息****
| 项目 | 内容 |
|---|---|
| 漏洞编号 | CVE-2026-109618、CVE-2026-109619 |
| 漏洞类型 | 远程代码执行（RCE） |
| 危险等级 | 严重 |
| CVSS v4.0 | 9.2（两处均为 9.2，PHP 官方评级） |
| 受影响组件 | PHP 解释器内核（非扩展、非框架层） |
| 认证要求 | 无需认证（依据评分级别判断） |
| 受影响版本 | 官方未公布，详见第五节 |
| 修复版本 | 官方未公布，随 10 月 21 日 22:00 版本发布 |
| 在野利用 | 暂无公开证据，未列入 CISA KEV 目录 |
| 官方缓解措施 | 补丁发布前无 |
**▌影响面评估****
-
波及范围为何较大
漏洞位于解释器内核，与运行方式无关。 据现有信息，Apache mod\_php 与 PHP-FPM 两种主流部署方式均在被指受影响范围内。这意味着风险不局限于某一扩展或某一框架，以「已启用 FPM、未使用 mod\_php」为由排除自身风险并不成立。
利用无需认证。 9.2 的评级对应未授权远程代码执行，攻击者不需要账号、后台入口或任何前置条件。
下游应用密度高。 PHP 承载了全球多数内容管理系统、电商平台、建站面板与共享主机服务。据 W3Techs 口径统计，PHP 在已知服务端编程语言中的占比长期维持在七成以上。核心层漏洞一旦出现可用利用代码，受影响对象将是长尾站点整体，而非少数目标。
2. 目前公开流传的利用演示视频涉及的主流框架及资产暴露情况
据当前流传的利用演示，以下 9 款 PHP 应用与开发框架出现在受影响范围内。演示内容的真实性尚未获得官方确认，此处仅作为资产排查的范围参考。
| 框架 / 应用 | FOFA 检索语法 | 全球资产 | 国内资产 |
|---|---|---|---|
| WordPress | app=\"WordPress\" |
7,226 万 | 88.7 万 |
| Drupal | app=\"Drupal\" |
169.7 万 | 6.08 万 |
| Joomla | app=\"Joomla\" |
100.0 万 | 1.27 万 |
| Laravel | app=\"Laravel\" |
40.6 万 | 6.57 万 |
| MediaWiki | app=\"MediaWiki\" |
14.3 万 | 1,849 |
| Magento | app=\"Magento\" |
7.9 万 | 906 |
| phpBB | app=\"phpBB\" |
5.00 万 | 751 |
| Symfony | app=\"Symfony\" |
1.10 万 | 162 |
| WHMCS | app=\"WHMCS\" |
1,193 | 15 |
图 1 检索 app=\"WordPress\"，返回 72,260,260 条匹配记录（3,103,937 条独立 IP），为演示涉及应用中体量最大者
另有国内使用量较大的两款 PHP 应用，虽未出现在当前演示列表中，但同属 PHP 应用范畴，是否存在同类风险需待官方公告确认，建议一并纳入排查：
| 框架 / 应用 | FOFA 检索语法 | 全球资产 | 国内资产 |
|---|---|---|---|
| ThinkPHP | app=\"ThinkPHP\" |
57.3 万 | 44.4 万 |
| Discuz | app=\"Discuz\" |
24.1 万 | 17.9 万 |
图 5 检索 app=\"ThinkPHP\" && country=\"CN\"，国内返回 443,587 条匹配记录（49,252 条独立 IP）
需要提示的是，框架层面的暴露量与框架自身是否直接暴露漏洞无关——漏洞位于 PHP 内核，只要底层 PHP 版本在受影响范围内，运行其上的任意 PHP 应用均处于同一风险面。上表的作用是帮助确定排查优先级，而非划定安全边界。
▌影响版本
公开泄露信息称 PHP 5 及之后版本均可能受影响，该范围尚未获得官方确认），将在修复版本发布时一并公布。结合现有公开信息，当前可确认与待确认的内容如下：
| PHP 分支 | 维护状态 | 是否可获得官方修复 |
|---|---|---|
| 8.5 | 现行维护 | 预计提供 |
| 8.4 | 现行维护 | 预计提供 |
| 8.3 | 现行维护 | 预计提供 |
| 8.2 | 仅安全修复，2026 年 12 月结束支持 | 预计提供 |
| 8.1 及更早 | 已终止维护 | 不提供 |
| 7.x | 已终止维护 | 不提供 |
| 5.x | 已终止维护 | 不提供 |
三点说明：
其一，安全研究团队对外表述为影响 PHP 5、6、7、8 各版本，此为第三方判断，官方公告未予确认。
其二，另有安全研究员公开判断是仅 PHP 8 分支会获得补丁，这与 PHP 5、7 早已终止维护的现状一致。
其三，流传演示环境为 Ubuntu 26.04 + PHP 8.5.4，该版本信息未经官方证实。
综合来看，可获得官方修复的分支为 8.2 至 8.5。其余分支不存在「等待补丁」这一选项，风险将长期存在，唯一可行路径是升级至受支持分支。
**▌补丁发布前的处置建议****
距修复版本发布尚有一段时间，以下工作建议在今晚 22:00 前完成，以保证补丁释出后可立即进入实施阶段。
1. 完成 PHP 资产清点。 清点范围不应局限于 Web 站点。CLI 脚本、定时任务、常驻队列进程、后台管理面板往往运行着不同版本的 PHP，需逐一登记版本号与部署位置。
2. 确认每台实例的安装来源。 区分系统发行版源、主机面板集成、第三方软件源、容器镜像与自行编译五种来源。来源决定了补丁的获取路径与回滚方式，需在补丁发布前明确。
3. 核对面板环境。 使用宝塔、Plesk 等主机面板的环境，系统级 PHP 与面板托管的 PHP 属于两套独立安装，须逐一核对站点绑定的 PHP handler，避免仅升级其中之一。
4. 梳理 EOL 分支资产并排定迁移计划。 仍在运行 PHP 8.1 及更早版本、尤其 7.4 与 5.6 的业务，本次不会获得官方修复。需在补丁发布前明确两项决定：是否排期升级至受支持分支，以及升级完成前的风险隔离方式。
5. 收敛暴露面。 CERT-EU 的建议同样适用于此阶段：对短期内无法完成修补的对外应用，考虑先从公网撤除，或通过访问控制限制来源。
6. 开启并留存日志。 重点采集 Web 访问日志与 PHP-FPM 运行日志，关注由 Web 服务用户发起的异常子进程创建、异常命令执行与可疑请求特征。
7. 完成变更准备。 提前完成变更审批、备份与回滚预案，明确值守人员与通知链路，确保 22:00 修复版本释出后可立即执行升级，而非次日再走流程。
**▌修复指南****
- 确认受影响范围
修复版本发布后，首先以官方公告公布的受影响版本范围与触发条件为准，核对自身资产是否存在可被利用的路径。在确认之前不建议直接对全网实例执行升级。
2. ### 获取修复版本
仅从官方渠道获取：php.net 下载页、各 Linux 发行版安全源、容器镜像的官方仓库。参考 9 月 24 日发布的 8.5.11、8.4.26、8.3.35、8.2.34，本次修复版本预计落在 8.2 至 8.5 四条分支，具体版本号以公告为准。
3. ### 执行升级
按「先测试、再灰度、后全量」的顺序推进。升级前确认已具备回滚条件，包括旧版本安装包、配置文件与数据备份。
4. ### 重启相关进程
这一步最容易被跳过，也是最容易导致「已修复」判断失真的环节。二进制包更新后，内存中运行的仍是旧版本代码：
a.Apache mod\_php 方式：重启 Apache 服务。
b.PHP-FPM 方式：重启对应的 FPM 进程池。
c.常驻 CLI 进程（队列 Worker、守护脚本）：逐一重启。
不可仅凭 php -v 的输出判断修复已完成，该命令反映的是命令行二进制的版本，与正在提供服务的进程无关。
5. ### 更新容器镜像
容器环境仅重启容器无法完成修复，必须重新构建包含新版本 PHP 的镜像，并执行全量滚动更新，确认所有副本均已切换至新镜像后，再回收旧副本。
6. ### 修复后核验
核验内容包括三项：实际运行进程所加载的 PHP 版本、业务功能回归结果、以及修复前登记的资产清单是否全部覆盖。存在遗漏实例时，应作为遗留风险单独登记。
7. ### 无法升级分支的补偿措施
对 PHP 8.1 及更早、不会获得官方修复的实例，若确实无法在短期内完成升级，可采取以下措施降低风险。需要明确的是，这些措施只能降低被利用的可能性，不能消除漏洞：
a.将实例从公网撤除，或通过 VPN、零信任网关限制访问来源。
b.在 WAF 侧启用虚拟补丁与异常请求拦截规则。
c.以最小权限用户运行 Web 服务，限制可写入目录范围。
d.关闭非必要的扩展与模块，减少暴露面。
8. ### 关于常见无效措施
disable_functions、open_basedir 属于 PHP 脚本层安全限制。本次漏洞位于解释器原生代码层，在进入函数调用之前执行流即被劫持，此类配置无法形成有效防护。
封禁 SSH 端口与攻击链路无关，漏洞入口为 80/443 等 Web 端口。
常规 WAF 规则对新漏洞缺乏覆盖，仅可作为辅助手段，不宜作为核心防护依赖。
**▌参考****
- https://www.php.net/archive/2026.php
- https://cert.europa.eu/publications/security-advisories/2026-018/
- https://x.com/watchtowrcyber
- https://www.bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow/
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论