The 90-day disclosure policy is dead

90天漏洞披露政策已死

2026-05-09 :: [Updated :: 2026-05-09] Himanshu Anand :: 14 min read (2846 words) 2026年5月9日 :: [更新于 :: 2026年5月9日] Himanshu Anand :: 14分钟阅读 (2846字)

TLDR

摘要

The 90 day responsible disclosure window was built for a world where bug finders were rare and exploit development was slow. That world is gone. LLMs have compressed both timelines to near-zero. I have seen it first hand, and so has everyone else paying attention. This post lays out why the old model is broken, with real stories, and makes one ask to the industry: treat every critical security issue as P0 and patch it immediately. Not tomorrow. Not next sprint. Now. 90天的负责任披露窗口期是为那个“漏洞发现者稀少且漏洞利用开发缓慢”的时代而建立的。那个时代已经结束了。大语言模型（LLM）将这两个时间维度都压缩到了近乎于零。我亲眼见证了这一点，所有关注此领域的人也都看到了。这篇文章将通过真实案例阐述为何旧模式已经失效，并向行业提出一个诉求：将每一个关键安全问题都视为 P0 级（最高优先级），并立即修复。不是明天，不是下一个冲刺周期，而是现在。

I have been doing security work for a while now, and the last 12 months feel different. Not in a “AI is going to take over the world” way. In a much more boring, much more practical way. The tools we use, the tools attackers use, and the tools researchers use to find bugs have all gotten smarter at roughly the same speed. And that has quietly killed some of the fundamental assumptions the security industry has been running on for over a decade. Let me walk you through what I mean, with stories. 我从事安全工作已经有一段时间了，但过去12个月的感觉截然不同。这并非那种“人工智能将接管世界”的科幻感，而是一种更枯燥、更务实的感受。我们使用的工具、攻击者使用的工具，以及研究人员用来发现漏洞的工具，都在以大致相同的速度变得更聪明。这悄然打破了安全行业十多年来一直依赖的一些基本假设。让我通过几个故事来向你说明我的意思。

The old world (rest in peace)

旧世界（安息吧）

Pretend it is 2019. You find a critical bug. You write up a report. You send it to the vendor. The vendor takes a few days to triage, a couple of weeks to fix, maybe a month to roll out. If you follow Google Project Zero style disclosure, you give them 90 days before going public. During those 90 days, you assume: 假设现在是2019年。你发现了一个关键漏洞。你写了一份报告，发送给厂商。厂商花几天时间进行分类，几周时间修复，可能一个月后发布更新。如果你遵循 Google Project Zero 式的披露流程，你会给他们90天的宽限期，然后再公开。在这90天里，你会假设：

• You are probably the only person who found this bug
• 你可能是唯一发现这个漏洞的人
• Even if someone else finds it, they will take their own time
• 即使其他人发现了，他们也会按自己的节奏处理
• The vendor has a comfortable head start on writing the patch
• 厂商有足够充裕的时间来编写补丁
• After the patch lands, attackers need days or weeks to reverse engineer it into a working exploit
• 补丁发布后，攻击者需要几天甚至几周的时间进行逆向工程，才能开发出可用的漏洞利用程序

Every single one of these assumptions is now wrong. 现在，这些假设中的每一条都已经不再成立了。

Story 1: 10 people, 1 bug, 6 weeks

案例一：10个人，1个漏洞，6周时间

In late April, I reported a pretty bad bug to a company. I am keeping the details vague because the issue is still not patched, but the shape of it goes like this: an attacker can buy anything from the website, send back their own crafted response to the server, and because there is no signature verification on the response, the server happily accepts it. Buy a $5000 item for $0. Mark your purchase as completed without paying. Critical, easy to exploit, very bad day for the company. 4月下旬，我向一家公司报告了一个相当严重的漏洞。为了保密，我隐去了细节，因为该问题尚未修复，但其逻辑大致如下：攻击者可以从网站购买任何商品，向服务器发送自己精心构造的响应，由于服务器没有对响应进行签名验证，它会欣然接受。你可以用0美元买到5000美元的商品，并在不付款的情况下将订单标记为已完成。这是一个关键的、易于利用的漏洞，对公司来说简直是灾难。

Cool. I write it up, I send it in, I feel good about myself for about 10 minutes. Then the triage team comes back and says “yeah we know, first reported in March. You are reporter number eleven.” Eleven Freaking people found the same critical bug in roughly six weeks. 很好。我写好报告，提交上去，自我感觉良好地过了大约10分钟。然后分类团队回复说：“是的，我们知道了，3月份就有人报告过了。你是第11位报告者。”在短短六周内，竟然有11个人发现了同一个关键漏洞。

A friend from BlueWater CTF had flagged this pattern months ago, that LLM-assisted hunters were converging on the same bugs almost simultaneously, across totally unrelated reporters using totally unrelated workflows. And it is not just me noticing this. @d0rsky, who works on the triage side, posted this: “Once a new vulnerability is discovered - especially via some LLM prompt/skills/automation, we start getting a wave of duplicate reports within days. Same root cause, slightly different wording. […] What concerns me more, is, if researchers can replicate these findings so quickly, what’s stopping blackhats from doing the same before the issue is fixed? Feels like the window between ‘first discovery’ and ‘mass awareness’ is getting dangerously short.” BlueWater CTF的一位朋友几个月前就指出了这种模式：在LLM的辅助下，漏洞猎人们几乎同时锁定了相同的漏洞，尽管这些报告者之间毫无关联，使用的工作流也完全不同。不仅我注意到了这一点，从事漏洞分类工作的 @d0rsky 也发帖称：“一旦发现新漏洞——特别是通过某些LLM提示词、技能或自动化手段——我们几天内就会收到一波重复报告。根本原因相同，只是措辞略有不同。[…] 更让我担心的是，如果研究人员能如此迅速地复现这些发现，那么在问题修复之前，又有什么能阻止黑客做同样的事情呢？感觉‘首次发现’到‘大规模知晓’之间的窗口期正在变得危险地短暂。”

