一、事件概述

PHP 是全球部署最广泛的服务器端脚本语言之一，几乎支撑着半个互联网。2026年10月，PHP官方披露并修复了两项严重级别的远程代码执行（RCE）漏洞：

• CVE-2026-109618（GHSA-w8hw-w9fx-j79w）

• CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）

两项漏洞的 CVSS 4.0 评分均为 9.2，属于“严重”等级，业内也被媒体统称为 PHP2Shell。攻击者无需任何身份认证，仅通过构造特定的 HTTP 请求即可触发内存破坏，最终以 Web 服务进程权限执行任意代码，后果包括网页篡改、敏感数据窃取、植入后门乃至服务器完全失陷。

时间线：

• 2026年10月20日：PHP 官方预告将发布安全更新；

• 2026年10月21日13:30（UTC）：PHP 官方正式发布修复版本 —— 8.5.12、8.4.27、8.3.36、8.2.35；

• 随后：CNVD（CNVD-2026-41674、CNVD-2026-41675）、国家互联网应急中心、欧盟 CERT-EU、英国 NCSC 及国内多家网络安全主管单位相继发布预警通报；

• 目前：漏洞技术细节已公开并有概念验证（PoC）代码流传，暂未发现大规模在野利用，但按历史规律，从公开到被批量利用通常只有数天窗口。

在 PHP 官方发布修复版本后仅数小时，我公司即在第一时间完成漏洞复现、攻击路径验证，并形成了覆盖各个版本、各种部署形态的解决方案。 截至本文发布，已先后为多家政企单位、企业客户及个人用户提供漏洞排查、升级加固与应急处置服务。

二、漏洞技术详情

2.1 CVE-2026-109618：内存耗尽（OOM）处理导致的内存损坏

PHP 用 memory_limit 限制单个请求可用内存，超限时会通过 longjmp() 强制中断请求并抛出 OOM 错误。问题在于：这种中断可能发生在请求内部数据尚未完成初始化的时候（典型场景是解析 multipart/form-data 文件上传的过程中）。

请求后续的清理流程会把这些“半成品”数据当作正常数据去处理，并释放一块从未被初始化的内存。而这块内存中，可能仍残留着攻击者此前请求所留下的数据。攻击者通过精心构造请求，即可借此控制程序执行流程，实现远程代码执行。

关键事实：

• PHP 官方已在 Apache + mod_php 的默认输入与内存限制下，通过 HTTP 完成了完整的未认证 RCE 验证；

• 触发发生在业务代码执行之前，也就是说，即便使用了可靠的第三方框架、自身代码毫无问题，也无法天然免疫；

• 单个未认证请求即可完成攻击。

2.2 CVE-2026-109619：跨请求的“陈旧全局状态”释放后使用

Web 工作在多请求复用模式下，某些属于请求的全局内部状态，在其底层内存被释放之后仍然保留着指针（例如一次致命错误 fatal error 之后）。同一个工作进程处理的下一个请求，可能在正常初始化重置之前就访问了这份陈旧状态，造成堆内存“释放后使用”（Use After Free），进而导致内存泄露与远程代码执行。

关键事实：

• PHP 官方确认该路径在 mod_php 与 PHP-FPM 下均可实现 RCE；

• 会话上传进度功能（session.upload_progress）默认开启，触发相关处理不要求业务主动调用 session_start() —— 也就是说，大量系统默认就处于可被攻击的状态；

• 防护重点在于“不要唯业务层防守”，必须从服务器配置层下手。

三、影响范围

3.1 受影响的 PHP 版本

特别注意：PHP 官方考虑到本次漏洞的严重性，已额外发布了面向 PHP 7.4、8.0、8.1 的最小化源码级补丁（backport），仅适用于自行编译且没有 LTS 供应商的用户。这是非常罕见的安排，反过来说也说明这次漏洞的严重程度。

3.2 受影响的运行形态（SAPI）

只要以如下任一方式对外提供 Web 服务，都需要排查：

• PHP-FPM

• Apache mod_php（官方认定为风险最高的组合）

