> **摘要**: 本文复盘一次 PHP "php2shell" 双漏洞（CVE-2026-109618 / CVE-2026-109619，CVSS v4.0 均为 9.2 Critical）的应急响应全过程。因漏洞细节被第三方提前泄露，PHP 官方将原定周四的安全发布**紧急提前至 2026-10-21 14:00 UTC**——本文从当日凌晨的情报驱动盘点切入，剖析两个漏洞在请求生命周期不同阶段的成因（内存耗尽残留数据被清理例程误用 / Worker 跨请求陈旧状态复用），给出四大分支（8.2/8.3/8.4/8.5）升级路径、WAF 四板斧临时缓解（阻断 `session.upload_progress` 字段、拦截无上传预期的 multipart 请求、请求体大小上限、速率限制）、`session.upload_progress.enabled=Off` 配置加固，以及基于 OOM 日志特征的检测规则与巡检脚本，帮助 PHP 应用团队在补丁泄露与在野利用的赛跑中把响应窗口压缩到小时级。

## 引言：一次被泄露"逼出来"的紧急补丁

> **时间**：2026 年 10 月 21 日（周三）08:30
> **触发源**：PHP 官方紧急安全公告 + 厂商防护通告推送
> **业务影响**：12 台 PHP 生产服务器（8 台 php-fpm + 4 台 mod_php 遗留架构），承载官网、API 网关与内部 CMS
> **紧急程度**：P0（预认证 RCE，CVSS 9.2，细节已泄露）

10 月 21 日早上，安全群被一条通告刷屏：PHP 官方因**漏洞细节被第三方提前泄露**，将原定周四发布的安全更新紧急提前到当天 14:00 UTC（北京时间 22:00）。同日 PHP Foundation 发布博客《Today's PHP Security Release, and How We're Strengthening PHP Security》，确认两个 Critical 级 RCE——**CVE-2026-109618** 与 **CVE-2026-109619**，社区给了它一个直白的名字：**php2shell**。

这组漏洞最危险的三个特征：

1. **预认证**：Apache + mod_php 场景下，一个未认证请求可在**任何应用代码运行之前**触发，官方在**默认配置**下完整演示了 RCE；
2. **php-fpm 同样沦陷**：官方确认 php-fpm 虽路径不同，但经应用级代码路径同样可达成 RCE——"我们用的 fpm 不是 mod_php"不构成豁免；
3. **情报时差被压缩**：细节泄露意味着攻击者比正常披露流程提前拿到了"使用说明书"，补丁窗口从"天"变成"小时"。

本文完整记录从当日盘点、升级、缓解到检测加固的全过程，供 PHP 应用团队对照自查。

## 一、漏洞背景：同一事件的两个阶段

两个漏洞影响 PHP 请求生命周期的**不同阶段**（Datadog Security Labs 的分析口径），组合后构成完整攻击链：

| 项目 | CVE-2026-109618 | CVE-2026-109619 |
|------|------------------|------------------|
| **CVSS v4.0** | 9.2（Critical） | 9.2（Critical） |
| **漏洞类型** | 内存破坏 → RCE（OOM corruption） | 释放后复用（UAF）→ RCE |
| **成因** | 请求恰好在内存分配失败（触及 `memory_limit`）的错误时刻中断，PHP 留下**部分初始化的内部数据**，后续清理例程将其误当作有效数据处理，造成内存破坏 | Worker 进程**跨请求复用陈旧全局状态**：请求处理结束后，全局错误、会话等状态未被完全重置，后续请求可访问已失效内存 |
| **触发阶段** | 请求处理中（内存分配失败瞬间） | 请求之间（状态残留） |
| **GHSA 编号** | GHSA-w8hw-w9fx-j79w | — |
| **触发条件** | Apache + mod_php：未认证请求、默认配置、任何应用代码运行前；php-fpm：经应用级代码路径 | 共享 Worker 状态的常驻进程模型（fpm / mod_php） |