Exactly. The triage teams are seeing it too. This is not a researcher’s paranoia. It is a pattern. At first I thought, okay, same tools, same prompts, makes sense. But then I did the uncomfortable math. If 10 people reported the bug, how many found it and did not report it? The same LLM that helped 10 honest researchers is also available to everyone else. It does not check your intentions at the door. 没错。分类团队也看到了这一点。这并非研究人员的偏执，而是一种模式。起初我以为，好吧，同样的工具，同样的提示词，这很合理。但随后我算了一笔令人不安的账：如果10个人报告了这个漏洞，那么有多少人发现了它却没有报告？那个帮助了10位诚实研究人员的LLM，同样也对其他人开放。它在提供服务时并不会审查你的意图。

Out of those 10 reporters, only 1 gets the CVE credit. Only 1 gets the bounty. What about the other 9? How many get frustrated? How many decide to sell it instead of wait? And the people who never reported it at all — they are not sitting on a 90 day clock. They are not sitting on any clock. The 90 day window is not protecting users. It is giving everyone who already has the bug a 90 day head start. 在这10位报告者中，只有1人能获得CVE编号，只有1人能拿到赏金。那另外9个人呢？有多少人会感到沮丧？有多少人会决定将其出售而不是等待？而那些根本没有报告的人——他们并不受90天披露期限的约束。他们不受任何时间限制。90天的窗口期并没有保护用户，它反而给了所有已经掌握该漏洞的人90天的领先优势。

Story 2: 30 minutes from patch to exploit

案例二：从补丁发布到漏洞利用仅需30分钟

Recently, React patched a bunch of security issues (CVE-2026-23870, CVE-2026-44575, CVE-2026-44579, CVE-2026-44574, CVE-2026-44578) and wrote a public blog post about it. Standard practice. Show your work, explain the fix, give the community a heads up. I read the post out of curiosity. Then I thought, let me see how hard it would be to turn this patch into a working exploit. Just an experiment, on my own machine, against a local test app. 30 minutes. From reading the patch to having a working exploit (DOS, as it was DoS only). 最近，React修复了一系列安全问题（CVE-2026-23870等）并发布了一篇公开博客。这是标准做法：展示工作成果，解释修复方案，提醒社区。我出于好奇读了那篇文章，然后心想：看看把这个补丁转化为可用的漏洞利用程序有多难？这只是在我自己的机器上针对本地测试应用做的一个实验。结果只用了30分钟。从阅读补丁到获得一个可用的漏洞利用程序（仅限DoS拒绝服务攻击）。

AI did most of the heavy lifting: understanding the diff, identifying the vulnerable code path, writing the PoC. The published issue was a denial of service, but the underlying primitive could go further with more work. In the old world, turning a public patch into a working exploit (n-day exploitation) took skilled reverse engineers days to weeks. That gap was the safety net. “We shipped the patch, admins have a few days to update.” That safety net is gone. The gap is now measured in minutes for simple bugs, maybe hours for complex ones. The skilled reverse engineer is optional. The LLM does the boring parts and the human just steers. The moment a patch ships, assume the exploit exists. There is no grace period. Companies cannot afford to “schedule” patch deployment for the next maintenance window. The maintenance window is now. AI完成了大部分繁重的工作：理解差异（diff）、识别易受攻击的代码路径、编写PoC。虽然发布的问题是拒绝服务，但如果投入更多精力，底层的原语（primitive）可以实现更深层的攻击。在旧世界，将公开补丁转化为可用的漏洞利用程序（n-day利用）需要熟练的逆向工程师花费几天到几周的时间。那个时间差就是安全网。“我们发布了补丁，管理员有几天时间来更新。”现在，这个安全网消失了。对于简单漏洞，这个时间差现在以分钟计算，复杂漏洞也只需几小时。熟练的逆向工程师不再是必须的，LLM负责枯燥的部分，人类只需负责引导。补丁发布的那一刻，就应假设漏洞利用程序已经存在。没有宽限期了。公司再也无法承担将补丁部署“安排”到下一个维护窗口的后果。维护窗口就是现在。

Story 3: the week linux caught fire

案例三：Linux“起火”的那一周

If you want the clearest possible proof that the 90 day disclosure model is dead, look at the last two weeks of the Linux kernel. Two back-to-back critical vulnerabilities. Both with public exploits. Both affecting every major distribution. The timeline reads like a horror movie. 如果你想要最明确的证据证明90天披露模型已死，看看过去两周的Linux内核就知道了。两个接连出现的关键漏洞，都有公开的漏洞利用程序，且都影响了所有主流发行版。时间线读起来就像一部恐怖电影。

Act 1: copy fail 第一幕：复制失败 On April 29, Xint Code (the team…) 4月29日，Xint Code（该团队…）