> ## Content Index
> Fetch the complete content index at: https://www.yooku.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# “PHP2Shell” 超级高危漏洞
- URL: https://www.yooku.com/php2shell-chao-ji-gao-wei-lou-dong/
- Published: 2026-10-23T12:42:29.000Z
- Updated: 2026-10-23T13:56:22.000Z
- Author: Master

| 报告属性        | 内容                                        |
| ----------- | ----------------------------------------- |
| **漏洞名称**    | PHP2Shell (PHP 核心远程代码执行漏洞)                |
| **CVE 编号**  | CVE-2026-109618 / CVE-2026-109619         |
| **GHSA 编号** | GHSA-w8hw-w9fx-j79w / GHSA-6wmf-4rv5-p3rp |
| **CVSS 评分** | **9.2 (Critical / 严重)**                   |
| **影响组件**    | PHP Core (PHP 核心运行库)                      |
| **威胁类型**    | 预身份验证的远程代码执行 (Unauthenticated RCE)        |
| **报告发布日期**  | 2026年10月23日                               |

## 1\. 漏洞概述

2026年10月21日，PHP 官方紧急发布安全更新，修复了存在于 PHP 核心中的两项致命漏洞，统称为 **“PHP2Shell”**。由于 PHP 支撑着全球超过 70% 的 Web 网站（包括 WordPress、Laravel、Drupal 以及大量企业自研系统），且漏洞允许**未经身份验证的攻击者发起远程代码执行（RCE）**，该漏洞被安全界评估为近年危害性最高的底层基础设施漏洞之一。

### 核心威胁特征：

1. **零门槛触发**：无需任何登录凭证或特定应用权限，通过精心构造的 HTTP 请求即可发起攻击。
2. **前置触发**：在 Apache `mod_php` 等架构下，攻击甚至可以在目标业务逻辑代码未开始执行前即被触发。
3. **AI 攻防加持**：研究表明，该漏洞被发现及 PoC 验证过程中，大模型（AI）自动化挖掘与辅助利用起到了关键推动作用，大幅缩短了从漏洞暴露到全网扫描的攻击窗口。

## 2\. 技术机理深入解析

### 2.1 CVE-2026-109618：内存溢出（OOM）处理不当导致的内存腐败

- **机制漏洞**：PHP 使用 `longjmp()` 机制来处理内存溢出（Out-Of-Memory, OOM）致命错误，以此强制中断当前上下文并终止请求。
- **成因分析**：在解析如 `multipart/form-data`（表单提交或文件上传）等请求时，若触发 OOM，PHP 会提前跳出上下文。此时，请求内部数据结构仅处于\*\*“部分初始化”\*\*状态。
- **利用路径**：后续的请求清理（Request Cleanup）流程会将未初始化的内存误认为有效指针并尝试释放。攻击者可通过先前的内存堆布局控制这部分内容，从而造成堆内存腐败，并最终实现任意代码执行（RCE）。

### 2.2 CVE-2026-109619：跨请求全局状态残留（Use-After-Free / UAF）

- **机制漏洞**：PHP 进程在处理请求时会维持部分全局状态（Global State），这些状态临时指向请求专属的内存空间。
- **成因分析**：当发生致命错误（Fatal Error）或异常退出时，部分全局指针未被正确重置或在重置后被错误重新填充，导致全局状态指向已被释放的内存区域（Use-After-Free）。
- **利用路径**：在多路复用进程模型（如 PHP-FPM Worker）中，后续处理新 HTTP 请求的同一个 Worker 会在未完全重新初始化前读取或跳转至这些残留的“脏指针”，攻击者据此可控制执行流。

## 3\. 影响范围与风险评估

### 3.1 受影响的 PHP 版本

- **PHP 8.5** < 8.5.12
- **PHP 8.4** < 8.4.27
- **PHP 8.3** < 8.3.36
- **PHP 8.2** < 8.2.35
- **EOL 停服版本**：所有已停止维护的版本（如 PHP 8.1, 8.0, 7.x, 5.x）均受影响且**无法获得官方直接修复更新**，风险极高。

### 3.2 运行环境风险梯队

| 架构/运行模式                              | 风险等级     | 说明                                                    |
| ------------------------------------ | -------- | ----------------------------------------------------- |
| **Apache mod\_php**                  | **极其严重** | 请求初始化阶段即会执行 Cleanup 逻辑，可在任何业务代码运行前达成 RCE。             |
| **PHP-FPM**                          | **高**    | 虽然 Worker 启动失败会被直接销毁，但在成功启动后的请求处理与全局状态重用中仍可被 exploit。 |
| **FrankenPHP / LiteSpeed / php-cgi** | **高**    | 只要使用受到影响的 PHP 核心解析器，均存在被攻陷风险。                         |

## 4\. 应急处置与修复指南

针对 PHP2Shell 漏洞，运维与安全团队应采取\*\*“先临时防护，后快速升级”\*\*的应急响应策略。

### 4.1 根本解决方案：官方升级

强烈建议各单位立即将生产环境中的 PHP 升级至安全版本：

- 升级至 **PHP 8.5.12** 或以上
- 升级至 **PHP 8.4.27** 或以上
- 升级至 **PHP 8.3.36** 或以上
- 升级至 **PHP 8.2.35** 或以上

> **注**：使用 Linux 发行版（如 Ubuntu、RedHat、Debian）官方源的系统，请及时应用系统官方更新（Backported Patches）。

### 4.2 临时缓解措施（无法立即升级时的紧急替代方案）

若因业务兼容性暂无法立即更新 PHP 版本，可实施以下配置层面的缓解手段：

#### 措施 1：调整 PHP 内存限制配置

在全局 `php.ini` 或 Apache/FPM 配置文件中将 `memory_limit` 设为不限制（降低人为 OOM 触发概率），并限制 POST 提交体积：

```ini
; 移除用户层可触及的内存上限（由系统/容器层控制）
memory_limit = -1

; 降低请求包大小，减少恶意 payload 注入空间
post_max_size = 8M
upload_max_filesize = 7M

; 禁用 session 上传进度跟踪（削减攻击面）
session.upload_progress.enabled = 0

```

#### 措施 2：WAF / 边缘网关拦截规则

在 Nginx、Apache 或 Cloudflare/WAF 等入口网关侧：

1. **限制请求体大小**：将不需要文件上传功能的接口 POST 体积限制在 1MB\~8MB 以内。
2. **拦截异常的 `multipart/form-data`**：拒绝缺乏 `Content-Length` 或字段嵌套层级异常深度的请求。
3. **隔离防护**：在容器/Cgroup 级别设置严格的内存上限与 OOM 处理机制（如内存溢出时直接 Kill 掉 Worker 进程而非交给 PHP 内部机制处理）。

## 5\. 总结与前瞻

“PHP2Shell” 漏洞展现了现代化攻防演进的新特征：**AI 技术缩短了底层高难漏洞的利用周期**。PHP 这一传统基础设施再次提醒我们，必须加强对遗留底层代码（如内存管理、长跳转 `longjmp` 异常逻辑）的审计。企业应将基础组件的快速补丁分发能力纳入核心安全考核指标。

*报告生成时间：2026年10月23日*