• php-cgi

• FrankenPHP

• LiteSpeed / LSAPI

3.3 受波及的上层业务系统

CMS、框架与应用平台本身未必有漏洞，但底层依赖 PHP 运行时，同样存在风险：

WordPress、Drupal、Joomla、Magento、MediaWiki、Roundcube、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS、OpenCart 等。此外，一大批内置 PHP 的商业软件、网络设备 Web 管理端、一体机也需要一并盘点排查。

四、自查方法（建议今天就做）

4.1 确认实际运行的 PHP 版本

CLI 与 Web 服务器可能运行不同版本，两边都要查：

php -v                    # 命令行版本
php-fpm -v                # Web 侧版本（也可能是 php-fpm8.3 -v 等）
php -r 'echo PHP_VERSION;'  # 只看版本号

此外建议在临时探针中使用 phpinfo() 输出页面，确认 Web 侧实际加载的版本、SAPI 类型与生效的 php.ini 路径，用完务必删除该探针文件。

如果是 PHP-FPM，还应确认 FPM 池加载了哪个版本的二进制，以及 www.conf 生效的配置路径。

4.2 与上面的版本表对照

只要落在“受影响版本”区间内，就应当按第五节的处理路径进行处置。不要因为“我们在内网”或“我们访问量很小”而豁免 —— 这类漏洞不需要认证，也有很多真实场景是被横向渗透攻入内部的。

4.3 资产盘点建议

建议同时盘点：对外业务的 Web 中间件清单、容器镜像内的 PHP 版本、各类一体机/网络设备 Web 管理端、 CI/CD 流水线上的 PHP 环境，避免只盯着几台应用服务器。

五、我公司的解决方案

针对本次漏洞，我公司已完成漏洞原理分析、复现验证与修复路径确认，面向各个版本、各种部署形态均已具备可直接执行的解决方案：

5.1 在线贴合维护窗口的标准化升级

• 使用发行版包管理（yum / dnf / apt）安装的场景：核对发行版与 LTS 供应商的安全公告，使用已回补加固的安装包；部分发行版在官方发布前已同步收到补丁，需确认实际 changelog 中已包含本次修复；

• 源码编译安装的场景：升级至 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 对应源码包，保留原有编译参数重新整理二进制并平滑切换，避免升级后扩展缺失导致业务中断；

• 容器化部署的场景：更新基础镜像版本，重新推送镜像并滚动发布，同步核查 Dockerfile 中是否锁定旧版本 tag。

5.2 老旧版本（PHP 8.1 及更早）的处置路径

这一部分是本次事件中最容易被忽略、也最容易“搁置”的地方。我们提供三条可选路径：

1. 迁移升级至受支持的版本（推荐）：对老旧版本 Branch 做兼容性评估，梳理废弃函数与扩展依赖，制定分阶段迁移方案；

2. 供应商回补补丁：联系发行版或 LTS 供应商，确认是否提供本次漏洞的 backport 包；

3. 官方最小化源码补丁：PHP 官方已为 7.4 / 8.0 / 8.1 发布了源码级 backport，适用于自行编译、且无法通过前两种方式修复的场景，我们可协助完成补丁梳理与验证。

5.3 临时无法停机的缓解加固

对确实无法立即升级的核心业务系统，可按第六节配置逐层收敛攻击面，并配合我们提供的核查清单逐 pool、逐目录确认是否生效。

5.4 应急处置与失陷排查

对已暴露于公网、且运行受影响版本的系统，我们建议同步开展入侵排查：审查 Web 日志中的异常 multipart/form-data 请求、核查新增文件与可疑计划任务、检查 Web 进程异常外连、清理可能残留的后门。

截至到目前为止，我们已先后为多家政企单位、企业客户以及个人用户完成本次漏洞的排查与处置，涵盖 yum/dnf/apt 包管理部署、源码编译部署与容器镜像部署等不同形态。 如果您的环境尚未完成升级，欢迎通过本文末尾的联系方式与我们联系。

六、修复建议（官方正式修复优先）

