4946 条请求背后：从攻击日志深度拆解 PHP2Shell 攻击

原创 威胁情报中心 2026-10-26 17:50 北京

`PHP_SESSION_UPLOAD_PROGRESS` 只是入口特征，不是漏洞利用成功的证明。近期流量中，批量扫描、传统会话投毒、管理员会话伪造、命令执行验证和恶意脚本投放混在一起。

2026 年 10 月 21 日，PHP 发布紧急安全版本，修复 CVE-2026-109618 与 CVE-2026-109619。随后，互联网迅速出现大量带有 PHP_SESSION_UPLOAD_PROGRESS 字段的请求。

对 10 月 19 日至 25 日出现的 4946 条相关 POST 请求重新聚类后，可以看到一个比“PHP2Shell 大规模利用”更复杂、也更值得警惕的图景：

• 扫描流量占据显著比例。204.76.203[.]7 一个地址就产生 1320 条请求，但其 Payload 只有 p2s-rider 或 probe，没有可执行代码。
• 传统攻击链正在借用新热点。27.159.66.104 持续投递管理员会话序列化数据；另有请求把 PHP 代码放在上传文件名中，仍依赖会话投毒、文件包含或反序列化等附加条件。
• 恶意投放行为真实存在。10 月 23 日出现 818 条具有相同下载执行命令前缀的请求，其中 715 条保留了完整的 217.60.102[.]5/sh 地址，另外 103 条因请求体截断只保留相同前缀。
• “发起攻击”与“攻击成功”必须分开。现有请求和可见响应中，没有出现命令回显、WebShell 后续访问或二次下载执行证据，因此不能据此宣布任何目标已经失陷；同样，也不能因为缺少证据就断言全部失败。

01 先厘清一个误区：同一个字段，不等于同一种漏洞利用

PHP_SESSION_UPLOAD_PROGRESS 是 PHP 会话上传进度功能的表单字段。它之所以在这轮事件中高频出现，是因为 CVE-2026-109619 的一条已确认攻击路径经过该功能，而传统 PHP 会话投毒也经常利用它。

但两项 PHP2Shell 漏洞的本质并不是“PHP 会直接执行这个字段里的代码”。

传统会话投毒则是另一条逻辑链：攻击者把可控内容带入会话序列化数据，再通过本地文件包含、不安全的会话读取或反序列化条件使其进入执行上下文。

还有两个细节决定了“写入”不能简单等同于“执行”：

1. 上传进度值通常会参与构造会话中的上传进度键名，而不是作为一个独立 PHP 文件直接运行。
2. session.upload_progress.cleanup 等配置会影响上传完成后进度数据的清理，部分传统利用还涉及时序竞争。

02 按攻击意图重新分类：这批流量里至少有五种角色

以下分类依据攻击源、请求路径、User-Agent、会话标识和 Payload 内容综合判断。部分请求体存在截断，不能仅按单一关键词统计。

这五类行为的危险等级和取证方法完全不同。把它们统一统计为“PHP2Shell 攻击成功流量”，会同时造成高估成功率和低估真实投放风险。

03 重点攻击源画像

1. 77.90.185.20：单日集中投递，目标明确指向外部脚本执行

该地址在 10 月 23 日 04:29 至 22:55 集中产生 639 条请求，全部访问 /index.php。其中：

• 513 条使用带有 Chrome/147.0.0.0 的浏览器形态 User-Agent，126 条未提供 User-Agent；
• 每条请求均带有随机化的 PHPSESSID；
• 639 条均出现相同的 __START__ 与下载执行命令前缀；
• 551 条保留完整下载地址，其余 88 条在 128 字节处截断，但前缀一致；
• 17 条得到 HTTP 200，另有少量 500、502、503；状态码本身不能证明执行结果。

核心 Payload 为：

这段命令可以拆成四层：

1. 结果定位：用 __START__、__END__ 包裹预期输出，便于自动化工具从网页内容中定位执行结果。
2. 下载兜底：优先使用 wget，失败后切换到 curl。
3. 削弱证书校验：--no-check-certificate 与 -k 都降低 TLS 证书验证约束，使裸 IP、自签名证书等部署更容易被直接利用。
4. 下载即执行：脚本不先落盘，而是通过管道交给 sh；php2shell 是传给脚本的参数，可用于标记入口或选择执行逻辑，但它本身不是恶意软件家族名称。

部分请求还加入大量随机 pad_N 字段，使请求体结构更复杂。它们可能改变请求解析和内存分配形态，但仅凭这些字段不能断定其具体堆布局作用。

