一句话，一夜，他自己也找到了

10 月 21 日夜里，两件事先后落地，把当天下午那场披露里最缺的一块补上了：22:36 UTC，AWS 说它自己的蜜罐在 10 月 17 日就见到过针对这两个漏洞的利用尝试，比公开披露早四天；二十六分钟后，Chainguard 的 CEO 接受采访，承认镜像是提前发的，并给出了理由。12

此前的解释是「有人单方面破了禁运」。这两条新事实把问题挪到了另一个位置：破没破，取决于用哪一条规则量。而那条规则里，写着两个身份。

Chainguard 的 CEO Dan Lorenc 对 The Register 说，他不否认时间线。周五，一位最早发现漏洞的研究者告诉他们「PHP 有事」；当天夜里，他和团队用自家的 harness 与一个前沿模型，加上一句「find bad vulnerabilities in PHP」，独立找到了同一批内存破坏漏洞。周六他们被完整告知，确认自己的部分发现与原始报告对得上，并开始帮忙测试补丁。2

三天后，也就是 10 月 21 日 07:41 UTC，Chainguard 发出了带修复的镜像，比协调好的 14:00 早六小时十九分，而且对所有人开放，不只是付费用户。23

PHP 基金会的定性是「单方面解除禁运」，并写下后果：在任何其他 PHP 用户还在等的时候，攻击者已经可以研究二进制形式的修复。3 Lorenc 的说法是另一句：「It's coordinated vulnerability disclosure, unless there's evidence of active exploits in the wild.」他在自己的帖子里写得更具体：这一步是「按照协调披露流程中关于『出现利用之后如何发布』的指南」做的。24

把这两句话放回文本里，会发现争执的根不在事实，在主语。

FIRST 的《多方漏洞协调与披露指南》给「发现者」的定义只有一句：识别出某个产品或服务中潜在漏洞的个人或组织——不限厂商。同一份文件里，提前公开写在这一侧：「已知的在野利用可能促使发现者在修复之前公开披露」。协调者是另一条：「出现对该漏洞的在野利用，并且协调者选择公开。」5

CERT 的协调披露指南更直接一点，也更含糊：「当事件证明有必要时，打破先前的披露时间表约定有时是必要的。」它把「出现在野利用」列为提前发布的理由之一，却没有写谁来决定，只补了一句「发现者、报告者与厂商各自都可能有合理但相互冲突的看法」，必要时可以找中立第三方。6

两份文本里都没有分发方。它拿到的是补丁，义务是等到协调时刻——这不是某条写下来的规则，而是这套流程的默认分工。PHP 自己在 10 月 20 日 19:30 的预告里给出的是另一种写法：把提前发布的权利留给自己，「We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.」7

于是同一件事有了两种读法。PHP 读的是：提前发布的决定权在维护者，别人做了就是破约。Lorenc 读的是：这条例外属于流程里的参与者，而我恰好也是一个发现者。两边都能在自己的文本里找到依据，因为没有一份文本写过：当发现者与分发方是同一个人时，哪一个身份优先。

AWS 的这条披露，让「提前」这个词又向前挪了一段。它在 MadPot 蜜罐的遥测里识别到一次针对这两个漏洞的利用尝试，日期是 10 月 17 日，来自一个与商业匿名化网络相关的 IP。AWS 的原话留着分寸：从一个匿名地址去打蜜罐，说明这「很可能」是有行为者在做，但它不清楚对方在公开之前是怎么拿到利用信息的。1

这个日期比 CVE 编号在论坛上流传（10 月 20 日 15:00 UTC）还早三天左右。也就是说，把当晚的混乱全部归因于「编号外流」，并不完整：在任何人开始传之前，已经有人在试了。13

发布当天也有记录。AWS 说，10 月 21 日 02:00 到 08:00 之间，它又从另外几处匿名基础设施上看到多起尝试，载荷与匿名方式各不相同，判断是多个行动者；披露之后数小时内又出现更多 PoC，并「几乎立刻」被用在自家传感器上。它给出的 IOC 表里，10 月 17 日那一行只有一个地址：103.216.220.92。1

AWS 从这件事里抽出的第一条教训，正好是这次争执的注脚：「禁运只在别人还没找到同一个 bug 之前保护防守方。」第二条更直接：AI 辅助分析让「把补丁 diff 或公告变成可用利用」变便宜了，因此能在数小时甚至数分钟内动手的人变多了。1

回到那次决定本身。按 Lorenc 的叙述，触发点是周二夜里的流言变多，以及「流程里的几家安全厂商确认看到了在野利用」；他开了一个视频会，然后决定发镜像，并立刻通知了披露频道。4

公开侧当时能查到的是什么？是一段误发的 PoC 视频，和几个错误的数字。PHP 基金会记下的顺序是：10 月 20 日 15:00 编号外流并附带错误的 10.0 分，19:30 预告提前，20:00 前后 Calif 误发 PoC 视频。3

