上周，我们发布了一份报告，描述了 PHP 中的两个主要漏洞（CVE-2026-109618，CVE-2026-109619）。从那时起，Wiz 研究团队与大多数安全行业一样，在监测相关活动并审查公开可用的利用代码。目前为止，我们在我们的遥测中观察到有限数量的利用尝试，并未发现公开可用的证明概念（PoC），展示针对任意目标的完整、通用的端到端利用。然而，一些合作伙伴私下向我们披露了针对各种目标的利用，我们也在内部继续实验。展示我们成功利用的视频可在 php2shell.com 找到。本文总结了我们在实际环境以及我们自己的蜜罐数据中观察到的补救工作和利用尝试，并分享了我们对这些活动的持续调查的发现。我们将继续监测事态发展，并在新证据出现时更新此帖子。 观察到的暴露趋势 在 PHP2Shell 于 2026 年 10 月 21 日公开披露之后，Wiz 遥测记录到过去几天互联网暴露的易受 PHP2Shell 攻击的机器数量减少了约 67%。此外，在易受攻击的互联网暴露机器中，运行 PHP 版本 7.3 或更早版本的比例在五天内从 8.3% 降至 5.7%。这测量了观察到的群体中运行未获得官方补丁的旧版本的比例。在此期间，受到显著影响的组织数量——在这里定义为至少有一个暴露且易受攻击的实例——减少了约 47.9%（见下图）。作为参考，我们的数据表明 PHP 在我们的数据集中的组织使用率为 65%。这些观察结果一致表明，组织通过补丁、升级、退役受影响的机器和限制互联网访问等一系列措施共同减少其暴露（请注意，这些数据表明总体趋势，但并未确定每种补救策略的相对贡献；扫描覆盖率和观察到的群体大小也会影响总体报告的数字）。在公开披露一周后，初始受影响的组织中，保持易受攻击状态的不到 53%。 Wiz 研究观察到的利用尝试 在这种情况下，我们迄今为止观察到以下类型的活动： - 使用 PHP2Shell 利用机制的尝试，采取的技术与公开 PoC 匹配。 - 与漏洞无关的 PHP2Shell 品牌工具，依赖于会话中毒和应用程序中的单独本地文件包含（LFI）漏洞。 观察到的使用 PHP2Shell 利用机制的尝试 我们观察到两个针对 PHP 基础软件的开源利用工具的变种。在我们捕获的尝试中，没有一个完成了利用链。老版变种遇到了请求大小限制或未能产生预期的内存耗尽条件。新版变种则始终耗尽了 PHP 的内存，但未能获得继续所需的内存地址。 变种 1：传统链 第一个请求来自我们的 PHP-CGI 蜜罐，IP 地址为 3.37.227[.]134。它匹配了该工具包的旧链，这一链位于 archive/legacy-8m/exploit.py 及其附带的阶段脚本中。第一个完整的利用阶段使用包含 1005 个部分的多部分主体，包含一个名为 big 的字段，填充约 12 MB 的填充物：根据工具包的说明，此阶段尝试在会话重置期间耗尽内存，为后续请求留下会话状态。在我们的蜜罐上，它在到达该代码之前失败。声明的请求大小超出了配置的 8 MB post_max_size 限制，因此 PHP 跳过了对多部分主体的处理并记录了：作者随后已将此链移入工具包的存档目录。 另一尝试：针对 Roundcube 的后续尝试 在后续尝试中，103.151.172[.]95 从传统链发送了更长的序列，包括旨在占用其他 Apache 工作进程的停滞连接。当仅有一个工作进程可用时，该利用尝试通过发送包含 1001 个字段的 3000 字节请求进行堆塑。这些请求未能触发所需的内存耗尽流。因此，没有证据表明此尝试达到了预定的内存耗尽条件。 变种 2：当前链 我们捕获的大多数 IP 地址使用了新版链，该链由 pure/mk_a1.py 和 pure/mk_leak_b.py 构建。我们在多次尝试中观察到这个变种。这个变种经过的阶段更多：其第一个阶段始终导致 PHP 耗尽其内存。接下来的阶段，尝试泄漏进程内存，在我们捕获的每次运行中均未成功。