更值得注意的是，217.60.102[.]5/sh 并非首次出现。10 月上旬的公开蜜罐研究已经观察到同一地址被用于 RedTail 相关载荷分发，服务于 Apache 路径穿越、PHP-CGI 参数注入等不同入口。ThreatFox 后续也将该 URL 与 RedTail、PHP2Shell 标签关联。

这说明该基础设施具有跨漏洞复用特征：攻击者不必为每个新漏洞重新建设下载体系，只需替换初始入口。不过，URL 和命令模板复用不能单独证明所有请求都由同一组织控制。

2. 204.76.203.7：高频不等于高危，典型目标清单型探测

该地址在 10 月 24 日 18:44 至 25 日 15:34 产生 1320 条请求：

• 734 条上传进度值为 p2s-rider；
• 586 条为 probe；
• 请求体仅约 201—236 字节；
• 统一使用 Firefox/128.0 形态 User-Agent；
• 请求路径集中在 / 与 /index.php。

这些请求没有 PHP 代码、系统命令或反序列化对象，不能称为“直接投递 WebShell”。其更符合自动化暴露面探测：用统一标记触发上传进度处理路径，再根据响应或后续状态筛选目标。

10 月 25 日，Defused Cyber 公开披露在 GlobalProtect 蜜罐上也看到来自该地址、带有 p2s-rider 的同类请求。这与本次观察在源地址和标记上完全吻合，说明其扫描范围并不限于普通 PHP 页面。公开材料并未证明这些探测已经成功利用漏洞，也不足以据此推断扫描者身份。

3. 27.159.66.104：不是系统命令投放，而是管理员会话状态伪造

该地址在 10 月 19 日至 25 日持续活跃，共出现 942 条相同 Payload 请求，占同类 1063 条记录的绝大多数。请求只落在四种路径变体：

上传进度值固定为：

其关键字段非常直白：id=1、isadmin=1、name=admin、status=1。攻击者试图把会话内容导向“已认证管理员”状态，而不是在当前请求里执行 id、wget 等操作系统命令。

这类 Payload 是否有效，取决于多个应用侧条件：会话序列化处理器如何解析该字符串、应用是否读取相应会话键、是否直接信任其中的管理员标记，以及后续请求能否复用同一会话。字符串中出现 admin 不等于已经获得管理员权限，HTTP 200 也不能证明会话伪造成功。

从漏洞归类看，它更接近应用特定的会话注入或反序列化滥用，不能仅因使用相同上传进度字段，就直接归入 CVE-2026-109618 或 CVE-2026-109619 的成功利用。

4. 85.11.167.243：新漏洞探针与 PHPUnit 老路径混用

该地址在 10 月 21 日至 22 日产生 407 条请求，具有明显的工具模板特征：

• 384 条 User-Agent 为 php2shell-109618；
• 402 条上传进度值为 x，5 条为 pwn；
• 使用 a1b2c3d4e5f6a7b8c9d0e1f2a3、attacksessionid0001 等固定会话标识；
• 228 条访问 /lib/phpunit/phpunit/Util/PHP/eval-stdin.php，其余主要访问 /index.php 与 /wp-login.php；
• 请求体最大约 62.9 KB，包含重复填充内容。

另一份数据样本中的 114 条同来源记录里，3 条带有可见请求体。它们不再只是 x 标记探针，而是包含固定 PHPSESSID、5184 字节 A／B 填充，以及重复的 t[] 字段；字段中反复出现以下命令形态：

这不是常规 PHP 函数调用写法，system 与 wget 之间也没有可读的空格或括号，更像面向内存破坏链构造的命令与地址数据，而不是可直接粘贴运行的脚本。三条请求声明的 Content-Length 均为 62929，但可见部分的 t[] 数量不同，说明保留内容存在截断，不能按可见数量还原完整请求。其结果分别为 502、HTTP 状态字段为 0 和未捕获到有效响应，均未出现命令回显或下载成功证据。

eval-stdin.php 对应 PHPUnit 历史漏洞 CVE-2017-9841 的常见利用路径。把 PHP2Shell 探针发往该路径，可能反映扫描器同时复用多个漏洞模板，也可能是在测试不同入口的通用可达性；它不能证明 PHPUnit 漏洞或 PHP2Shell 任一漏洞可用。

这些特征说明其活动具有自动化扫描性质，但仍不能把扫描请求当作成功入侵。

5. 112.17.242.3：从“是否可达”升级为“能否执行系统命令”

该地址在 10 月 22 日约 79 分钟内发送 92 条请求，User-Agent 为空，Payload 固定为：

