PHP2Shell漏洞：封禁期前已被利用
Amazon identifies Oct 17 PHP2Shell exploitation prior to public disclosure
Amazon Threat Intelligence在MadPot蜜罐中监测到，早在CVE-2026-109618和CVE-2026-109619公开披露前四天，就有攻击者利用PHP2Shell漏洞发起攻击。这次事件揭示了一个严峻的现实：协调披露机制下的封禁期并不能完全阻止漏洞被提前利用。随着AI辅助分析降低了漏洞利用门槛，从补丁发布到可用Exploit出现的时间窗口正在急剧缩短。安全团队必须调整策略，将关键系统的修复SLA从数天缩短至数小时，并基于最早已知利用时间而非披露日期启动调查，同时部署不依赖特定CVE签名的检测机制。
对于互联网暴露系统的关键漏洞，补丁和缓解措施的时限应以小时计，而非天。
HN 评论区
88- andyvanosdale
如果该漏洞在 10 月 17 日就已经被探测或利用，那么 PHP 团队在公开声明中指责 Chainguard 的做法就显得非常可疑。
本质上，PHP 团队正在推卸责任，逃避他们在这一团乱麻中应尽的义务。"Chainguard 违反了禁言期"、"请给我们资金支持"、"我们只是志愿者"、"我们几年前就知道这个问题但没有 POC，因为我们想发布功能而不是安全修复"。所有这些不过都是推脱之词。
这场闹剧让我确信，我绝不会在任何我参与的项目中使用 PHP。PHP 团队彻底搞砸了，而且他们正拼命向四面八方推卸责任。
- hyperpape
Matthew Prince 也发了一条推文，称 Cloudflare 在公告发布前就看到了数千次尝试，https://x.com/eastdakota/status/2113079352682570051，公告发布后增加到数万次，而现在已达到数百万次。
不幸的是，如果你把公告中的时间理解为 UTC 14:00，那已经是 Chainguard 发布镜像后的几个小时了。我不确定人们是否有可能看到了 Chainguard 的构建版本，从中理解了问题并构建了利用工具，但一个精确的时间线将有助于更好地理解情况。
- VladVladikoff
我在服务器日志中看到了针对该漏洞的探测，但没有看到实际利用。我认为僵尸网络只是把它加到了漏洞扫描器中，但我至今还没见过任何实际可用的利用案例。GitHub 上有数百个看似拼凑的尝试，但据我所知没有一个能真正奏效。很希望有人能证明我错了。
另外，亚马逊的这篇帖子令人尴尬。他们从 17 号就知道这个问题，却未能遵守禁言期时间表来修复 Amazon Linux（他们的补丁原定于今天 10 月 22 日发布）。
- menomatter
他们是否区分了尝试次数和成功入侵次数？我想搞清楚这个漏洞是否容易利用。昨天这里有一篇文章认为该漏洞并不容易利用，需要 LFI 条件。
- decidu0us9034
"利用尝试"这个说法缺乏明确性。漏洞扫描机器人一直在产生海量的怪异流量。是否有人拥有能在真实异构环境中运行、而不仅仅是实验室环境下的便携式可靠利用工具？这甚至可行吗？看起来似乎不可行。LLM 可以自动化实用利用工具的开发，但并不能消除所有使其从一开始就难以实现的约束。感觉很多人忽略了这一点，我不知道。