再次强调：只有升级到官方修复版本才是彻底解决，以下缓解手段只是临时过渡措施，不能作为终态。

6.1 正式修复步骤

1. 升级至对应分支的修复版本：8.2.35 / 8.3.36 / 8.4.27 / 8.5.12；

2. 重启全部 PHP 工作进程及相关服务（FPM、Apache / Nginx、opcache 相关进程），仅升级二进制不重启无效；

3. 核对实际 Web SAPI 的版本与生效配置，不要只看 php -v 的命令行结果；

4. 使用发行版回补包的，以供应商安全公告为准确认修复状态。

6.2 针对 CVE-2026-109618 的临时缓解

; FPM 池 / Apache 管理员级配置（业务不可覆盖）
php_admin_value[memory_limit] = -1
post_max_size = 8M        ; 不需要文件上传的业务
; post_max_size = 32M     ; 需要文件上传的业务
upload_max_filesize = 8M  ; 需小于 post_max_size

• memory_limit=-1 必须写在管理员级配置中（php_admin_value、php.ini 或 Apache 配置），并确认没有 pool、目录或应用配置把有限值重新恢复；

• 同时在 Web 服务器或反向代理层，对解码后的请求体大小、输入变量数量、multipart 分段数量、请求头数量与嵌套深度做限制；该限制须覆盖“没有可用 Content-Length 的请求”；

• 不需要 multipart 的业务，可直接拒绝此类请求；

• 如需资源边界，请用容器 / cgroup 的内存限制做“可用性兜底”，切勿用 RLIMIT_AS 或 RLIMIT_DATA 代替 PHP 内存上限 —— 后者反而可能触发漏洞所需的分配失败路径。

6.3 针对 CVE-2026-109619 的临时缓解

; 必须写在请求解析前生效的位置
session.upload_progress.enabled = 0
; PHP 8.5 环境额外设置
fatal_error_backtraces = 0

• 配置必须落在 php.ini、FPM 池配置或服务器启动配置中，不能依赖脚本内的 ini_set() 或 .user.ini，也必须在修改后重启全部工作进程；

• 同时建议修正那些攻击者能够触达的致命错误与执行超时逻辑（回调、上传处理、导入处理、清理流程等）；

• 单纯用 error_reporting、display_errors 或 @ 屏蔽诊断信息并无帮助。

七、后续跟踪提示

2026年10月23日，PHP 官方又披露了一个远程代码执行漏洞 CVE-2026-115560。该漏洞仅影响采用非常规配置的 Web 应用，PHP 官方判定风险较低，因此不会额外发布紧急版本，将在下一个常规版本中修复，并建议各单位在升级前保持缓解措施。

建议在下一个常规版本发布前，继续维持 session.upload_progress.enabled = 0 的设置，以获得对该风险点的完整防护。

建议关注渠道：

• PHP 官方发布与下载：https://www.php.net/downloads.php

• PHP 官方历史公告：https://www.php.net/archive/2026.php

• 官方安全通告（GitHub Advisory）：GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp

• 第三方受影响软件清单（NCSC-NL）：https://github.com/NCSC-NL/php2shell

八、服务声明与联系方式

量子计算（山西）软件有限责任公司在本次漏洞响应中，第一时间完成了漏洞复现、攻击路径验证与解决方案输出。目前，针对各个受影响版本、各种部署形态的处置方案均已具备可交付能力，并已持续为多家政企单位、企业客户及个人用户提供漏洞排查、版本升级、加固配置与失陷排查服务。

如您需要对现有环境进行安全性核查与升级加固，欢迎与我们联系：

• 公司全称：量子计算（山西）软件有限责任公司

• 唯一联系电话：0351-5255612

• 唯一官方邮箱后缀：@sxslz.com

• 官方网站：https://www.sxslz.com

安全提示：本文所列的修复版本、配置参数与处置建议均来源于 PHP 官方及权威安全机构的公开通报。实际处置时请结合自身业务窗口与变更流程，先在灰度环境验证再推广至生产环境。