亚马逊威胁情报（Amazon Threat Intelligence）在 MadPot 中识别出针对 PHP2Shell 的利用活动，且这些利用行为发生在该漏洞公开披露之前。团队通过 MadPot 的观测数据，捕获到攻击者在披露前投递的 PHP2Shell 相关请求，并据此还原了早期利用链与命令执行过程。
正文
Amazon Threat Intelligence 在 MadPot 遥测数据中发现了一起针对 PHP2Shell 的利用尝试，时间为 2026 年 10 月 17 日，比 CVE-2026-109618 和 CVE-2026-109619 公开披露早四天。该利用尝试来自一个与商业匿名网络关联的 IP 地址。在漏洞仍处于披露前禁运期（embargo）时，从匿名 IP 地址针对蜜罐发起攻击，说明这是威胁行为者所为，但目前尚不清楚该行为者是如何在披露前获得利用信息的。
PHP 的 embargo 窗口原定于 2026-10-21 1400 UTC 解除。在发布当天，Amazon Threat Intelligence 已发现多个针对该漏洞的概念验证（PoC）利用，最早约在 2026-10-21 0200 UTC。随后，从 2026-10-21 0200 UTC 到 2026-10-21 0800 UTC，又发现更多来自其他匿名基础设施、针对 MadPot 的 PHP2Shell 利用尝试。实际载荷和匿名基础设施的选择各不相同，说明背后是多个行为者。技术分析仍在进行，目前不清楚这些尝试在真实系统中是否会成功。
embargo 窗口实际解除时间是 2026-10-21 1400 UTC。禁运解除、补丁发布后，几小时内又出现了更多概念验证利用，我们几乎立刻看到它们被用于攻击我们的传感器。PHP2Shell 目前在野外被大规模利用。
这一事件带来的两点经验，其意义远不止这一个漏洞：
- embargo 只能在其他人发现同一个漏洞之前保护防御者。协调披露仍然是正确的模式，但防御者不应假定公开披露日期就是最早的利用日期。就 PHP2Shell 而言，系统遭到入侵的时间可能早于安全公告。
- 从补丁到可用利用的时间正在缩短，这是结构性原因造成的。过去，我们观察到的大多数利用都发生在公开的概念验证发布之后：少数有能力的行动者编写利用，其余人则等待他们。这种依赖正在减弱。AI 辅助分析让把补丁差异（patch diff）或安全公告转化成可用利用变得更加廉价。结果是一旦漏洞的技术细节披露，更多行为者能在数小时甚至数分钟内行动。
对安全负责人来说，这改变了以下几项工作假设：
- 对于面向互联网系统的关键漏洞，修补和缓解的时间线要以小时为单位衡量。7 天或 30 天的 SLA 假设了一种已不存在的延迟。
- 调查要从已知最早的利用开始，而不是从披露日期开始。就 PHP2Shell 而言，至少要从 10 月 17 日开始调查。
- 投资于不依赖特定 CVE 签名的检测。首次利用往往出现在这些签名存在之前。
AWS 如何帮助保护客户
AWS 部署了多层保护来帮助保护客户。我们的内部威胁情报系统自动检测到并限制了针对该漏洞的恶意扫描尝试。我们每分钟分析超过 2000 亿个事件，并整合来自 MadPot 蜜罐网络的威胁情报，以实时识别和阻止已知的利用尝试。蜜罐系统让我们能早期发现利用尝试，从而实现快速响应和威胁分析。
建议立即采取的措施
- 立即升级到已修复的 PHP 版本。升级是彻底修复 CVE-2026-109618 和 CVE-2026-109619 的唯一完整方法。目前没有仅通过配置就能完全解决这两个问题的变通办法。
- 对于无法立即修补的 PHP 部署，可考虑阻止 multipart（多部分）文件上传，但在部署前要先确定这对应用有何影响。
- 查找表单上传中带有 PHPSESSIONUPLOAD_PROGRESS 字符串的 POST 请求。
- 检查 Web 服务器日志中的可疑活动。
- 检查 Web 应用服务器上是否有意外的进程执行或文件修改。
入侵指标（IOCs）
| 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 |
上述 IP 地址包含共享的匿名基础设施，并非本次威胁活动所独有。组织应对涉及这些地址的任何观测进行调查，而不是直接封禁。
关于如何在修补期间使用 AWS Web Application Firewall 降低暴露面，请参阅我们的博客文章《使用 AWS WAF 应用 PHP2Shell RCE 漏洞（CVE-2026-109618 和 CVE-2026-109619）的缓解措施》。
评论
讨论气氛高度不信任厂商的安全叙事：多数人认为所谓“漏洞利用尝试”很可能只是扫描和探测，真正可用的利用代码仍未出现，同时集中批评亚马逊自家 Amazon Linux 与 bottlerocket 修补迟缓、PHP 团队在披露前保密期失职并向 Chainguard 甩锅；少数人则讽刺科技公司把漏洞当成公关竞赛。分歧主轴在于攻击是否已被真实大规模利用、利用尝试增多是否源自内线泄露或 Chainguard 镜像提前曝光，以及各家应为延迟修补负多大责任。
质疑“利用尝试”被夸大，扫描探测与真正利用需区分
- 不少评论认为，Cloudflare 和亚马逊提到的成千上万次“尝试”很可能只是日志中的探测，或僵尸网络把该漏洞加入扫描器规则后的噪音；GitHub 上虽出现大量仓促生成的尝试代码，但据观察并无真正能工作的利用代码。还有人要求厂商明确区分观察到的现象：是会导致崩溃的内存破坏，还是真正能执行代码的利用，否则亚马逊公告中的“利用尝试”无法判断实际风险。此前有文章指出该漏洞并不好用，还需配合本地文件包含问题。（认可度：较多人） > 我在服务器日志里只看到探测而非实际利用，僵尸网络只是把它加进了漏洞扫描器；据我所知 GitHub 上大量自动生成的尝试也都不能真正工作。（@VladVladikoff）
批评亚马逊自家补丁和镜像修复太慢，博文适得其反
- 多条评论指出，亚马逊至少从 10 月 17 日就知道该漏洞并称其被积极利用，却未遵守漏洞披露前的保密时间线，Amazon Linux 更新包在官方补丁发布 18 小时后才提供，bottlerocket 的 AMI 也迟迟没有 emSign 吊销；其博客本想展示监测能力，结果反而暴露亚马逊把客户置于风险中，并未传达出 AWS 想要的信息。（认可度：较多人） > 亚马逊在补丁发布前数日就知道漏洞并被积极利用，却仍在补丁发布 18 小时后，才提供 Amazon Linux 的更新包。（@Tomdarkness）
指责 PHP 团队向 Chainguard 甩锅，并怀疑内部人员泄露
- 评论认为，如果 10 月 17 日前后就已有探测或利用，PHP 团队公开责怪 Chainguard 破坏保密期就很难成立；PHP 团队被指用“我们是志愿者”“请给我们资金”“多年前就知道但为了先做功能而不是安全修复才没有概念验证代码”等说法转移责任。更反直觉的是，攻击似乎是在研究人员和 PHP 内部人士被通知后才开始，令人怀疑并非外部攻击者恰好独立发现同一利用链，而是保密期内的信息被分享或出售，PHP Foundation 需要解释为何在两个多月里毫无作为。（认可度：较多人） > PHP 团队把“Chainguard 破坏保密期”“请给我们资金”“我们只是志愿者”以及“为了先做功能而不是安全修复才没有概念验证代码”都说成理由，其实全是在推卸责任。（@andyvanosdale）
呼吁用精确时间线判断 Chainguard 镜像与泄漏的关系
- 有评论指出，Cloudflare 提到的“公告前数千次尝试”若按公告中的 14:00 UTC 计算，其实发生在 Chainguard 发布镜像几小时之后；因此需要精确时间线，才能判断攻击者是独立发现、看到 Chainguard 构建后理解问题并写出利用，还是保密期内的内部信息导致利用提前出现。也有人整理了覆盖披露前保密期、泄漏与亚马逊报告的完整时间线供核对。（认可度：少数人） > 如果按公告里的 14:00 UTC 算，那是在 Chainguard 发布镜像几小时之后；需要更精确的时间线才能理解人们是否看到 Chainguard 的构建、从中理解问题并写出利用。（@hyperpape）
讽刺厂商攀比谁先发现漏洞却都不修补
- 有评论用小学生攀比自行车的类比嘲讽整个行业：各家其实都骑着同一辆存在巨大漏洞却没人去修的自行车，却争着吹嘘谁先看到、谁先识别；真正该做的不是发公关稿，而是尽快打补丁、让客户得到保护。这条代表了不少人对厂商安全公关的厌倦。（认可度：少数人） > 这些科技公司像小学生攀比谁的自行车更好，其实大家骑的是同一辆有巨大漏洞却没人去修的自行车，却还在吹嘘谁先看到、谁先识别。（@ActionHank）
有价值的补充
- 有评论追问 CrowdSec 到底观测到什么数据；由于 PHP 安装基数很大，这类 PHP 利用警报理应进入快速告警通道。
- Cloudflare 公布的尝试量增长（公告前数千、公告后数万、目前数百万）同样只反映“尝试”，没有给出成功入侵或真实代码执行的证据。
- @makmanalp 整理了一份覆盖披露前保密期、泄漏以及亚马逊报告的完整时间线，可用于自行核对上述争议。