id 用于返回执行账户的用户、组信息，前后标记用于自动提取输出。与 x、probe 不同，这已经是主动的命令执行验证；与下载外部脚本相比，它仍属于相对低破坏性的执行确认阶段。

可见结果只有 405 或未捕获到有效响应，未出现 php2shell_out_start 与 uid= 回显。因此，合理结论是“存在明确的 RCE 验证意图”，而不是“RCE 已成功”。

04 Payload 的真正分水岭：内容写在哪里，后续由谁执行

仅看是否包含 <?php，会同时漏报和误报。更有效的分析方式，是同时检查 Payload 的位置、执行原语和后续依赖。

在这份样本中，181.215.5[.]248 提供了一个典型例子。该地址在 10 月 25 日 10:02—10:03 连续发送两次内容相同的请求：声明 Content-Length: 65104，包含固定 PHPSESSID、上传进度值 x、5184 字节 A／B 填充，以及 149 个编号为 t[0]—t[148] 的字段。字段内反复出现地址样字节和连续的 systemid 字符串，完全没有可读的 <?php 标签。

这类请求不应按普通 PHP 代码注入理解：其结构更接近内存布局塑造与命令执行阶段的数据构造。两次请求一次返回 HTTP 200，另一次未捕获到有效响应，均没有 uid=、进程或出站证据。因此可判定为具有命令执行意图的二进制形态利用尝试，不能判定执行成功。

少量样本还出现了更明确的持久化意图：

• filename="<?php echo '===RCE==='; system($_GET['c']); die(); ?>"：一旦进入执行上下文，可通过 c 参数传入命令。
• 带有 P2SAB30V32M5NI6 标记的 Payload：同时包含 $_REQUEST['c'] 命令接口和基于 file_put_contents() 的文件写入接口。

这些代码说明攻击者准备了后续控制接口，但“Payload 具备 WebShell 功能”与“WebShell 已经写入并可访问”仍是两个不同事实。

另一份数据样本还显示，135.136.40[.]135 与另一公网来源的两条记录具有完全相同的请求体文本：使用相同的 multipart boundary、PHPSESSID、上传进度值 k1 和 P2S4758KKYW25ZS 标记，文件名中同时包含 $_REQUEST['c'] 命令接口与 Base64 文件写入接口。两条记录均返回 HTTP 200，但响应只是正常页面，没有出现该标记或 WROK: 写入回显。

这种一致性支持“复用同一扫描模板或请求重放”的判断，但不能仅凭模板相同就认定两个来源由同一攻击者控制。后者后续还出现了带唯一 NUCLEI... 标记的文件名 Canary，说明其同时使用了参数化 WebShell 模板和 Nuclei 探测模板。

05 公开案例补充：从攻击意图到完整执行链

前述材料主要呈现 Web 请求和有限响应，能够还原攻击源与 Payload 意图，以下部分公开案例补充攻击链中未被观察到的环节，并与本次流量中的下载执行命令、命令验证标记和成功性判断标准相互印证。

1. 进程级确认的 RCE：四阶段请求与 35 次 shell 执行完成闭环

一份公开蜜罐证据报告把网络包、Apache／PHP 错误和 Tetragon 进程事件逐条关联，确认 35 个执行阶段 POST 对应 35 次由 Apache worker 直接启动的 /bin/sh：

• 15.204.59[.]70 对应 3 次；
• 162.35.99[.]94 对应 32 次。

其成功链不是单独一个带有 system() 的短请求，而是四个阶段：

执行后观察到 apache2 → /bin/sh → id／php／curl 等进程关系，部分请求还尝试通过 HTTP 回连攻击源。这里的决定性证据不是 HTTP 状态码，也不是 OOM 或 worker 崩溃，而是非预期的 Apache 子 shell 及其子进程。

该报告还有三个值得防守方记住的细节：

• 成功环境为 PHP 8.4.26、单 worker 的 Apache mod_php，不能外推为所有环境的利用成功率。
• 最终执行后 worker 可能崩溃，导致正常访问日志缺少完成记录。
• 虽然观察到 curl、wget 和 PHP HTTP 请求，但报告没有确认任何第二阶段文件被成功下载。

研究者认为请求序列与 CVE-2026-109618 的公开泄漏引导利用链一致；这些证据并未证明使用了另一条独立的 CVE-2026-109619 路径。

这一案例也与本次流量的研判形成两点印证：其一，带有 id、curl、wget 的 Payload 确实对应攻击者希望到达的执行与投放阶段；其二，Payload 中出现这些命令仍只代表意图，只有 worker 派生 shell、命令子进程或对应出站行为才能补足成功证据。