![059-cve-2026-109618-109619-php-php2shell-rce-fix-guide 图 1](https://developer.qcloudimg.com/http-save/yehe-2059497/8ddabd52c4974dee756a371a0b95416c.png)

## 二、影响面盘点：你的 PHP 在不在线

### 2.1 受影响版本矩阵（腾讯云通告口径）

| 分支 | 受影响区间 | 修复版本 |
|------|-----------|---------|
| 5.x / 7.x | 全部低于 8.2.35 | **8.2.35**（或升级至更高分支） |
| 8.2.x | 8.2.0 ≤ v < 8.2.35 | **8.2.35** |
| 8.3.x | 8.3.0 ≤ v < 8.3.36 | **8.3.36** |
| 8.4.x | 8.4.0 ≤ v < 8.4.27 | **8.4.27** |
| 8.5.x | 8.5.0 ≤ v < 8.5.12 | **8.5.12** |

### 2.2 15 分钟资产盘点脚本

```bash
#!/bin/bash
# php2shell-inventory.sh — CVE-2026-109618/109619 资产盘点
# 用法：在 CMDB 主机清单上批量执行，输出受影响主机与运行模式

echo "== 1. PHP 版本 =="
php -v 2>/dev/null | head -1

echo "== 2. 运行模式判定（mod_php = 最高危 / fpm = 高危）=="
if apachectl -M 2>/dev/null | grep -q php; then
    echo "[ALERT] Apache mod_php 模式：预认证、默认配置可直接 RCE"
fi
ps aux | grep -E "php-fpm" | grep -v grep | head -3 \
    && echo "[WARN] php-fpm 运行中：经应用级代码路径可达 RCE"

echo "== 3. 高危配置检查：session.upload_progress =="
php -i 2>/dev/null | grep -i "session.upload_progress.enabled"
# enabled=1 为默认值：WAF 缓解与配置加固的判断依据

echo "== 4. memory_limit（OOM 触发面）=="
php -r "echo ini_get('memory_limit'), PHP_EOL;"
```

![图1：盘点脚本批量执行输出——12 台主机全部受影响，4 台 mod_php 标记 P0、8 台 php-fpm 标记 P1](https://developer.qcloudimg.com/http-save/yehe-2059497/00fb635d5cfea7aa1249ddef27a411e5.png)
*图1：盘点脚本汇总输出（演示数据，主机名与工单号已脱敏）*

盘点结果决定排期优先级：**mod_php 主机 P0 当天处理**，php-fpm 主机 P1 24 小时内完成。

## 三、修复方案：三条路径按风险排序

### 3.1 路径 A（推荐）：升级到修复版本

```bash
# Debian/Ubuntu：确认候选版本包含修复号再升级
apt list --all-versions php8.3-fpm php8.3-cli | grep 8.3.36
apt-get update && apt-get install --only-upgrade php8.3-fpm php8.3-cli php8.3-common

# RHEL/CentOS（Remi 源）
yum update php83-php-fpm php83-php-cli

# 源码编译场景：官方下载对应修复版本
# https://www.php.net/releases/ → 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
```

**升级后三件套**（缺一不可）：

```bash
php -v                          # ① 确认新版本号
php-fpm -m | head -5            # ② 确认扩展加载正常
systemctl reload php8.3-fpm     # ③ reload（非 restart）：Worker 逐个换血，不中断在途请求
```

> **为什么用 reload 而不是 restart**：php-fpm 的 reload 会让旧 Worker 处理完在途请求后退出、新 Worker 接管——对长请求（导出、支付回调）更友好。但注意 **reload 后旧 Worker 的陈旧状态风险才真正清零**，这也是本漏洞"跨请求复用"特性下必须确认 Worker PID 已更新的原因。

### 3.2 路径 B（补丁窗口内的临时缓解）：WAF 四板斧

AWS 在官方补丁发布同步给出了 WAF 缓解组合，四条规则按攻击面从大到小：

| # | 缓解措施 | 针对点 |
|---|---------|--------|
| 1 | **阻断 `session.upload_progress` 字段** | OOM 触发链的关键入口字段 |
| 2 | **拦截"无上传预期的 multipart 请求"** | multipart 解析是内存耗尽的常见触发面；对纯 JSON API 直接封禁 multipart |
| 3 | **请求体大小上限** | 收紧到业务真实上限（如 1MB），压缩"恰好耗尽 memory_limit"的触发空间 |
| 4 | **速率限制** | 拉高攻击者构造触发序列的成本 |

```nginx
# Nginx 层等价缓解（无云 WAF 时的自建版）
server {
    # ① 请求体上限
    client_max_body_size 1m;

    # ② API 路径直接拒绝 multipart
    location /api/ {
        if ($content_type ~* "multipart/form-data") {
            return 415;
        }
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}
```

### 3.3 路径 C（配置加固，与版本无关，长期保留）

```ini
; php.ini —— 关闭 session upload progress 特性
; 该特性默认开启（enabled=1），业务极少真正使用，却是本次 OOM 触发链的入口字段
session.upload_progress.enabled = 0

; 收紧 memory_limit，缩小"恰好错误时刻"的触发面（按业务压测后取值）
memory_limit = 128M
```

### 3.4 架构级建议：淘汰 mod_php

本次 4 台 mod_php 遗留主机之所以被列为 P0，根源在架构：**mod_php 把 PHP 解释器嵌入 Apache 进程**，请求在应用代码之前就进入 PHP 内部状态机（官方确认的"任何应用代码运行前触发"正是指这条路径）。迁移到 `php-fpm + FastCGI` 后：

- PHP 与 Web 服务器进程隔离，Web 层有前置缓冲（超时、body 限制）；
- Worker 模型可控（reload 换血、状态清理策略随版本演进）；
- 版本升级不再绑定 Apache 重启。

这次事件是推动 mod_php 下线的好时机。

## 四、检测：在补丁落地前后盯住两类日志特征

```bash
# 特征 1：OOM 中断（CVE-2026-109618 的前置信号）
grep -E "Allowed memory size of .* exhausted" /var/log/php*error.log \
  | awk '{print $1,$2}' | sort | uniq -c | sort -rn | head

# 特征 2：异常的 multipart POST 高频命中同一 URI（触发尝试）
awk '$6=="\"POST\"" && $9==200 && $7 ~ /\?/' /var/log/nginx/access.log \
  | grep -c "multipart"
```

![图2：php2shell-watch 应急观察面板——OOM 错误在补丁发布后触发 PhpOomSpike 告警，WAF 415 拦截率约 68%](https://developer.qcloudimg.com/http-save/yehe-2059497/3210dd5a274ac13ddb8d6d03b98f3962.png)
*图2：Grafana 应急观察面板（演示数据，时间轴为补丁发布后 12 小时窗口）*

Prometheus 告警规则（php-fpm exporter 场景）：

```yaml
groups:
  - name: php2shell-watch
    rules:
      - alert: PhpOomSpike
        expr: increase(php_oom_errors_total[10m]) > 5
        labels: { severity: warning }
        annotations:
          summary: "PHP OOM 错误 10 分钟内超 5 次——php2shell 触发前置信号，核对版本是否已升级"
      - alert: MultipartBlockedSpike
        expr: increase(nginx_http_415_total[10m]) > 50
        labels: { severity: warning }
        annotations:
          summary: "multipart 拦截命中率异常——疑似扫描/利用尝试，提取来源 IP 排查"
```

## 五、成本核算与响应价值

以本次 12 台服务器（8 fpm + 4 mod_php）的响应为例（数据为防御侧实际口径估算）：

| 项目 | 数值 |
|------|------|
| 盘点（脚本自动化，15 分钟 × 1 人） | 0.25 人时 |
| fpm 升级 + reload（8 台，滚动） | 2 人时 |
| mod_php 迁移评估（4 台，当日先缓解后排期迁移） | 4 人时 |
| WAF/配置缓解 + 检测规则 | 1.5 人时 |
| **响应总投入** | **≈ 7.75 人时（约 1 个工作日）** |
| 参照损失口径 | 预认证 RCE + 细节已泄露场景下，单台沦陷的应急成本（取证、重置、业务回滚）通常以 **10 人时/台** 起步，叠加数据风险 |

响应投入与单次沦陷处置成本的比值约 **15 倍**；若按"泄露后 72 小时黄金窗口"内完成升级计算，本次响应把暴露窗口从"周"级压缩到"小时"级——这是情报驱动响应（订阅官方公告 + 厂商通告双通道）的直接价值。

## 六、复盘与改进

1. **情报双通道缺一不可**：本次最早触达来自厂商防护通告，PHP Foundation 博客提供权威细节，`php.net` 发布页给出修复版本——单一信源容易漏掉"提前发布"这类关键变化。
2. **泄露时代的响应 SLA 要重定义**：正常披露有 90 天缓冲，泄露驱动发布只有 **24 小时**。团队 SLA 应设为：Critical + 预认证 → 24 小时内完成缓解、72 小时内完成升级。
3. **缓解规则先于补丁排期**：WAF 四板斧在升级窗口内就是"临时疫苗"，尤其 mod_php 遗留架构迁移不是一天能完成的事。
4. **mod_php 进入淘汰倒计时**：预认证、应用前触发、进程模型耦合——三条都指向同一结论。
5. **AI 攻防时差在缩短**：从泄露到扫描器落地的时间越来越短，"等周末再升"在 2026 年已经是高风险动作。

---

> **参考资料**：
> - [PHP Foundation: Today's PHP Security Release, and How We're Strengthening PHP Security](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/)
> - [PHP 官方发布页（8.5.12 等修复版本）](https://www.php.net/)
> - [Datadog Security Labs: PHP2Shell — detection, analysis, and remediation](https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/)
> - [AWS Builder Center: A Community Checklist for php2shell on AWS](https://builder.aws.com/content/3L1O3OGdUB5loyuR2tCQKI9E3Yu/find-it-patch-it-watch-it-a-community-checklist-for-php2shell-on-aws)
> - [腾讯云安全通告：PHP "php2shell" 远程代码执行漏洞风险通告](https://cloud.tencent.com/announce/detail/2525)
> - 本专栏相关篇目：[050 WordPress wp2shell RCE](050-cve-2026-63030-60137-wordpress-wp2shell-rce-fix-guide.md)、[058 Tomcat EncryptInterceptor 补丁绕过](058-cve-2026-34486-tomcat-encryptinterceptor-bypass-fix-guide.md)

**创建时间**: 2026-10-23
**系列**: CSDN 安全应急响应专栏 第 059 篇

摘要: 本文复盘一次 PHP "php2shell" 双漏洞（CVE-2026-109618  CVE-2026-109619，CVSS v4.0 均为 9.2 Critical）的应急响应全过程。因漏洞细节被第三方提前泄露，PHP 官方将原定周四的安全发布紧急提前至 2026-10-21 14:00 UTC——本文从当日凌晨的情报驱动盘点切入，剖析两个漏洞在请求生命周期不同阶段的成因（内存耗尽残留数据被清理例程误用  Worker 跨请求陈旧状态复用），给出四大分支（8.2/8.3/8.4/8.5）升级路径、WAF 四板斧临时缓解（阻断 session.upload_progress 字段、拦截无上传预期的 multipart 请求、请求体大小上限、速率限制）、session.upload_progress.enabled=Off 配置加固，以及基于 OOM 日志特征的检测规则与巡检脚本，帮助 PHP 应用团队在补丁泄露与在野利用的赛跑中把响应窗口压缩到小时级。

【Web安全】CVE-2026-109618/109619：PHP "php2shell" 预认证 RCE 双漏洞修复指南

本文复盘一次 PHP "php2shell" 双漏洞的应急响应全过程。因漏洞细节被第三方提前泄露，PHP 官方将原定周四的安全发布紧急提前至 2026-10-21 14:00 UTC——本文从当日凌晨的情报驱动盘点切入，剖析两个漏洞在请求生命周期不同阶段的成因，给出四大分支（8.2/8.3/8.4/8.5）升级路径、WAF 四板斧临时缓解

安全

PHP官方因CVE-2026-109618/109619双漏洞细节泄露，紧急提前发布安全补丁。本文复盘php2shell应急响应全过程，覆盖影响面盘点、四大分支升级路径、WAF四板斧临时缓解方案及配置加固，提供基于OOM日志特征的检测规则，帮助团队在补丁泄露与在野利用的赛跑中，将响应窗口压缩至小时级。

数据处理

代码解释

服务器

云安全

解释器

Ubuntu

Debian

CentOS

Nginx

让每一个 Agent，都跑在云上

cngw

tcmg

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【Web安全】CVE-2026-109618/109619：PHP "php2shell" 预认证 RCE 双漏洞修复指南-腾讯云开发者社区-腾讯云

【Web安全】CVE-2026-109618/109619：PHP "php2shell" 预认证 RCE 双漏洞修复指南

【Web安全】CVE-2026-109618/109619：PHP "php2shell" 预认证 RCE 双漏洞修复指南

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