亚马逊将PHP2Shell利用追溯到10月17日，比CVE-2026-109618披露早四天
亚马逊威胁情报报告称，其于2026年10月17日观察到一次PHP2Shell利用尝试，比CVE-2026-109618和CVE-2026-109619于2026年10月21日公开披露早四天。这一发现意味着防御者应从最早已知的利用时间而非公告日期来衡量其响应窗口，并且面向互联网的关键补丁应被视为小时级问题，而非7天或30天的问题。
亚马逊实际检测到了什么
亚马逊威胁情报识别到一次针对其MadPot蜜罐网络的PHP2Shell利用尝试，日期为2026年10月17日，比CVE-2026-109618和CVE-2026-109619公开披露早四天。该尝试来自一个与商业匿名化网络关联的IP地址。
亚马逊表示，由于当时该漏洞仍处于保密期，从匿名IP地址针对蜜罐表明该活动由威胁行为者实施。亚马逊还表示，尚不清楚该行为者如何在披露前获取漏洞利用信息。公司指出，尚不清楚观察到的任何尝试是否会在真实系统上成功。
MadPot是亚马逊的蜜罐系统。亚马逊表示，其每分钟分析超过2000亿个事件，并整合来自MadPot蜜罐网络的威胁情报，以实时识别和阻止已知的利用尝试。
PHP2Shell利用时间线
PHP保密窗口原定于2026-10-21 14:00 UTC解除。利用活动在该边界两侧聚集。
| 时间（UTC） | 事件 |
|---|---|
| 2026-10-17 | 首次针对MadPot的PHP2Shell利用尝试，来自103.216.220.92 |
| 2026-10-21 ~0200 | 在保密解除前识别到该漏洞的最早概念验证利用 |
| 2026-10-21 0200-0800 | 来自额外匿名基础设施的更多PHP2Shell利用尝试，载荷各异 |
| 2026-10-21 1400 | 保密解除并发布补丁 |
| 2026-10-21 1400之后 | 数小时内出现更多概念验证利用，并几乎立即被用于针对亚马逊传感器 |
亚马逊将载荷和匿名基础设施的选择描述为多样化，这表明涉及多个行为者而非单一行为者。公司表示，PHP2Shell目前正在野外被广泛利用。
保密仅在其他人在同一时间发现相同漏洞前保护防御者
亚马逊陈述的第一条经验是，协调披露仍然是正确的模式，但防御者不应假设公开披露日期是最早的利用日期。对于PHP2Shell，入侵可能早于公告。10月17日的蜜罐命中是亚马逊为该主张提供的具体证据。
补丁到利用的时间窗口因结构性原因正在缩短
亚马逊的第二条经验是，从补丁到可用利用的时间正在缩短。亚马逊表示，过去其观察到的大多数利用发生在公开概念验证发布之后：少数有能力的行为者构建利用，其他人等待他们。亚马逊表示，这种依赖关系正在减弱，因为AI辅助分析使得将补丁差异或公告转化为可用利用的成本更低。因此，一旦漏洞的技术细节被披露，更多行为者可以在数小时甚至数分钟内采取行动。
安全领导者应改变什么
亚马逊列出了三项工作假设，称此事件使其失效：
- 对于面向互联网系统中的关键漏洞，以小时为单位衡量补丁和缓解时间线。7天或30天的SLA假设了不再存在的延迟。
- 从最早已知的利用时间而非披露日期开始调查。对于PHP2Shell，亚马逊表示至少应从2026年10月17日开始调查。
- 投资于不依赖特定CVE签名的检测，因为首次利用通常发生在这些签名存在之前。
针对PHP2Shell的推荐修复措施
亚马逊列出了五项行动：
- 立即升级到修复后的PHP版本。亚马逊表示，升级是CVE-2026-109618和CVE-2026-109619的唯完整修复措施，且没有仅配置的变通方案能完全解决这两个问题。
- 考虑在无法立即修补的PHP部署中阻止多部分文件上传，在确定这将如何影响应用程序之后。
- 查找表单上传中包含PHP_SESSION_UPLOAD_PROGRESS字符串的POST请求。
- 审查Web服务器日志以查找可疑活动。
- 检查Web应用服务器上是否有意外进程执行或文件修改。
AWS还发布了一篇配套文章，介绍在修补期间使用AWS WAF对PHP2Shell RCE漏洞应用缓解措施。
亚马逊观察到的IP地址
亚马逊发布了与该活动相关的六个IP地址。它明确表示，这些地址包括共享匿名基础设施，并非该威胁活动独有，组织应调查涉及这些地址的观察结果，而非直接阻止它们。
| IP地址 | 观察日期 |
|---|---|
| 103.216.220.92 | 10/17/2026 |
| 31.223.184.166 | 10/21/2026 |
| 37.19.200.5 | 10/21/2026 |
| 134.209.159.64 | 10/21/2026 |
| 103.114.163.188 | 10/21/2026 |
| 95.217.98.37 | 10/21/2026 |
Hacker News讨论补充了什么
Hacker News上关于该报告的讨论线程（197分，55条评论）主要围绕两个问题：亚马逊描述的利用是否实际成功，以及为什么亚马逊自己的Linux补丁滞后于其宣传的披露。
观察到的任何活动是否构成实际入侵？
评论者询问亚马逊是否区分利用尝试和成功渗透。一位评论者描述只看到探测而非可用利用：
我在服务器日志中看到过探测，但没有看到实际利用。我认为僵尸网络将其添加到漏洞扫描器中，但我尚未看到任何实际可用利用的例子。GitHub上有数百个vibe coded尝试，但据我所知没有一个有效。
另一位评论者询问该利用是否易于使用，指出另一篇文章认为该利用并不容易，需要本地文件包含（LFI）。亚马逊本身表示尚不清楚任何尝试是否会在真实系统上成功，因此源材料并未解决此问题。
亚马逊自身的补丁时间线受到批评
几位评论者认为该博客文章削弱了自身信息，因为亚马逊Linux软件包滞后于补丁发布。一位评论者指出了amazonlinux/amazon-linux-2023仓库上的一个GitHub问题：
所以亚马逊在补丁发布前几天就知道此漏洞且其正被积极利用。尽管如此，他们仍在补丁发布后18小时才提供其亚马逊Linux软件包的更新版本？
另一位评论者表示，亚马逊的亚马逊Linux补丁原定于10月22日发布，并因此称该文章令人尴尬。这些是评论者关于亚马逊Linux发布时间的说法；AWS博客文章本身并未讨论亚马逊Linux软件包的可用性。
与其他供应商遥测的重叠
一位评论者引用了Matthew Prince的一条推文，称Cloudflare在公告前看到数千次尝试，公告后数万次，到推文发布时数百万次。同一评论者指出了时间线模糊性：如果公告指的是14:00 UTC，那比Chainguard发布其镜像晚几个小时，精确的时间线将有助于确定行为者是否从这些构建中衍生出利用。
对PHP项目披露处理的批评
部分讨论质疑利用如何能在研究人员和PHP内部人员收到私人通知后如此接近开始。一位评论者写道：
攻击在漏洞被研究人员发现和PHP内部人员通知后开始，这很能说明问题。谁真的相信恶意实体在同一时间完全独立地发现了完全相同的利用链？
另一位评论者对PHP团队的公开沟通更为严厉，称其回应将责任推给Chainguard和资金问题。第三位评论者将批评概括为更广泛的抱怨，即供应商在竞争谁先检测到漏洞，而非为客户提供修复。
仍未解决的问题
源材料留下了几个未解问题。亚马逊未说明披露前行为者如何获得利用细节，任何尝试是否成功，或哪些特定行为者背后是多样化的载荷。评论线程提出了10月17日活动可能是披露前武器化的可能性，但亚马逊和评论者均未提供证据确立该链条。然而，亚马逊的操作指导并不依赖于这些答案：在数小时内修补面向互联网的PHP部署，从最早已知的利用日期开始取证时间线，并依赖行为检测而非特定CVE签名。