开源的透明度曾是护城河，AI 正在让它变成负担

TL;DR

AI 正在同时击穿两种漏洞披露文化赖以成立的前提，开源软件的透明度优势正在变成安全负担，用户和维护者都面临前所未有的压力。

一个“安静”的补丁，如何引爆一场安全危机

2026 年 4 月 29 日，Copy Fail（CVE-2026-31431）公开披露。这是一个潜伏近十年的 Linux 内核提权漏洞——一个 732 字节的 Python 脚本，能在 2017 年至 2026 年补丁合并前构建的几乎所有主流 Linux 发行版上获取 root 权限，不依赖竞态条件，不需要特定内核偏移，逻辑直白，100% 可靠复现。

漏洞本身足够震撼。但更值得关注的，是它的“兄弟漏洞”Dirty Frag 的遭遇。

Dirty Frag 由安全研究员 Hyunwoo Kim 发现，包含两个子漏洞——CVE-2026-43284（ESP 变体）和 CVE-2026-43500（RxRPC 变体），属于与 Copy Fail 同一类的漏洞。2026 年 4 月 30 日，Kim 按照 Linux 内核社区的惯例，将补丁提交到了 netdev 邮件列表——修复是公开的，但他没有声张漏洞的安全影响，寄希望于这个补丁能淹没在每天数以百计的 commit 流中，悄悄合并，给各发行版争取一些打补丁的时间。

这个窗口只维持了 9 个小时——Kuan-Ting Chen 独立发现了同一个漏洞，并同样提交了报告。第一道防线就此失守。

2026 年 5 月 7 日，补丁合并进 netdev tree（f4c50a4），Kim 向 linux-distros 邮件列表提交了完整信息，设定了短暂的 embargo。同一天，一个无关的第三方识别出了这次补丁的安全含义，将完整 exploit 公开发布。第二道防线也在设定当天崩塌。embargo 就此破裂，Kim 随即获得各发行版同意，全量披露了 Dirty Frag 的完整文档。

这不是运气不好。这是一个信号：那套“悄悄修、静静等”的逻辑，正在失效。

两种漏洞文化的对峙