2. 第二阶段基础设施关联 Potassium，但不能补全未观察到的执行

Arctic Wolf 披露了另一组具有明确武器化意图的 Payload：

另一变体还尝试枚举操作系统和执行账户，并从同一服务器获取文件。相关基础设施上发现 ARM 与 x86-64 两个 Potassium 样本，后者属于 Mirai 衍生僵尸网络家族。

这里必须把两句话同时保留：基础设施与 Potassium 样本存在关联；现有遥测没有证明 PHP2Shell 请求实际下载或执行了这些样本。这与本次 217.60.102[.]5 投放器的研判逻辑一致——下载命令是高优先级线索，成功下载与执行仍需出站和主机证据。

3. 后利用视角：入侵后命令呈现批量化、机器可读特征

另一则报道援引 Unit 42 的观察：攻击者在初始利用后访问认证数据库中的密码哈希与多因素认证秘密，并开展 Active Directory 侦察和权限提升尝试。

公开的后利用命令呈现三个特点：

• 使用 ==SHELLUSER==、==PASSWD== 等分隔符包裹输出；
• 批量读取 /etc/nsswitch.conf、/etc/resolv.conf、/etc/hosts、/etc/group、/etc/passwd、/etc/os-release；
• 使用 curl 发起匿名 LDAP 查询，查找管理员账户和目录信息。

Unit 42 认为这些结构化分隔符便于自动化平台或 AI Agent 解析。对防守方而言，可直接把这些标记作为高价值狩猎特征；但它们只是行为线索，不能单独用于攻击者身份归因。

06 攻击成功性：建立证据阶梯，而不是盯死 HTTP 状态码

在这 4946 条请求中，仅 195 条带有可见响应体，且存在长度限制；这些响应未出现 __START__、php2shell_out_start、===RCE===、uid= 等执行标记。因此，现有材料只能支持“攻击已发出”或“请求被应用接收”，不能支持“目标已失陷”。

建议使用以下证据阶梯：

对本次投放器流量，最关键的补证动作是：检查是否出现指向 217.60.102[.]5 的出站连接，以及 PHP／Web worker 是否派生 sh、wget、curl。没有这些证据，不能把 200 当成功；一旦出现，则应立即进入事件响应，而不是继续只做 Web 告警统计。

07 处置建议：补丁优先，检测必须覆盖“请求之外”

1. 完成 PHP 运行时用补丁。官方修复版本为 8.2.35、8.3.36、8.4.27、8.5.12。发行版或 LTS 包可能回移植修复而保持旧版本号，应以供应商公告和包更新记录为准。升级后重启全部相关 PHP／Apache worker，避免旧进程继续运行。
2. 不要把关闭上传进度当作完整修复。session.upload_progress.enabled=0 只覆盖 CVE-2026-109619 的已确认会话路径，不能消除 CVE-2026-109618 或其他变体；配置必须在请求解析前生效，并重启 worker。
3. 将 IOC 用于回溯，不只用于实时封禁。重点检索 77.90.185[.]20、217.60.102[.]5、公开确认 RCE 的两个源地址，以及下文 Payload 标记。封禁 IP 不能替代补丁和历史排查。
4. 补看完整请求序列。围绕同一源地址和会话标识扩展时间窗，寻找 A1／B1／A2／B2 阶段、文件包含请求、?c=、?cmd= 和新 PHP 文件访问，而不是只检索一个上传进度字段。
5. 把进程与出站检测提到最高优先级。关注 Web worker 派生 shell、下载工具、脚本解释器，以及向非常用裸 IP 的 HTTP／HTTPS 连接。
6. 检查会话与 Web 目录。寻找包含 PHP 代码、序列化对象或异常管理员字段的 sess_* 文件，以及新增或修改的 PHP 文件；同时保留原始文件和时间信息供取证。
7. 谨慎使用公开 PoC。不要在生产环境直接运行来源不明的利用代码。版本与配置核验、供应商检测工具和只读检查应优先于主动触发内存破坏。

A 技术附录 A：MITRE ATT&CK 技术映射

B 技术附录 B：失陷指标与攻击指标（IOC／IOA）

B.1 本次观察到的重点地址

B.2 10 月 22 日后公开案例指标

B.3 高价值 Payload 与请求特征

其中 probe、x、通用 User-Agent 和常见路径单独使用时噪声较高，应与源地址、会话 ID、请求体结构和后续行为组合检测。

B.4 公开案例请求体与样本哈希

