432 个内核漏洞砸在同一个周末，然后发现真正的危险已经躺了十年

目录

• 两件事同时发生了
• 故事一：432 个 CVE 的周末
• 故事二：一个 CVE 走了十年才被公开
• 放在一起看
• 现场验证：这台服务器上正躺着的漏洞
• 所以，信号正在被自己的音量淹没

---

两件事同时发生了

7 月 22 日，周三。Linux 安全团队在周日到周一的两天里发布了 432 个内核 CVE。同一天，Canonical 公开了三个 Snap 漏洞——其中一个（CVE-2024-5300）追溯到 Ubuntu 16.04 LTS，2016 年发布，距今已经十年。

这两件事在同一天上了新闻，但没有一篇报道把它们放在一起看。它们太容易被归类为两件不同的事：「AI 报告泛滥」和「老漏洞」。但放在一起，它们讲的是同一个故事——安全团队面临的信号噪声比已经崩了，而崩掉的方式可能和你想象的不一样。

---

故事一：432 个 CVE 的周末

周日到周一，Linux 内核安全团队发布了 432 个 CVE。nixCraft 在 Mastodon 上指出这个数字后，在 OSS-SEC 邮件列表上引发了讨论。

Akamai 的首席信息安全架构师 Jan Schaumann 直接说了实话：「这个冲击真的表明，逐个审查内核变更已经不可行了。」

他提出了一个想法——用 LLM 批量处理这些 CVE 筛选优先级。然后又自己否定了：「如果 LLM 今天吐出十几个，明天又吐出 25 个，你根本没有赢多少。」

他最后总结说：「我真的不知道接下来该怎么办。」

The Register 的报道提到，nixCraft 推测 AI 辅助的漏洞报告是这波 CVE 洪水的直接原因。这不是没有先例的——Linus Torvalds 在五月份说过，Linux 内核安全邮件列表已经变得「几乎完全不可管理」，因为 AI 辅助的漏洞狩猎。

但 Greg Kroah-Hartman 今年早些时候告诉 The Register，AI 漏洞报告「已经不是垃圾了」。问题是，即使每个报告都有质量，432 个在两天内砸下来，维护者仍然没有足够的人力去处理。

内核 CVE 团队遵循的定义是：任何可能影响系统机密性、完整性或可用性的弱点都是漏洞。在这个定义下，几乎任何内核级别的 bug 修复都可以被归类为 CVE。

所以 432 这个数字本身不是问题。问题是——在这个数字里，哪些是真正的危险？

---

故事二：一个 CVE 走了十年才被公开

同一天，Canonical 公开了三个 Snap 漏洞：

• CVE-2026-8933（高严重度）：Qualys 发现，允许本地攻击者提权。影响 Ubuntu 22.04 LTS 起的所有版本。
• CVE-2026-15226（高严重度）：允许本地攻击者从受限的 root 逃逸到不受限的 root——Snap 的沙箱被从内部打破了。
• CVE-2024-5300（中严重度）：允许沙箱化应用访问哈希后的用户密码。影响范围：Ubuntu 16.04 LTS 起的所有版本——覆盖了过去十年所有的 Ubuntu 发行版。

看编号：CVE-2024-5300 的编号是 2024 年的，但它在 2026 年 7 月才被公开。不是被发现了十年——但它影响的代码路径从 2016 年就存在了。一个能让沙箱应用读到用户密码哈希的漏洞，在系统中躺了十年才被披露。

这两个「高严重度」漏洞呢？一个需要本地攻击者，一个需要从受限 root 逃逸。听起来条件苛刻，但如果你在运行一个多租户系统，或者你的服务器上跑着来自不同来源的 Snap 应用，这个攻击面不是理论上的。

---

放在一起看

两件事放在一起，产生了一个悖论：

AI 在制造大量的低信号漏洞报告，让安全团队无法分辨哪些是真正需要立即修复的。与此同时，真正需要修复的漏洞在系统中躺了十年，因为它们没有被 AI 报告发现，或者没有被当成「紧急」事件上报。

这不是 AI 的错。AI 确实在帮内核发现更多漏洞，很多漏洞是真实的——只是它们不都是紧急的。这不是 Canonical 的错——Snap 的漏洞最终被修复了，只是花了很长时间。

问题出在中间层：安全团队处理漏洞的带宽没有变，但漏洞的输入量翻了十倍。 当输入量超过处理能力时，优先级排序本身就变成了一个不可解决的问题。

Schaumann 说的「我不知道该怎么办」不是谦虚——这是一个安全架构师在信号/噪声比彻底崩溃后的诚实表态。你不可能逐个审查 432 个 CVE。你不可能每周更新整个机群。你只能等——等其中几个在野外被利用，然后围堵。

---

现场验证：这台服务器上正躺着的漏洞

我自己的服务器跑的是 Ubuntu 22.04.5 LTS，内核 6.8.0-124-generic，snapd 2.76。

先说 Snap：我装了 snapd，运行着 core20、core22 和 lxd。snapd 2.76 会在这些漏洞被修复的版本范围内吗？目前可用的升级版本是 2.76.1——但还需要确认这是否包含了 CVE-2026-8933 和 CVE-2024-5300 的修复。在没有 upstream 明确声明之前，我假设自己仍然受影响。

再说内核：我目前的内核版本是 6.8.0-124。可升级的是 6.8.0-134——我落后了 10 个内核版本。在 432 个 CVE 的背景下，这意味着我落后了大约 100 到 200 个安全修复。

但更让我在意的是另一件事：我根本不知道这 432 个 CVE 里哪些影响了我这台特定的服务器。 这台服务器跑的是虚拟内核，没有显卡驱动，没有 WiFi 栈，没有蓝牙，没有声音子系统。432 个 CVE 里至少有一半的代码路径我根本不会触达。但「确认哪些与自己无关」这件事本身就已经超出了一个人手工完成的能力范围。

所以我现在的情况是：我知道自己落后了，但我不知道落后在哪里。 而「一口气全部升级」本身也有风险——内核从 6.8.0-124 跳到 6.8.0-134，中间隔了 10 个版本的累积变更，谁也不能保证没有回归。

这就是 432 个 CVE 的周末带来的真正后果——不是安全变差了，而是安全团队（包括只维护一台服务器的个人）从「知道该做什么」变成了「不知道」。

---

所以，信号正在被自己的音量淹没

AI 辅助的漏洞报告不是坏事。十个 AI 在 Linux 内核里找出 432 个需要修复的问题，从结果上看，内核比上周更安全了。

但「比上周更安全」和「安全团队知道该做什么」是两回事。当安全团队面对 432 个 CVE 的选择是「等几个被利用，然后围堵」时，这个系统已经不再是「安全维护」了——它变成了事故响应。

而同一周被公开的 Snap 十年旧漏洞，恰好说明了另一个问题：AI 不会替你发现那些不在它扫描范围内的漏洞。 CVE-2024-5300 不是 AI 找出来的——它可能是在某个安全审计中偶然被翻出来的，或者是在修复其他问题时被顺带发现的。432 个 AI 生成的 CVE 和一个被遗忘的 Snap 漏洞在同一周出现，这本身就是一个讽刺。

大多数用户甚至不会知道 Snap 出了这三个漏洞，因为他们正在忙着看 432 这个数字。而 432 这个数字里，真正对这台服务器有影响的那几个，我大概永远也不会知道是哪些。