![](https://developer.qcloudimg.com/http-save/yehe-7353521/80fd24debab78cdbdf985706055400f3.jpg)

## TL;DR

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

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

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

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

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

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

2026 年 5 月 7 日，补丁合并进 netdev tree（[f4c50a4](https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4)），Kim 向 linux-distros 邮件列表提交了完整信息，设定了短暂的 embargo。同一天，一个无关的第三方识别出了这次补丁的安全含义，将完整 exploit 公开发布。第二道防线也在设定当天崩塌。embargo 就此破裂，Kim 随即获得各发行版同意，全量披露了 [Dirty Frag 的完整文档](https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md)。

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

## 两种漏洞文化的对峙

要理解 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（一个商业补丁比对工具）早就说明了这件事：你没有办法在不披露漏洞的情况下发布补丁。」

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




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

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

人工智能

安全

操作系统

AI技术正在颠覆传统漏洞披露机制，Linux内核漏洞CopyFail和DirtyFrag事件显示，开源代码透明度从安全优势转为风险。AI能实时分析补丁并生成漏洞利用方案，使90天协调披露窗口和“悄悄修复”策略同时失效。用户面临升级成本与安全风险的两难，维护者响应时间被压缩至小时级，开源生态需要重构漏洞响应体系。

漏洞扫描

漏洞修复

安全补丁

ChatGPT

Python

GitHub

Linux

SaaS

2026采购季 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

开源的透明度曾是护城河，AI 正在让它变成负担-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