以下 SHA-256 来自公开报告。请求体哈希对应解码后的完整 multipart body，不是 PCAP 或 chunked 线上字节流。

C 技术附录 C：检测与狩猎要点

• Web 侧：检索异常 multipart POST、过多 parts、深度嵌套字段、超长字段名、无有效 Content-Length 的大请求，以及不符合业务基线的上传进度字段。
• 响应侧：关注异常超长或包含非预期编码内容的 Set-Cookie: PHPSESSID=，以及唯一执行标记之间的命令输出。
• 错误日志：关联 Unknown on line 0 的内存耗尽、会话启动警告、zend_mm_heap corrupted、段错误和 worker 异常退出。单个错误不能独立确认 RCE。
• 主机侧：重点检测 apache2、httpd、php-fpm 派生 sh、curl、wget、php 等异常子进程，以及 Web 目录和临时目录中的可疑文件变化。
• 网络侧：将攻击源请求与随后数分钟内的出站连接关联，特别关注裸 IP、非常用端口和下载后立即执行的行为。
• 证据保全：保留完整请求与响应、源端口、worker PID、进程父子关系和时间戳。只有这些字段能够跨数据源重建完整攻击链，避免把多个无关请求误拼为一次成功入侵。

D 技术附录 D：统计口径与证据限制

• 覆盖范围：4946 条记录以 PHP_SESSION_UPLOAD_PROGRESS 特征为统计入口，不代表全部 PHP2Shell 流量；尤其不能覆盖不含该字段的 CVE-2026-109618 请求，也不能单独发现后续 LFI、WebShell 使用或出站下载。
• 内容完整性：部分请求体仅保留前缀，部分响应存在长度限制。对截断样本只统计可验证的相同前缀，不推测缺失部分一定与完整 Payload 完全相同。
• 记录处理：按直接请求统计，剔除可识别的入库伪影；公开蜜罐和事件响应案例独立列示，不并入上述请求数量。
• 成功性边界：现有材料不包含完整的进程、文件和出站遥测。“未发现成功证据”不等于“已证明全部失败”，公开案例中的确认结果也不能反向套用到本次其他请求。

结语

PHP2Shell 热点之后，最危险的分析误区有两个：一是把所有带上传进度字段的请求都视为同一漏洞利用，二是把 HTTP 200 或 worker 崩溃直接写成“攻击成功”。

从攻击源和 Payload 看，本轮活动已经覆盖暴露面扫描、会话伪造、命令验证和外部脚本投放；从公开案例看，真实 RCE 也已出现进程级证据。防守方真正需要建立的，不是更大的关键词告警列表，而是一条能够贯穿请求序列、PHP 内部异常、进程执行和出站连接的证据链。

参考链接

1. PHP 官方 — 2026 年安全公告与版本说明
https://www.php.net/archive/2026.php#2026-10-21-5

2. PHP 官方安全公告 — CVE-2026-109618／GHSA-w8hw-w9fx-j79w
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

3. PHP 官方安全公告 — CVE-2026-109619／GHSA-6wmf-4rv5-p3rp
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

4. 0x4D31 Honeypot Data — PHP2Shell exploitation observed：packet-to-process RCE evidence（2026-10-24）
https://github.com/0x4D31/honeypot-data/blob/main/reports/php2shell/2026-10-24-confirmed-rce.md

5. 0x4D31 — PHP2Shell：observed exploitation attempts，22—24 October 2026
https://gist.github.com/0x4D31/6b1e7b5fb7a10219af187be91335c96f

6. Arctic Wolf — PHP2Shell Critical PHP Vulnerabilities Enable Unauthenticated RCE
https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/

7. The Hacker News — PHP2Shell Exploitation Hits Government Entity Amid Global Scanning and Signs of AI-Assisted Hacking
https://thehackernews.com/2026/10/php2shell-exploitation-hits-government.html

8. The Hacker News — Someone Tried to Exploit PHP2Shell 4 Days Before Disclosure
https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html

9. Cloudflare — Deploys protections against PHP2Shell vulnerability
https://blog.cloudflare.com/php-vulnerabilities-waf-protection/

10. GreyNoise Swarm 研究转载 — One Loader／RedTail
https://inksec.io/blue-team/greynoise/one-loader-redtail/

11. ThreatFox — 217.60.102.5 相关指标检索
https://threatfox.abuse.ch/browse/

12. MITRE ATT&CK — Enterprise Matrix
https://attack.mitre.org/matrices/enterprise/

13. Wiz Research — PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
https://www.wiz.io/blog/php2shell-php-rce

阅读原文

跳转微信打开