AREX Feed Article
AWS 称蜜罐在 PHP2Shell 公开披露前四天记录到利用尝试，并判定漏洞已被广泛利用
2026 年 10 月 21 日 14:00 UTC，PHP 基金会解除漏洞禁运，CVE-2026-109618 与 CVE-2026-109619 的补丁对外发布。当天 22:36 UTC，Amazon Threat Intelligence 在博客中说，它在 MadPot 蜜罐遥测中识别到一条更早的记录：10 月 17 日已有人投递针对这两个漏洞的利用尝试，比公开披露早四天（，2026-10-21T22:36Z）。
PHP 支撑着约 70% 的网站，这两个漏洞合称 PHP2Shell，被 PHP 基金会定为 critical 级并当日发布紧急补丁（，2026-10-21）。AWS 据此提醒，公开披露日不能当作最早的利用日。
10 月 17 日的那条蜜罐记录
AWS 说，这次尝试来自一个与「商业匿名化网络」关联的 IP 地址，也就是代理网络或 VPN 一类的基础设施。针对禁运期内从匿名地址打向蜜罐的行为，AWS 首席信息安全官 CJ Moses 在博文中写道，这「暗示该活动是由威胁行为者实施的」，但他同时写明，仍不清楚该行为者在披露前如何获得利用信息（，2026-10-22T02:24Z）。
公开的 IOC（失陷指标）表把这条记录钉在具体地址上：103.216.220.92，观测日期 10/17/2026。其余五个地址——31.223.184.166、37.19.200.5、134.209.159.64、103.114.163.188、95.217.98.37——观测日期都是 10 月 21 日。AWS 提醒这些地址属于共享的匿名化基础设施，并不专供本次活动，企业应当拿它们去检索自己的日志，而不是简单拉黑。
WIRED 补充了发现的经过：这条 10 月 17 日的记录，是 AWS 分析师在 10 月 21 日回看蜜罐历史活动时才看到的。
解禁前 12 小时，PoC 已经出现
AWS 的日志里还有第二个时间点。10 月 21 日 02:00 UTC 前后，AWS 识别到多个 PoC（概念验证利用代码），比禁运解除早约 12 小时。02:00 到 08:00 之间，更多利用尝试从不同的匿名基础设施打向 MadPot，载荷内容和匿名化服务的选择都不一样，AWS 据此判断参与者不止一个。禁运一解除，新的 PoC 在数小时内继续出现，AWS 的传感器「几乎立刻」就看到它们被用于攻击。
Cloudflare 在同一时段提供了另一种网络侧观测。公司博客说，针对 PHP2Shell 的 WAF（Web 应用防火墙）防护从 10 月初起开发部署，并在公开披露前约 9 小时上线；10 月 21 日 03:02 UTC 起，使用免费或付费 WAF 的客户默认受到保护。Cloudflare 还表示，它通过跟踪规则命中量、对照规则逻辑，观察到攻击者在改动载荷以绕过防护（，2026-10-21T13:56Z）。
次日，Cloudflare CEO Matthew Prince 给出了量级：在漏洞公开公布前的 10 个小时里，Cloudflare 全网看到「数千次」利用尝试；公布后 45 分钟升到数万次，两小时内到数十万次，发帖时已达数百万次（，2026-10-22T01:25Z）。这些数字统计的是利用尝试次数；Prince 没有说明其中多少载荷有效、有多少打入了目标。
「广泛利用」与「能否打通」是两件事
AWS 在同一篇分析里先写下保留：技术分析仍在进行，不清楚这些尝试是否能在真实系统上成功；随后给出结论——「PHP2Shell 现已在野被广泛利用」。结论与保留并列，划定了新证据的边界：蜜罐和 Cloudflare 的网络记录的是有针对性的探测与投递，从这些观测里看不到已经确认的失陷。
安全研究者 Marcus Hutchins 当晚从利用链一侧提出了保留。他说，这条 RCE（远程代码执行）需要取得通常受 ASLR（地址空间布局随机化）保护的内存地址；网上流传的 PoC 多数是「完全不可用的 AI slop」；至少有一个可用的非垃圾利用在传播，但依赖暴力破解绕过 ASLR，「影响并不特别大」；关于在野利用的传闻零散，他预计未来几周才会出现大规模利用（，2026-10-21T23:19Z）。他还在帖文开头注明，以上是他「目前掌握的信息」。
两种说法统计的对象不同：一边数的是请求，一边评的是利用链的可靠性。
除了升级，没有别的完整修复
AWS 的处置建议很直接：升级到修复版本是两个漏洞唯一完整的修复方式，不存在只改配置就能同时覆盖两者的方案。对暂时无法升级的 PHP 部署，它建议考虑拦截 multipart（多部分表单）文件上传，但部署前要先确认对应用的影响；同时检查表单上传中带 PHP_SESSION_UPLOAD_PROGRESS 字符串的 POST 请求、Web 服务器日志里的异常活动，以及应用服务器上意外的进程执行或文件修改。
AWS 从这次事件总结的两条经验针对流程，而非某一个 CVE。第一，禁运只在别人也发现同一个 bug 之前保护防守方，公开披露日不等于最早利用日，排查 PHP2Shell 至少应从 10 月 17 日查起。第二，「补丁到可用利用」的窗口在结构性缩短：AI 辅助分析让把补丁 diff（代码差异）或公告转成可用利用的成本变低，更多行为者能在技术细节公开后数小时甚至数分钟内动手。它据此建议，对面向互联网系统的关键漏洞按小时而不是按天计算修复窗口，并投入不依赖特定 CVE 签名的检测。
AWS 把排查起点定在 10 月 17 日，并说技术分析仍在进行。这些尝试里有多少真的成功，目前没有结论。