90天披露政策已死

# 90天漏洞披露政策已死 来源: https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/ ## TLDR⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#tldr) 90天的负责任漏洞披露窗口是为一个漏洞发现者稀缺且利用开发缓慢的世界而设计的。那个世界已经一去不复返了。大语言模型（LLM）已将这两者的时间线压缩至近乎为零。我已亲眼目睹，所有关注此事的人也都看到了。本文将通过真实案例阐述旧模式为何失效，并向业界提出一项请求：将每个关键安全问题视为 P0 级别并立即修复。不是明天，不是下一个迭代周期，而是现在。 --- 我从事安全工作已有一段时间，过去12个月的感觉有所不同。不是那种“AI将接管世界”的戏剧性变化，而是更平淡、更实际的变化。我们使用的工具、攻击者使用的工具以及研究人员用来查找漏洞的工具，都以大致相同的速度变得“更聪明”。这悄然摧毁了安全行业运行了十多年的某些基本假设。让我通过一些故事来解释我的意思。 ## 旧世界（安息吧）⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#the-old-world-rest-in-peace) 想象一下是2019年。你发现了一个关键漏洞。你撰写了一份报告。你发送给供应商。供应商花费几天时间进行分诊（triage），几周时间进行修复，也许还需要一个月时间才能部署。如果你遵循Google Project Zero (https://googleprojectzero.blogspot.com/)风格的披露方式，你会在公开之前给他们90天的时间。在这90天里，你假设： - 你可能是唯一发现此漏洞的人 - 即使其他人发现了，他们也需要花费时间 - 供应商在编写补丁方面有充裕的提前量 - 补丁发布后，攻击者需要几天或几周的时间将其逆向工程化为可利用的攻击载荷 上述每一个假设现在都是错误的。 ## 故事1：10个人，1个漏洞，6周⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#story-1-10-people-1-bug-6-weeks) 4月下旬，我向一家公司报告了一个相当严重的漏洞。由于该问题尚未修补，我保持细节模糊，但其大致情况如下：攻击者可以从网站购买任何商品，向服务器发送自己构造的响应，并且由于响应对无签名验证，服务器会欣然接受。以0美元购买5000美元的商品。在未付款的情况下标记购买已完成。关键问题，易于利用，对公司来说是糟糕的一天。不错。我写好了报告，发送出去，自我感觉良好大约10分钟。然后分诊团队回复说：“是的，我们知道，最早在3月就有报告了。你是第11位报告者。”**十一个该死的人**在大约六周内发现了同一个关键漏洞。 sashko BlueWater CTF的一位朋友几个月前就指出了这种模式，即LLM辅助的猎手几乎同时在全无关联的报告者使用完全无关的工作流的情况下，收敛于相同的漏洞。而且不只是我注意到了这一点。@d0rsky (https://x.com/d0rsky/status/2040848736713126365)，从事分诊工作，发布了以下内容： > *“一旦发现新漏洞——尤其是通过某些LLM提示/技能/自动化——我们就会在几天内收到大量重复报告。根本原因相同，措辞略有不同。[...] 我更担心的是，如果研究人员能如此快速地复制这些发现，是什么阻止了黑帽黑客在问题修复之前做同样的事？感觉‘首次发现’与‘大众知晓’之间的窗口正变得危险地短。”* 没错。分诊团队也看到了这一点。这不是研究人员的妄想。这是一个模式。 sashko NobodyIsNobody 起初我想，好吧，同样的工具，同样的提示，说得通。但随后我做了令人不安的计算。如果有10个人报告了漏洞，有多少人在发现后**没有**报告？帮助10位诚实研究人员的同一个LLM也对其他人可用。它不会在门口检查你的意图。在这10位报告者中，只有1人获得CVE信用。只有1人获得赏金。那其他9人呢？有多少人感到沮丧？有多少人决定出售它而不是等待？而那些根本没有报告的人——他们不坐在90天的倒计时钟上。他们不坐在任何倒计时钟上。**90天窗口并没有保护用户。它只是给所有已经掌握漏洞的人90天的提前量。** ## 故事2：从补丁到利用仅需30分钟⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#story-2-30-minutes-from-patch-to-exploit) 最近，React修复了一批安全问题（CVE-2026-23870 (https://nvd.nist.gov/vuln/detail/CVE-2026-23870),CVE-2026-44575 (https://nvd.nist.gov/vuln/detail/CVE-2026-44575),CVE-2026-44579 (https://nvd.nist.gov/vuln/detail/CVE-2026-44579),CVE-2026-44574 (https://nvd.nist.gov/vuln/detail/CVE-2026-44574),CVE-2026-44578 (https://nvd.nist.gov/vuln/detail/CVE-2026-44578)）并发布了一篇公开博客文章。标准做法。展示工作成果，解释修复方法，给社区一个预警。我出于好奇读了这篇文章。然后我想，看看将这个补丁转化为可利用的攻击载荷有多难。只是一个实验，在我的机器上，针对本地测试应用。**30分钟。**从阅读补丁到拥有可工作的利用代码（因为是DoS，所以只是拒绝服务）。AI完成了大部分繁重工作：理解差异（diff），识别易受攻击的代码路径，编写概念验证（PoC）。发布的问题是拒绝服务，但底层原语经过更多工作可以走得更远。在旧世界中，将公开补丁转化为可利用的攻击载荷（N日攻击）需要熟练的逆向工程师花费数天到数周的时间。这个差距就是安全网。“我们发布了补丁，管理员有几天时间进行更新。” 这张安全网已经没了。对于简单漏洞，这个差距现在是以分钟计算的，对于复杂漏洞可能以小时计算。熟练的逆向工程师不再是必需的。LLM处理枯燥的部分，人类只需 steering。**补丁发布的瞬间，就假设利用代码已经存在。**没有宽限期。公司负担不起“计划”在下一个维护窗口部署补丁。维护窗口就是现在。 ## 故事3：Linux燃起烈火的那一周⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#story-3-the-week-linux-caught-fire) 如果你想找到90天披露模式已死的最清晰证据，看看Linux内核的最后两周。两个连续的关键漏洞。两者都有公开利用代码。两者都影响所有主要发行版。时间线读起来像是一部恐怖片。 ### 第一幕：Copy Fail（复制失败）⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#act-1-copy-fail) 在**4月29日**，Xint Code (https://code.xint.io/)\(Theori (https://theori.io/)背后的团队，九次DEF CON CTF冠军\)公开披露了Copy Fail (https://copy.fail/)——**CVE-2026-31431** (https://nvd.nist.gov/vuln/detail/CVE-2026-31431)。内核加密子系统中的一个直线逻辑缺陷。不需要竞态条件。100%可靠。一个**732字节的Python脚本**可以在自2017年以来发布的每一个Linux发行版上获取root权限。每一个。全部。Ubuntu, RHEL, Amazon Linux, SUSE, 所有都包括。距离游戏结束只有一个`curl | python3 && su`的距离。令人恐惧的细节：他们使用AI发现了它。大约一个小时针对内核`crypto/`子系统的自动化扫描。就这样。一小时。一个扫描器。九年的暴露期。完整的技术分解，请阅读Xint的分析文章 (https://xint.io/blog/copy-fail-linux-distributions)。Copy Fail确实获得了补丁（主线提交`a664bf3d603d` (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603d)）和一种直接的缓解措施：禁用`algif_aead`模块。人们开始打补丁。深呼吸。好吧。也许我们可以处理这个。然后威胁行动者出现了。据报道，伊朗对手利用该漏洞入侵Ubuntu服务器，并将其重新用作DDoS活动的节点。由AI发现、公开披露、被国家行为体武器化、用于构建攻击基础设施的内核权限提升漏洞。这一切都在几天内完成。 Enlightment ### 第二幕：Dirty Frag（脏碎片）⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#act-2-dirty-frag) **不到一周后**，在**5月7日**，研究员Hyunwoo Kim（@v4bel (https://x.com/v4bel)）发布了Dirty Frag (https://github.com/V4bel/dirtyfrag)——**CVE-2026-43284** (https://nvd.nist.gov/vuln/detail/CVE-2026-43284)和**CVE-2026-43500**。内核IPSec ESP（`esp4`/`esp6`）和RxRPC网络模块中的两个链式漏洞。与Copy Fail和Dirty Pipe (https://dirtypipe.cm4all.com/)属于同一类漏洞。相同的页缓存损坏技术。不同的攻击路径。关键部分是：**即使你应用了Copy Fail的缓解措施，Dirty Frag也有效。**即使你黑名单了`algif_aead`。Dirty Frag不使用该模块。它通过完全不同的路线达到相同的结果：在非特权用户到root之间，确定性地，在所有主要发行版上。Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44。一行命令编译并运行。而在这里，披露模式完全崩溃了。Hyunwoo Kim在4月29-30日向`[email protected]`报告。他公开提交了补丁。他于5月7日与`linux-distros` (https://oss-security.openwall.org/wiki/mailing-lists/distros)邮件列表进行了协调，达成了5天的禁运期。就在同一天——**几小时内**——一个无关的第三方发布了关于ESP漏洞的详细利用信息，打破了禁运期。在与发行版维护者协商后，Hyunwoo发布了完整的Dirty Frag分析文章 (https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md)，利用代码和可工作的PoC。**在那一刻，没有任何Linux发行版提供补丁。**截至目前，只有CVE-2026-43284（ESP部分）有主线修复 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4)。CVE-2026-43500（RxRPC组件）**仍然没有上游补丁**。并且结合两者的链式利用几乎适用于所有系统。（Ubuntu (https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available),Red Hat (https://access.redhat.com/security/vulnerabilities/RHSB-2026-003), andothers (https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe)已发布其自己的公告。）微软的Defender团队在披露后**24小时内**确认了有限的野外利用 (https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/)。攻击者获取SSH访问权限，部署ELF二进制文件，通过`su`提升root权限，修改身份验证配置，擦除会话文件，横向移动。全套剧本，在生产环境中实时上演。CTS（@gf_256 (https://x.com/gf_256/status/2052480591489122747)）用五个字总结了它： > **“负责任披露已死🤦”**CTS Tweethttps://x.com/gf_256/status/2052480591489122747是的。 ## 那么这里到底什么死了⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#so-what-is-actually-dead-here) 让我具体说明我认为已无法修复的部分。**90天披露窗口已死。**不是“需要改革”。不是“可以稍微调整”。死了。它是为发现者稀缺且利用开发缓慢的世界设计的。LLM使发现者变得丰富且利用开发变得快速。当10位无关的研究人员在6周内发现相同的漏洞，且AI可以在30分钟内将补丁差异转化为可利用代码时，90天窗口到底保护了什么？谁也没保护。它只是在用礼貌的名字掩饰暴露。Copy Fail从AI扫描到公开PoC再到国家行为体武器化仅用了几天。Dirty Frag的禁运期在几小时内就被独立发现相同漏洞类的第三方打破。当相同的漏洞被多位研究人员和AI工具同时独立重新发现时，你无法协调披露。信息不再能被 containment。它拥有了LLM驱动的腿。**月度补丁周期也死了。**漏洞与修复之间30天的窗口假设攻击者比你的发布列车慢。他们并不慢。他们已经快了一段时间，而且差距还在扩大。微软在披露后24小时内就在野外看到了Dirty Frag。你的月度维护窗口不是安全余量。它是攻击窗口。**“等待公告”也死了。**如果你在阅读CVE描述时，攻击者正在阅读`git log --diff-filter=M`，你 already behind。公告是下游产物。补丁差异才是信号。 ## 业界需要做什么（我不会粉饰太平）⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#what-the-industry-needs-to-do-and-i-am-not-sugarcoating-this) 我有一个请求。一个。我知道这听起来极端。我知道这要求很高。但我上面展示的一切都指向同一个结论：**将每个关键安全问题视为P0并立即修复。**不是“24小时内”。不是“下一个迭代周期”。不是“在我们评估影响之后”。是现在。意思是，停下你正在做的事，现在就修复它。我知道这听起来不合理。我知道生产部署很复杂。我知道变更管理存在是有原因的。但威胁环境并不关心你的变更管理流程。以下是“立即”在实际操作中看起来的样子：**如果你是收到关键漏洞报告的供应商**，你的时钟从报告到达的那一刻开始计时。不是在你完成分诊时。不是在工程团队接手时。是它到达的那一刻。因为如果有人向你报告了，假设其他10个人也有，而且其中至少有一个不是善意的。**如果你是研究人员**，不要捂着关键漏洞。推动尽可能短的披露窗口。如果供应商无法在一周内修复，那是供应商的问题，不是披露的问题。旧的“给他们时间”的礼节在你还是唯一发现者时有意义。你不再是唯一发现者了。**如果你正在运行漏洞管理**，它必须是实时的。旧的“每周扫描，迭代分诊，周期内补丁”的时间线是攻击者在几个月前就抛弃的。关键问题的新最大响应时间是小时。不是天。小时。甚至这可能都太慢了。 ### 给蓝军的备注⌗ (https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#a-note-for-the-blue-team) 这部分重要到值得单独列出。攻击者已经将LLM集成到他们的利用管道中。如果你在防御方面没有做同样的事，你就是在拿着剪贴板去枪战。以下是我认为每个工程和安全团队现在应该构建的方向：**在代码推送点集成LLM。**每个拉取请求，每个合并，每个部署。将AI辅助的安全审查作为CI管道的一部分运行，就像你运行linter和单元测试一样。不是事后诸葛亮，也不是季度审计。在推送时。如果代码有漏洞，在它到达生产环境之前捕获它。在PR审查中修复漏洞的成本比CVE发布后修复它低几个数量级。**集成LLM