换句话说，「出现在野利用」这个条件，当时只在私下的电话与聊天里成立。公开的第一份相关表述出现在 13:53 UTC，Fastly 写「有公开前已在野攻击的证据」，但没有给日期；第一份带日期的一手记录出现在 22:36 UTC，也就是 AWS 的 10 月 17 日。从 07:41 到 22:36，隔了 14 小时 55 分。18

所以这件事最难受的地方在于：他没有赌错，但那一刻他无法证明自己没赌。例外是真的，程序是空的——一条以「证据」为触发条件的规则，在需要它的那几个小时里，证据恰好只存在于不会被公开的地方。

如果把这件事只看成一家公司的判断失误，就会漏掉它为什么会发生。

发现这件事的门槛，已经降到一句话。Lorenc 的描述是「只要被告知某个软件里有漏洞——哪怕是 PHP 这么大的东西——就足够把它找出来」，他补了一句「周五我自己就是这么做的，没有任何别的信息」。2 PHP 基金会那边给出的数字方向一致：7 月 1 日以来发布了 15 个 CVE，处理了一百多份最终被判定为无效、重复或无法复现的报告。3

这直接动摇了禁运的前提。禁运假设知道的人是一个可控的小集合：维护者、报告者、协调者、分发方。现在，任何一个拿到补丁的分发方，都可能在当晚变成第二个发现者——不是因为它拿到了补丁，而是因为「被告知有漏洞」本身就足够。身份开始重叠，而规则没有为重叠准备条款。

Chainguard 自己在 7 月的一篇文章里写过这个前提：「发现这些信息的人掌握着全部信息，我无法规定他们的条件。」那篇讲的是它自己的漏洞情报生意，语境不同，但这句话现在读起来像是另一个意思：当发现的人变多，就没有人再掌握全部信息。9

这件事影响的不只是跑 PHP 的网站。任何提前拿到补丁的一方——发行版、镜像商、托管平台、企业内部的补丁通道——都在这条链上；任何把值守与沟通按「披露日」安排的团队，也在这条链上。AWS 给的三条改法都值得原样搬进流程，因为它们把单位从「天」换成了「小时」。1

第一，面向公网的关键系统，补丁与缓解的时间线按小时计；7 天与 30 天的 SLA，假设的那个延迟已经不存在了。

第二，调查从已知的最早利用开始，而不是从披露日开始。这一次是 10 月 17 日。这条对日志的要求很具体：如果你的热存储只留七天，而披露日距最早利用已有四天，再加上发现与上报的延迟，你很可能在开始查之前就已经丢了窗口。

第三，检测不要依赖某个 CVE 的签名。第一次尝试发生在签名出现之前。AWS 给的可操作项包括：拦截 multipart 上传（先评估对应用的影响）、在表单上传里找带 PHP_SESSION_UPLOAD_PROGRESS 的 POST 请求、以及查 Web 服务器上的异常进程执行与文件改动。

第四行要自己写：把身份冲突的裁决写进流程。谁可以在「有在野利用证据」时提前发布；证据门槛是什么（第一方遥测、第三方报告，还是一段视频）；由谁认定；通知谁；认定之后多久内公开。这四样写下来，下一次的 Lorenc 就不必在电话里做判断，PHP 基金会也不必在第二天用一篇博文来定性。

对做模型与安全工具的团队，还有一层：你们卖的是「找到」。当找到变得便宜，客户卡住的地方会从「找不找得到」变成「来不来得及修」——PHP 基金会的说法是，AI 帮忙验证报告、把同一根因的报告归组，「但每一次判断和每一个补丁都由人做」。这句话决定了产品的边界：能加速判断与修补的东西有价值，只加速发现的东西，会把压力全部推给下游。3

能确定的是：镜像在 07:41 发出，比协调时刻早六小时十九分；Lorenc 承认这个时间是提前的，并给出了理由；PHP 基金会把它定性为单方面解除禁运；AWS 在 22:36 公布了 10 月 17 日的蜜罐记录；两份通行指南都把提前公开的权利写在发现者与协调者名下，没有写给分发方。

不能确定的也有几块。

10 月 17 日目前只有 AWS 一方的一手遥测，而且它用的词是「尝试」，并写明不清楚这些尝试在真实系统上会不会成功。它也没有解释对方是怎么提前知道的——这可能是一次泄露，可能是独立发现，也可能只是一次误报。1

两位当事人的叙述有一处对不上：Lorenc 说「周一消息开始外流」，PHP 基金会记的是周二 15:00。发布时刻倒是对得上——他写「周二深夜（美东）」，基金会记 07:41 UTC，那是美东凌晨三点四十一。34

受影响范围仍然没有数字。没有一方公布有多少组织被攻破，公开记录里能看到的还是一串蜜罐 IP 与几条 PoC 仓库；AWS 自己也提醒，那些地址属于共享的匿名化基础设施，应当去查自己的日志，而不是直接封掉。

至于「谁对谁错」，这个问题可能问错了。规则没有写的那一格，不会因为争论而被填上——它只会等到下一次，由另一个手里同时握着两个身份的人，再填一次。