要理解 Dirty Frag embargo 破裂的意义，需要先了解安全社区长期并存的 [两种截然不同的漏洞处理文化（Jeff Kaufman）](https://www.Jeff Kaufman.com/p/ai-is-breaking-two-vulnerability-cultures)。

一种是协调披露：发现漏洞后私下通知维护者，给予修复时间（通常 90 天），补丁发布后再公开披露。核心逻辑是：在防守方准备好之前，不让攻击者知道漏洞的存在。

另一种是 Linux 内核社区流行的 “bug 就是 bug” 文化：直接提交修复，不声张安全影响，寄希望于补丁淹没在日常 commit 流中。它的前提是：大多数人没有能力逐一审查海量内核提交。

两种文化各有道理，也各有盲区。协调披露减少了信息不对称，但 90 天的窗口意味着知情方有时间协调，也意味着这段时间内信息始终处于不完全公开的状态。“bug 就是 bug”文化减少了信息管控的负担，但它的前提是补丁能真正“隐身”——而这个前提，正在动摇。

Dirty Frag 事件恰好是两种文化正面冲突的样本——Kim 尝试用“悄悄修”的方式争取时间，随后又设置了协调披露的 embargo，结果两道防线都在同一天失守。

关于两种文化的张力，Jeff Kaufman 在 [文章](https://www.Jeff Kaufman.com/p/ai-is-breaking-two-vulnerability-cultures) 中做了一个简单但直接的测试：把 Dirty Frag 的那次 commit（f4c50a4）分别扔给 Gemini、ChatGPT、Claude，三个模型在获得完整上下文的情况下，全部正确识别出这是一个安全补丁。“没人会注意”这个假设，实验直接推翻了。

AI 是如何改变这一切的

让两道防线同时失守的，不是运气，是一个更深层的变化：分析内核补丁的安全含义，不再需要专业门槛。

过去，从一个边界条件修复里识别出攻击面，需要深厚的内核知识积累。这道门槛客观上保护了修复窗口。今天，把一个 commit diff 扔给 AI，几秒钟就能得到安全评估。任何人，用任何 AI 订阅账号，都可以对主流开源项目的 commit 流做实时扫描，成本趋近于零。

Kuan-Ting Chen 在 Kim 提交补丁后 9 小时独立发现同一漏洞，是这个新环境的真实写照——他的具体手段无从核实，但逻辑是清晰的：当分析一个 commit 的安全含义只需要把 diff 扔给 AI，独立发现的速度就会自然加快，越来越多的人会在越来越短的时间内得出同样的结论。这不是个案，而是常态。

长时间的信息管控窗口，本质上已经不可靠了。两种文化赖以成立的前提同时失效，原有的规范已经跟不上了。

透明度的代价

开源软件的核心价值之一是透明度——代码公开、历史可查、修复可追溯。这种透明度带来了更快的漏洞发现、更广泛的社区审查、更高的整体安全水位。几十年来，“开源更安全”的论断建立在这个基础上。

但透明度对所有人平等开放，包括攻击者。过去，专业壁垒在一定程度上弥补了这个问题——真正能从公开代码中挖掘出安全漏洞的人屈指可数。现在这道补偿正在消失。

这里有一个意外的对照：中心化 SaaS 在这个新环境里反而获得了安全优势。SaaS 的修复可以在服务端静默完成，不需要公开 commit，不需要协调发行版，用户甚至感知不到漏洞的存在。透明度曾经是开源在安全上的核心优势，现在在某种程度上成了负担。但这不是要拿 SaaS 做答案——而是理解用户和维护者正在承受什么代价的起点。

用户：稳定版本不再是避风港

企业用户应对安全风险长期有一套行之有效的策略：锁定经过验证的稳定版本，只在必要时升级，用“慢而稳”换取可预期的运维成本。这套策略的前提是——稳定版本里的漏洞，攻击者挖起来也不容易。

现在这个前提动摇了。AI 辅助的漏洞扫描不区分新旧版本，只要代码公开，历史版本同样是扫描目标。Copy Fail 正是最典型的样本：漏洞潜伏将近十年，影响覆盖 2017 年至今几乎所有主流发行版，那些一直\“稳定运行\”从未升级过内核的系统，反而是暴露时间最长的目标。

频繁升级的代价是真实的：测试成本、回归风险、兼容性改造、运维窗口……对于有复杂依赖栈的系统，一次升级可能需要数周工程投入。用户面临的不再是“要不要升级”的选择题，而是“升级成本”和“不升级风险”之间越来越难以平衡的权衡。

维护者：窗口消失了

如果用户承受的是升级压力，维护者面对的是整个响应流程跟不上的问题。协调披露的 90 天窗口，不只是给用户打补丁用的，也是维护者完成漏洞分析、补丁审查、发行版协调、披露文档准备的喘息空间。现在这个窗口正在被强制压缩到几天甚至几小时——Dirty Frag 的 embargo 在设定当天就被打破。

大型项目有专职安全团队，勉强能跟上节奏。但开源世界的主体不是这些项目。npm 上数以万计的包、GitHub 上无数个人维护的库，背后往往只有一两个利用业余时间工作的人，没有安全响应流程，没有发行版协调渠道。当 AI 把漏洞发现成本降到接近于零，攻击方的扫描范围会自然扩展到这些长尾项目，而这些维护者根本没有能力在窗口内完成响应。

这不是个别人的问题，是整个开源生态结构性的脆弱。

“很快将没有任何安全的方式披露漏洞”

HackerNews 上有人评论道：

“Soon, there will be no such thing as a safe way to disclose a vulnerability in an open source project.” —— miki123211

这句话听起来像是极端悲观，但仔细想，它并不夸张。

补丁公开即披露，embargo 随时可能被打破，独立发现的速度越来越快——这三件事同时成立，意味着开源项目在漏洞修复这件事上，几乎没有任何可以依赖的缓冲机制了。

但这不意味着答案是“回归闭源”。闭源有自己的问题，而且开源的价值远不止安全一项。

真正需要改变的，是整个漏洞响应体系的速度预期。Jeff Kaufman 在文章中给出的方向是：超短 embargo 加上 AI 辅助的快速响应——如果补丁能在一小时内完成并进入 QA 流程，窗口即便只有几小时也是有意义的。但这对维护者、发行版、用户三方同时提出了更高的要求——所有人都要更快。评论区说得更直接：「协调披露的规范从来就没有为这个环境校准过，而且这十年来一直如此。现在的情况是，任何东西只要合并进 Linux mainline，就会有好几个不同的组织把 diff 喂给 LLM，积极评估这是否修复了某个漏洞，并生成 exploit 指导。」他还补了一句：「BinDiff（一个商业补丁比对工具）早就说明了这件事：你没有办法在不披露漏洞的情况下发布补丁。」

问题是，开源生态里大多数人，并没有“更快”的条件。