Amazon Threat Intelligence 在 PHP2Shell 公开披露前发现 10 月 17 日利用尝试

Amazon Threat Intelligence 在 MadPot 遥测数据中发现了一次可追溯至 Oct. 17, 2026 的 PHP2Shell 利用尝试，比 CVE-2026-109618 和 CVE-2026-109619 的公开披露早四天。该利用尝试源发自一个与商业匿名化网络相关联的 IP 地址。在漏洞仍处于禁披期时，来自匿名 IP 地址对蜜罐的定向攻击表明，此次活动由某个威胁行为者实施，但该行为者如何在披露前获得漏洞利用信息仍不清楚。

针对 PHP 的禁披窗口原定于 2026-10-21 1400 UTC 解除。禁披结束当天，Amazon Threat Intelligence 发现了多个针对该漏洞的概念验证利用代码，其中最早约在 2026-10-21 0200 UTC。随后，从 2026-10-21 0200 UTC 到 2026-10-21 0800 UTC，Amazon Threat Intelligence 又发现了来自其他匿名化基础设施、针对 MadPot 的 PHP2Shell 利用尝试。实际使用的载荷及所选的匿名化基础设施各不相同，这表明这些利用尝试出自多个攻击者。技术分析仍在进行，目前尚不清楚这些尝试中是否有任何一次能在真实系统中成功。

禁披窗口实际于 2026-10-21 1400 UTC 解除。禁披结束并发布补丁后，更多概念验证利用代码在数小时内出现，我们几乎立即看到它们被用于攻击我们的传感器。PHP2Shell 目前已在真实环境中遭到大范围利用。

这次事件带来的两点教训，适用范围远不只限于这一个漏洞：

1. 禁披机制只能保护防御方，直到有人发现同一个漏洞为止。协同披露仍是正确的模式。但防御方不应假定公开披露日期就是最早利用日期。对于 PHP2Shell，系统失陷可能早于安全公告。
2. 由于一些结构性原因，从补丁发布到可用利用代码出现的时间正在缩短。过去，我们观察到的大多数利用活动都发生在公开的概念验证利用代码发布之后。少数具备能力的攻击者会构建利用代码，而其余人则等待他们发布。攻击者对这种少数人的依赖正在减弱。AI 辅助分析降低了将补丁差异或公告转化为可用利用代码的成本。因此，一旦漏洞的技术细节被披露，更多攻击者就能在数小时甚至数分钟内采取行动。

对于安全负责人而言，这改变了几项工作假设：

1. 对于面向互联网的系统中的关键漏洞，应以小时为单位衡量补丁部署和缓解措施的时限。7-day or 30-day SLA 预设了一段已经不存在的延迟。
2. 调查应从已知的最早利用活动开始，而不是从披露日期开始。对于 PHP2Shell，至少应从 October 17^th 开始调查。
3. 应投入资源建设不依赖特定 CVE 特征码的检测能力。首次利用活动往往会发生在这些特征码出现之前。

AWS 部署了多层防护措施，以帮助保障客户安全。我们的内部威胁情报系统自动检测并限制了针对该漏洞的恶意扫描尝试。我们每分钟分析超过 200 billion 个事件，并整合来自 MadPot 蜜罐网络的威胁情报，以实时识别和阻止已知的利用尝试。我们的蜜罐系统使我们能够提前发现利用尝试，从而实现快速响应和威胁分析。

1. 立即升级到已修复的 PHP 版本。升级是同时彻底修复 CVE-2026-109618 和 CVE-2026-109619 的唯一完整补救措施。不存在仅通过配置即可完全解决这两个问题的变通方案。
2. 对于无法立即打补丁的 PHP 部署，请考虑阻止多部分文件上传，但在部署此措施前，先确定这会如何影响您的应用程序。
3. 查找表单上传中包含 PHP_SESSION_UPLOAD_PROGRESS 字符串的 POST 请求。
4. 检查 Web 服务器日志中的可疑活动。
5. 检查 Web 应用程序服务器上是否存在意外进程执行或文件修改。

已识别的 IP 地址包含共享的匿名化基础设施，并非此次威胁活动所独有。组织应调查任何涉及这些地址的观测结果，而不是直接进行屏蔽。

请参阅我们的博客文章 使用 AWS WAF 针对 PHP2Shell RCE 漏洞实施缓解措施（CVE-2026-109618 和 CVE-2026-109619），了解如何使用 AWS Web Application Firewall 在您打补丁期间帮助降低暴露风险。

如果您有任何问题，请在 AWS re:Post 上启动新主题，或联系 AWS Support。