CVE-2026-109618、CVE-2026-109619（PHP2Shell）漏洞FAQ
时间：2026年10月23日
1. 声明
本文基于安天 CERT 工程师构建的 FAQ 清单整理而成，结合多个智能体协同分析并进行人工修订。文中涉及的 CVE 编号、版本号、评分等技术细节，部分来源于公开资料与社区信息，尚未全部经权威数据库（如 cve.org、NVD）交叉验证，可能存在事实偏差或时效性误差。技术验证无法短期完成，建议读者交叉验证关键信息。如发现错误或质疑，欢迎反馈，我们验证后会对网站版 FAQ 继续修订。
2. 前言
PHP2Shell 是 PHP 内核中一组高危内存安全漏洞的社区指代，由 CVE-2026-109618、CVE-2026-109619 两个编号组成。该漏洞无需业务代码存在缺陷，攻击者可通过构造特殊 HTTP 上传请求，在满足条件的 PHP-FPM 环境下触发内存缺陷，实现内存信息泄露、进程崩溃，极端场景下可完成远程代码执行。
本文以问答形式整理该漏洞的相关疑问，供资产排查、应急处置、威胁研判参考。全文共六个章节，覆盖漏洞基础、资产识别、攻击原理、防护边界、自查应急、威胁态势六个维度，合计四十个问题。
一、漏洞基础概况
Q1：PHP2Shell 漏洞是什么，两个 CVE 编号分别对应什么缺陷？
A：PHP2Shell 指代 PHP 内核 multipart 表单解析模块存在的两个内存安全漏洞。CVE-2026-109618 为内存耗尽（OOM）漏洞，畸形请求可直接造成 PHP 进程崩溃；CVE-2026-109619 是跨请求内存释放后重用漏洞，攻击者可利用该缺陷实现内存泄露，在满足条件时完成远程代码执行。
代号 PHP2Shell 的由来，是因为攻击者可依托 PHP 运行时内存缺陷，在不落地网页后门文件的前提下获取代码执行能力。这与传统“上传恶意脚本到服务器”的攻击模式有本质区别。
两个漏洞的技术特征对比如下：
表 1-1 两个 CVE 编号的技术特征对比
| 对比维度 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| 缺陷类型 | 内存耗尽（OOM） | 释放后使用（UAF） |
| 直接后果 | PHP 进程崩溃、服务中断 | 内存信息泄露、潜在远程代码执行 |
| 利用稳定性 | 高，请求即可触发 | 依赖内存布局与请求时序 |
| 攻击效果 | 拒绝服务（DoS） | 信息泄露 → 远程代码执行 |
| 修复优先级 | 中（影响可用性） | 高（影响机密性、完整性） |
说明：不同公开资料对两个 CVE 的具体缺陷类型描述存在差异。部分资料将两个编号均描述为释放后使用漏洞，也有资料按内存耗尽与释放后使用区分。本文按当前资料整理，实际映射关系需以 PHP 官方安全公告或 MITRE CVE 记录为准。
Q2：该漏洞的风险等级如何，属于远程漏洞还是本地漏洞？
A：综合判定为高危漏洞。属于远程漏洞，攻击者仅需网络可达目标站点，发送特制 HTTP 请求即可尝试触发，不需要预先获取业务账号、登录凭证。
远程漏洞与本地漏洞的核心区别在于攻击入口：
表 2-1 远程漏洞与本地漏洞的区分
| 漏洞类型 | 攻击前提 | 暴露面 | 本例归属 |
|---|---|---|---|
| 远程漏洞 | 网络可达目标服务 | 所有对外开放的 Web 端口 | PHP2Shell |
| 本地漏洞 | 已获得目标系统命令行权限 | 仅本地用户或已入侵者 | 不适用 |
由于 PHP 作为服务端脚本语言，其解析流程天然暴露在网络请求处理路径上，因此内核级缺陷通常直接构成远程攻击面。
Q3：漏洞披露的关键时间节点是怎样的？
A：安全研究者向 PHP 安全团队提交漏洞报告，厂商完成分析、开发补丁；补丁发布后漏洞信息公开，随后出现概念验证代码，互联网逐步出现批量探测与在野利用行为。
典型的安全漏洞披露时间线如下：
图 3-1 PHP2Shell 漏洞披露时间线
详细时间线可查阅 PHP 官方安全公告与 oss-sec 邮件列表。PHP 官方已于 2026 年 10 月 21 日 22:00（北京时间）推送安全补丁，具体时间与补丁信息以官方公告为准。
Q4：为什么网站业务代码没有漏洞，依然会受到 PHP2Shell 影响？
A：漏洞根源在 PHP 运行时内核，并非网站业务代码。即使业务代码不存在 SQL 注入、跨站脚本攻击、文件上传等 Web 漏洞，只要服务器使用受影响版本 PHP，且满足触发条件，攻击者就可以利用 PHP 底层内存管理缺陷发起攻击。
图 4-1 Web 应用安全边界与 PHP2Shell 漏洞位置示意
业务代码的漏洞需要攻击者与业务逻辑交互（如提交表单、调用接口），而内核漏洞在请求进入 PHP 处理流程时即被触发，早于任何业务脚本执行。
Q5：PHP2Shell 和传统网站上传漏洞有什么本质差别？
A：传统上传漏洞是业务校验逻辑缺陷，允许恶意文件写入磁盘后执行；PHP2Shell 是 PHP 内核解析 multipart 表单时的内存破坏问题，不需要向磁盘写入恶意网页后门文件，属于运行时内存层面的无文件攻击。
两者对比如下：
表 5-1 传统上传漏洞与 PHP2Shell 的本质差别
| 对比维度 | 传统上传漏洞 | PHP2Shell |
|---|---|---|
| 漏洞位置 | 业务代码（如上传后缀校验不严） | PHP 内核 multipart 解析模块 |
| 攻击载体 | 恶意文件（.php、.phtml 等） | 特制 HTTP 请求体 |
| 落地文件 | 需要写入 Web 目录 | 不需要，内存中直接执行 |
| 检测难度 | 相对容易（文件监控、防火墙、杀毒软件） | 困难（无文件、内存层面） |
| 修复方式 | 修复业务代码 | 升级 PHP 版本 |
| 影响范围 | 单个业务系统 | 所有使用受影响 PHP 的服务 |
Q6：漏洞触发发生在请求处理的哪个阶段？
A：漏洞触发发生在 PHP 内核解析 HTTP 请求体阶段，早于网站 PHP 业务脚本执行。脚本代码还未运行，内存缺陷就已经被触发。
图 6-1 PHP-FPM 请求处理流程与漏洞触发位置
由图 6-1 可见，漏洞触发点位于业务脚本执行之前，这解释了为什么业务代码无缺陷也会被攻击。
二、受影响资产与环境识别
Q7：哪些 PHP 版本存在漏洞，哪些版本已经修复？
A：PHP 8.1、8.2、8.3、8.4 部分子版本受影响，各分支需要升级至 PHP 官方发布的安全版本。PHP 8.1 及更早版本已经停止维护（EOL），官方不会提供安全补丁。
据资料整理的各分支修复版本阈值如下（具体版本号待官方公告验证）：
表 7-1 各 PHP 分支受影响与修复版本对照
| PHP 分支 | 受影响版本 | 修复版本 | 维护状态 |
|---|---|---|---|
| PHP 8.1.x | 全部子版本 | 无（已 EOL） | 已停止维护 |
| PHP 8.2.x | < 8.2.35 | >= 8.2.35 | 活跃支持 |
| PHP 8.3.x | < 8.3.36 | >= 8.3.36 | 活跃支持 |
| PHP 8.4.x | < 8.4.27 | >= 8.4.27 | 活跃支持 |
| PHP 8.5.x | < 8.5.12 | >= 8.5.12 | 活跃支持 |
注意：上表版本号来源于技术资料，未经 PHP 官方更新日志逐条核对。实际升级前，请通过版本查询命令确认当前版本，并访问 PHP 官方下载页或安全公告确认精确的修复版本号。
Q8：不同 SAPI 模式下，风险程度是否一样？
A：不一样。Apache + mod_php 是当前风险评估中的最高风险配置，因为已演示的利用链可在请求启动阶段、任何应用代码执行前，通过单个未认证请求触发。PHP-FPM 同样受到影响，但其利用条件与 mod_php 不同：针对 CVE-2026-109618，上游公告未报告完整的 PHP-FPM 利用链；针对 CVE-2026-109619，FPM 路径需要依赖应用层内的特定操作。CGI/FastCGI 模式存在一定风险，CLI 模式风险相对较低。
表 8-1 不同 SAPI 模式的风险对比
| SAPI 模式 | 进程模型 | 跨请求状态残留 | 风险等级 | 说明 |
|---|---|---|---|---|
| mod_php | 嵌入 Apache 进程，随请求或进程回收 | 高 | 高 | 取决于 Apache 的多处理模块（MPM）模式与进程回收策略 |
| PHP-FPM | 独立工作进程池，进程常驻 | 中高 | 中高 | 攻击者可利用长连接命中同一工作进程，实现跨请求内存复用 |
| CGI / FastCGI | 每请求或进程池模式 | 低至中 | 中 | IIS+FastCGI 等场景仍可能被利用 |
| CLI | 单次执行，进程退出 | 无 | 低 | 难以构造跨请求利用链 |
PHP-FPM 之所以成为主要目标，是因为其工作进程在处理大量请求后仍保持存活，为跨请求内存状态复用提供了条件。
Q9：Nginx+PHP-FPM、Apache+mod_php、IIS+FastCGI，哪些架构会受影响？
A：Nginx+PHP-FPM 是风险最高的组合；Apache+mod_php、IIS+FastCGI 只要 PHP 版本落在受影响区间，同样存在被利用风险。
图 9-1 常见 Web 架构风险排序
架构本身不决定是否受影响，底层 PHP 版本才是核心因素。但只要版本命中，架构差异会影响利用的稳定性与成功率。
Q10：宝塔、LNMP 一键包、云服务商预装 PHP 环境是否会受漏洞影响？
A：是否受影响只看底层 PHP 版本，和集成环境无关。只要内置 PHP 版本为受影响版本，无论宝塔、LNMP 还是云厂商预装环境，均存在风险。
集成环境只是安装与配置的封装，不改变 PHP 内核代码。排查时可直接执行版本查询命令：
# 查询 PHP 版本
php -v
# 查询 PHP-FPM 版本
php-fpm -v
# 查询上传进度配置
php -i | grep upload_progress
Q11：虚拟主机、独立服务器、容器、Serverless 环境，哪类资产风险最高？
A：共享虚拟主机风险最高，多租户场景下单台服务器承载大量站点，极易被批量扫描；其次是独立服务器与 PHP-FPM 容器；无服务器计算（Serverless）PHP 函数环境风险相对更低。
表 11-1 不同资产类型的风险对比
| 资产类型 | 多租户隔离 | 批量暴露面 | 风险等级 | 主要原因 |
|---|---|---|---|---|
| 共享虚拟主机 | 弱（同机多站） | 极大 | 最高 | 单次扫描可命中大量站点，黑产收益高 |
| 独立服务器 | 强 | 中 | 高 | 通常直接暴露公网，维护水平参差不齐 |
| PHP-FPM 容器 | 中 | 中 | 中至高 | 容器常伴随持续集成与持续部署（CI/CD）快速迭代，版本滞后常见 |
| Serverless PHP | 强 | 低 | 较低 | 函数生命周期短，跨请求状态残留窗口小 |
Q12：升级网站 CMS 程序（WordPress、Drupal 等）能不能修复 PHP2Shell？
A：不能。内容管理系统（CMS）属于上层业务应用，漏洞是 PHP 底层运行时缺陷，仅升级业务代码无法修复，必须升级 PHP 本身。
可以做一个类比：如果地基（PHP 内核）出现裂缝，无论地面建筑（CMS）装修得多好，都无法阻止地基塌陷。修复路径必须是：
错误做法：升级 WordPress、Drupal 或自定义业务代码。
正确做法：升级 PHP 版本至官方安全版本，或关闭上传进度统计功能作为临时缓解。
三、攻击原理与利用条件
Q13：成功利用 PHP2Shell，需要满足哪些必要条件？
A：核心条件包括四项：一是使用受影响版本 PHP；二是使用 PHP-FPM 等高风险服务器 API；三是服务可接收 multipart/form-data 类型 POST 请求；四是上传进度统计机制可用。缺少任意一项，攻击链很难完成。
表 13-1 成功利用的必要条件
| 序号 | 必要条件 | 说明 | 可否临时关闭 |
|---|---|---|---|
| 1 | 受影响版本 PHP | 版本落在官方公布的受影响区间 | 不可，需升级 |
| 2 | 高风险 SAPI | PHP-FPM 最佳，mod_php 次之 | 部分可调整 |
| 3 | 可接收 multipart/form-data | 目标接口接受文件上传或表单提交 | 可通过网关限制 |
| 4 | session.upload_progress 可用 | 默认开启，可配置关闭，CVE-2026-109619的确认利用路径之一 | 可，作为临时缓解 |
Q14：为什么攻击请求必须是 multipart/form-data 的 POST 上传请求？
A：漏洞触发点位于 PHP 内核 multipart 表单解析模块，只有该类型请求才会进入对应解析逻辑，触发内存分配与释放的缺陷。
multipart/form-data 是 HTTP 协议中用于提交表单数据（尤其是文件上传）的编码格式。PHP 在解析这种格式的请求体时，会调用专门的多部分解析器，将请求体拆分为多个部分并处理文件数据。PHP2Shell 的缺陷正存在于这一解析流程的内存管理环节，因此其他 Content-Type（如 application/x-www-form-urlencoded、application/json）不会进入该代码路径，无法触发漏洞。
Q15：攻击者可以实现哪些攻击效果？
A：一共三类效果：
一是发送畸形大请求触发内存耗尽，PHP 进程崩溃，业务中断；
二是内存信息泄露，读取进程内遗留的会话、凭证等敏感数据；
三是在满足内存布局条件下，实现无文件远程代码执行。
表 15-1 三类攻击效果对比
| 攻击效果 | 对应缺陷 | 影响维度 | 业务后果 |
|---|---|---|---|
| 进程崩溃 | 内存耗尽（OOM） | 可用性 | 服务中断、网站无法访问 |
| 内存信息泄露 | 释放后使用（UAF） | 机密性 | 数据库账号、接口密钥、会话数据外泄 |
| 远程代码执行 | 释放后使用（UAF） | 机密性、完整性 | 服务器被控制、植入后门、横向移动 |
Q16：内存泄露能够获取哪些敏感信息？
A：可读取 PHP-FPM 进程内存中残留的内容，包括请求参数、会话数据、数据库账号密码、接口密钥等业务凭证。
由于 PHP-FPM 工作进程会复用，前一个请求处理完毕后，内存中可能残留敏感数据。攻击者通过释放后使用缺陷读取这些残留内存，即可获取本应已释放的机密信息。这种攻击不需要写入任何文件，也不产生命令执行日志，因此隐蔽性极强。
Q17：漏洞 RCE 成功后，是否可以直接完成容器逃逸？
A：漏洞本身不自带容器逃逸能力。远程代码执行成功后，攻击者仅获得容器内命令执行权限，如需逃逸还需要利用容器环境其他漏洞，属于后续衍生风险。
需要区分两个阶段：第一阶段是利用 PHP2Shell 获得 PHP 进程权限（通常是 www-data 或 php-fpm 用户）；第二阶段才是尝试提升权限或逃逸容器。后者依赖于容器配置（如特权模式、挂载敏感目录、内核漏洞等），与 PHP2Shell 本身无关。
Q18：攻击者如何保证两次请求命中同一个 PHP-FPM 工作进程？
A：依靠 HTTP 长连接，让多条请求持续调度到同一个工作进程，从而实现跨请求内存状态复用。
PHP-FPM 默认启用长连接保持机制。当客户端与 PHP-FPM 之间建立持久连接后，同一连接上的多个请求会被调度到同一个工作进程处理。攻击者通过保持连接并快速发送构造请求，可以显著提高命中同一进程的概率，为跨请求内存复用创造条件。
Q19：该漏洞的远程代码执行是否可以绕过 disable_functions 限制？
A：在完成内存破坏、成功劫持执行流的场景下，可以绕过 PHP 层 disable_functions 限制，直接执行系统命令。
disable_functions 是 PHP 应用层的函数禁用配置，作用于 PHP 代码层面的函数调用（如 system、exec、passthru 等）。而 PHP2Shell 属于内核层内存破坏，攻击者通过控制指令指针或返回地址，可以直接跳转到系统调用或 gadgets，完全绕过 PHP 语言层的限制。同理，open_basedir、Suhosin 等应用层防护也无法阻挡内核层利用。
Q20：公开概念验证代码的利用门槛怎么样，扫描器是否已经支持检测？
A：互联网已经出现概念验证代码，使用 Python 即可构造恶意请求；Nuclei 等扫描器已经增加检测规则，但部分环境下利用存在稳定性差异。生产环境严禁直接使用概念验证代码测试，有造成服务崩溃风险。
表 20-1 公开工具与检测支持情况
| 工具/资源 | 状态 | 说明 |
|---|---|---|
| 概念验证代码 | 已公开 | Python 脚本可构造畸形 multipart 请求 |
| Nuclei 扫描模板 | 已支持 | 可检测部分环境，但存在误报与漏报 |
| 在野利用 | 已出现 | 黑产针对 PHP-FPM 共享虚拟主机批量扫描 |
特别提醒：在生产环境运行概念验证代码可能直接触发内存耗尽导致服务崩溃，务必在隔离的测试环境中验证。
四、防护能力边界与缓解措施
Q21：WAF、CDN 能否完全拦截本次漏洞攻击？
A：WAF 可基于请求特征拦截部分载荷，但载荷变形后存在绕过可能。WAF 只能识别流量特征，无法感知内存堆操作，不能从根源阻止漏洞利用。
WAF 与 CDN 的防护边界在于网络层与请求特征层，而 PHP2Shell 是内存层缺陷。攻击者可以通过分块传输、编码变形、拆分请求等方式绕过基于签名的检测。因此，WAF 只能作为临时缓解手段，不能替代版本升级。
Q22：关闭 session.upload_progress 能不能彻底防御漏洞？
A：关闭该配置可以大幅提升利用门槛，但不能根治漏洞，存在潜在绕过路径，仅作为临时缓解手段，不能替代版本升级。
关闭上传进度统计功能后，当前已知的利用路径被阻断，因为漏洞触发点位于该功能的处理逻辑中。但攻击者可能找到其他进入 multipart 解析模块的路径，或通过其他配置组合重新触发缺陷。因此，关闭该配置属于“缓解”而非“修复”。
Q23：修复 PHP2Shell 的根本方案是什么？升级后需要做什么操作？
A：根本方案是升级 PHP 到官方安全版本。升级完成后必须重启 PHP-FPM 或 Web 服务，新版本程序才会加载生效。
升级操作建议按以下步骤执行：
第一步，升级前完成服务器快照、数据备份与回滚方案；
第二步，通过包管理器或源码编译升级至修复版本；
第三步，重启 PHP-FPM、Nginx、Apache 服务；
第四步，验证业务稳定性，确认 PHP 版本与配置生效；
第五步，开展漏洞复测，确认风险消除。
Q24：业务暂时无法升级 PHP，有哪些临时缓解手段？哪些手段无效？
A：官方针对两个 CVE 分别给出了不同的临时缓解方向，需区分对待，不能一概而论。针对 CVE-2026-109618（OOM 损坏型） ，PHP 官方安全公告的首要临时缓解措施是 设置 memory_limit = -1，并建议通过 php_admin_value 等在应用无法覆盖的层级强制实施，同时确认没有池、目录或应用设置重新引入有限的内存上限。其原理是移除攻击者可控的“PHP 内存上限失败”触发条件；但需注意，底层分配失败仍可能到达同一脆弱路径，因此这只是降低暴露面，不是完整修复。针对 CVE-2026-109619（跨请求过期全局状态） ，确认的缓解包括 关闭 session.upload_progress.enabled 以及 关闭 fatal_error_backtraces（PHP 8.5 上确认的 producer 路径），两者均需重启工作进程才能生效。
表 24-1 临时缓解措施有效性对比
| 缓解措施 | 有效性 | 说明 |
|---|---|---|
| 调整 memory_limit | 高 | 移除可控的内存上限触发条件；底层分配失败仍可能到达脆弱路径，不能替代升级 |
| 关闭 session.upload_progress | 高 | 阻断当前已知利用路径，需重启生效 |
| WAF 增加畸形 multipart 检测 | 中 | 基于请求特征拦截，存在绕过可能 |
| 限制 POST 请求最大尺寸 | 中 | 增加攻击成本，但畸形小请求仍可能触发 |
| 收紧访问源 | 中 | 仅允许可信 IP 访问上传接口 |
| 调高 PHP-FPM 进程自动重启次数 | 低至中 | 减少跨请求内存残留窗口 |
Q25：调整 PHP-FPM 进程回收策略能起到什么作用？
A：配置 pm.max_requests，让工作进程在处理指定数量请求后自动重启，能够减少跨请求内存残留，降低利用成功率，但不能消除漏洞本身。
该措施的原理是：通过强制进程回收，缩短单个工作进程处理请求的生命周期，从而降低攻击者构造跨请求内存复用的窗口。但由于漏洞触发本身不需要跨请求（内存耗尽型），该措施对拒绝服务类攻击无效，仅对释放后使用类攻击有一定缓解作用。
Q26：open_basedir、Suhosin 这类 PHP 安全扩展能否挡住漏洞利用？
A：不能。open_basedir、Suhosin 属于 PHP 应用层防护，一旦攻击者完成内存破坏劫持执行流，就可以绕过这类 PHP 层限制。
open_basedir 限制 PHP 脚本可访问的目录树，Suhosin 提供额外的函数与执行保护。但两者都在 PHP 语言层生效，而 PHP2Shell 是内核层内存破坏。攻击者通过控制内存执行流后，可以直接调用系统功能，不受这些应用层配置约束。
Q27：EOL 停止维护的老旧 PHP 版本，没有官方补丁该怎么处置？
A：优先迁移至受官方支持的 PHP 版本。无法迁移的场景，评估商业长期支持补丁；同时叠加网络隔离、最小权限、WAF 审计等多层防护，持续监控异常访问。
对于已停止维护的 PHP 8.1 及更早版本，处置路径如下：
第一，制定迁移计划，尽快升级至受支持分支（8.2、8.3、8.4、8.5）；
第二，迁移前，将老旧版本资产从公网隔离，仅允许内网或可信源访问；
第三，如业务无法迁移，评估第三方商业长期支持（LTS）补丁的可行性；
第四，叠加网络层防护（WAF、网关限制）与主机层加固（最小权限、日志审计）。
Q28：虚拟主机用户没有权限升级底层 PHP，该如何处置？
A：第一时间联系主机服务商，要求升级底层 PHP 环境；临时限制上传接口，配置 WAF 防护，持续审计访问日志。
虚拟主机用户通常无法直接修改 PHP 版本或 php.ini 全局配置，可采取的措施包括：
一是联系服务商确认升级计划与时间表；
二是通过 .htaccess 或用户级配置尝试关闭上传进度统计功能（如服务商允许）；
三是临时禁用或收紧业务的文件上传功能，减少攻击面；
四是持续监控网站访问日志与错误日志，发现异常及时处置。
五、自查检测、入侵排查与应急响应
Q29：如何快速自查服务器 PHP 版本，判断是否存在风险？
A：执行版本查询命令查看版本；批量资产可使用自动化脚本采集 PHP 版本、服务器 API 类型、php.ini 配置，对照官方受影响版本范围判定风险。
# 查询 PHP 版本
php -v
# 查询 PHP-FPM 版本
php-fpm -v
# 查询上传进度配置
php -i | grep upload_progress
# 查询当前加载的 php.ini 路径
php --ini
对于批量资产，建议通过网络空间测绘或内部资产清单，识别开放 80/443 端口且响应头包含 PHP 版本信息的资产，再逐一核查版本与配置。
Q30：漏洞被利用后，日志中会出现哪些异常特征？
A：常见异常包括：大量 multipart/form-data 类型 POST 请求、畸形 boundary 字段、500 错误、内存耗尽报错、PHP-FPM 进程异常重启。
表 30-1 漏洞利用后的日志异常特征
| 异常特征 | 对应攻击阶段 | 日志位置 |
|---|---|---|
| 大量 multipart/form-data POST 请求 | 探测与利用 | Web 访问日志 |
| 畸形 boundary 字段 | 构造恶意请求 | Web 访问日志 |
| HTTP 500 错误 | 进程崩溃 | Web 访问日志、PHP 错误日志 |
| 内存耗尽（OOM）报错 | 触发 OOM 缺陷 | PHP 错误日志、系统日志 |
| PHP-FPM 进程异常重启 | 工作进程崩溃 | PHP-FPM 慢日志、系统日志 |
Q31：只做内存泄露、不执行命令的攻击，日志会有什么特征？
A：这类攻击不会产生命令执行日志，仅会出现特殊构造的 multipart POST 请求，痕迹隐蔽，很容易被忽略。
由于攻击者仅读取内存数据，不调用系统命令、不写入文件，因此系统日志、文件监控、命令审计均无记录。唯一的痕迹是访问日志中特殊构造的 multipart 请求。这要求运营人员不能仅依赖命令执行日志，还需关注请求体特征与频率异常。
Q32：如何从访问日志筛选可疑的攻击请求？
A：筛选 Content-Type 为 multipart/form-data 的 POST 请求，重点关注 boundary 异常、请求体超长的请求。
可参考的日志筛选思路如下：
# 筛选 multipart/form-data 请求
grep "multipart/form-data" /var/log/nginx/access.log
# 筛选 boundary 异常（如超长、含特殊字符）
grep -E "boundary=[^;]{0,10}$" /var/log/nginx/access.log
# 筛选大请求体（如超过 1MB）
awk '($10 > 1000000){print}' /var/log/nginx/access.log
实际环境中，建议结合请求频率、来源 IP 集中度、User-Agent 异常等维度综合研判。
Q33：FIM 文件完整性监控为什么很难发现该漏洞攻击？
A：漏洞支持无文件远程代码执行，攻击过程不写入恶意文件，文件完整性监控（FIM）只监控文件变更，无法识别内存层面的攻击行为。
FIM 通过比对文件哈希检测文件新增、修改、删除，而 PHP2Shell 的攻击载荷完全存在于 HTTP 请求与内存中，不产生文件系统变更。因此，依赖 FIM 的检测策略对这类无文件攻击基本无效，必须结合网络流量分析、进程行为监控、内存取证等手段。
Q34：如何判断 PHP-FPM 进程内存耗尽是业务正常现象还是漏洞攻击导致？
A：结合 Web 访问日志判断：漏洞攻击引发的内存耗尽会伴随畸形 multipart POST 请求；业务内存耗尽一般来自正常业务大文件上传、业务自身内存泄漏。
表 34-1 业务内存耗尽与漏洞攻击的区分
| 判断维度 | 业务正常现象 | 漏洞攻击 |
|---|---|---|
| 请求特征 | 正常文件上传，boundary 规范 | 畸形 multipart，boundary 异常 |
| 请求频率 | 与业务量匹配 | 突发高频，来源集中 |
| 时间分布 | 工作时间或业务高峰期 | 无明显规律，可能持续扫描 |
| 进程行为 | 内存缓慢增长后回收 | 突发崩溃，伴随大量 500 错误 |
Q35：怀疑服务器已经被入侵，应急处置步骤是什么？
A：应急处置步骤如下：
图 35-1 疑似失陷后的应急处置流程
第一步，隔离受害主机，阻断横向移动；
第二步，优先完成内存取证，再制作磁盘镜像，避免重启导致证据丢失；
第三步，审计 Web、PHP-FPM、系统日志，还原攻击时间线；
第四步，排查恶意进程、异常账号、定时任务、启动项等持久化机制；
第五步，清除后门与恶意文件，修改相关凭据；
第六步，修复漏洞（升级 PHP 或关闭上传进度统计），恢复业务；
第七步，完成事件溯源复盘，完善防护机制。
特别强调：在未完成内存取证前，禁止直接重启服务器，否则易丢失内存中的攻击痕迹。
六、威胁态势与长期安全思考
Q36：当前互联网是否已经出现在野批量扫描和利用？
A：漏洞披露后，互联网已经出现批量探测行为，黑产逐步开展在野利用，重点瞄准 PHP-FPM 共享虚拟主机资产。
共享虚拟主机由于单台服务器承载大量站点，且用户权限有限、升级滞后，成为黑产批量扫描的高性价比目标。建议共享虚拟主机用户与服务商保持沟通，及时完成底层 PHP 升级。
Q37：漏洞利用成功后，攻击者常见后续动作是什么？
A：攻击者获取执行权限后，通常植入持久化后门、部署挖矿程序、窃取数据库凭证，尝试在内网横向移动，窃取业务敏感数据。
表 37-1 攻击者常见后续动作
| 后续动作 | 目的 | 检测难度 |
|---|---|---|
| 植入持久化后门 | 维持访问权限 | 中（可通过文件、进程、定时任务监控发现） |
| 部署挖矿程序 | 消耗算力获利 | 低（CPU 异常、异常外联易发现） |
| 窃取数据库凭证 | 获取业务数据 | 中（需结合流量与日志分析） |
| 内网横向移动 | 扩大控制范围 | 高（依赖内网流量监控与身份审计） |
Q38：企业处置该漏洞，推荐的工作优先级是什么？
A：推荐按以下优先级推进：
图 38-1 企业处置 PHP2Shell 漏洞的工作优先级
第一，资产测绘，识别受影响 PHP 资产；
第二，部署临时防护，降低被利用风险；
第三，升级 PHP 版本，完成根本修复；
第四，日志审计排查入侵痕迹，确认是否已失陷；
第五，完善长期组件漏洞管理机制，防止同类问题复发。
Q39：这类底层内存漏洞为什么很难被传统代码审计发现？
A：漏洞位于 C 语言编写的 PHP 内核，依赖多请求时序与内存复用场景。传统静态代码扫描、业务代码审计，很难覆盖跨请求内存状态残留这类动态边界场景。
传统代码审计主要针对业务代码的逻辑缺陷（如注入、越权、校验不严），而内核漏洞属于内存安全问题，需要模糊测试、动态分析、污点跟踪等专门技术。此外，跨请求时序依赖运行时状态，静态分析难以覆盖，必须结合动态执行与压力测试才能暴露。
Q40：从 PHP2Shell 事件来看，企业针对基础组件应当建立怎样的长效防护机制？
A：建议建立软件资产台账，持续跟踪底层组件漏洞；定期开展版本巡检；完善漏洞应急响应流程；对基础组件增加内存安全相关的动态测试。
长效防护机制的核心要素如下：
表 40-1 基础组件长效防护机制
| 机制 | 关键动作 | 预期效果 |
|---|---|---|
| 软件资产台账 | 登记所有基础组件（PHP、Nginx、OpenSSL 等）及版本 | 漏洞爆发时快速定位受影响资产 |
| 版本巡检 | 定期核查组件版本与官方安全公告 | 及时发现滞后版本 |
| 应急响应流程 | 预设高危漏洞的处置剧本与责任人 | 缩短从披露到修复的时间窗口 |
| 内存安全测试 | 对基础组件增加模糊测试与动态分析 | 在上游发现潜在内存缺陷 |
PHP2Shell 再次说明：Web 安全不仅是业务代码的安全，底层运行时的安全同样关键。企业需将基础组件纳入统一的漏洞管理范畴。