Lean 核心可靠性漏洞 #14576 复盘：AI 辅助生成的“考拉兹猜想伪证”揭示内核缺陷

核心要点

• 漏洞成因：Lean 内核在处理嵌套归纳类型时，未能正确检查未在构造函数中出现的“幻影参数”，导致非法项逃避类型检查。
• 触发诱因：由 AI 辅助生成的考拉兹猜想（Collatz conjecture）“伪证”首次触发，该证明不含 sorry 却能通过旧版内核验证。
• 修复速度：官方在收到漏洞报告后一小时内即提交了修复补丁（#14577），并已发布新的补丁版本。
• 影响范围：该漏洞属于实现层面的 Bug，而非元理论缺陷，且仅能通过元编程绕过前端检查时触发。
• 外部检查器表现：独立的 Rust 实现检查器 nanoda 因另一个不相关的漏洞也未能拦截该证明，现已完成修复。

详细分析

漏洞的发现与触发机制

2026年7月25日，Ramana Kumar 发布了一个包含考拉兹猜想“反证”的代码库。令人惊讶的是，该证明在 AI 的协助下完成，且不包含任何 sorry 占位符，却得出了错误的数学结论。7月28日，Kiran Gopinathan 将该问题简化为一个对 False 的精简证明，并正式提交了编号为 #14576 的 Issue。经过调查，问题的核心在于 Lean 内核对嵌套归纳类型（Nested Inductive Types）的处理逻辑。

具体而言，当内核消除归纳类型 $T$ 下的嵌套出现时，如果该类型带有参数 $Ds$，且这些参数是“幻影参数”（即未在构造函数的字段中被提及），它们会从生成的辅助类型中消失。由于这些参数不再出现在辅助类型中，它们实际上逃避了内核的类型检查。攻击者可以利用这一点，在这些位置插入类型错误的参数，从而诱导内核接受一个错误的证明。

修复过程与安全性评估

在漏洞报告发布仅一小时后，开发团队便推送了修复程序。该修复由 Joachim Breitner 进行审核并提出了改进建议，随后被合并至主分支。尽管该漏洞性质严重，但其触发条件相对苛刻。在正常的 Lean 使用流程中，前端（Frontend）会检查所有参数并拦截此类非法项。该漏洞仅在通过元编程（Metaprogramming）直接向内核发送归纳声明时才可触及。因此，这被定义为一个实现层面的 Bug，而非 Lean 逻辑元理论（Meta-theory）的系统性漏洞。

外部检查器 nanoda 的关联漏洞

此次事件中，由 Chris Bailey 使用 Rust 开发的独立内核检查器 nanoda 也未能拦截该错误证明，但这并非因为相同的漏洞。调查显示，nanoda 实际上检查了 Lean 内核遗漏的那个环节，但它在投影节点（Projection Node）中未能正确验证类型名称。具有讽刺意味的是，nanoda 的这个独立漏洞在 Lean 漏洞被报告的一周前就已经由 Jeremy Chen 报告并修复，但 Ramana Kumar 使用的是一周前的旧版本 nanoda，导致该伪证在两个独立的检查器上均“蒙混过关”。

行业影响

这一事件在 Zulip、X（原 Twitter）、LinkedIn 和 Mastodon 等社交平台上引发了广泛关注。它再次证明了即使是高度可信的形式化验证工具，其内核实现也可能存在细微的边界情况漏洞。AI 在此次事件中扮演了意外的角色——通过生成复杂的代码结构，无意中探测到了人类开发者难以触及的内核边缘案例。此外，这也强调了开发多个独立内核检查器（如 nanoda）的重要性，通过交叉验证可以显著提升数学证明的绝对可靠性。

常见问题

问题：这个漏洞是否意味着 Lean 证明的所有数学定理都失效了？

不。该漏洞仅在特定且罕见的嵌套归纳类型构造中触发，且通常会被 Lean 的前端拦截。目前官方已经发布补丁，用户只需更新到最新版本即可消除该风险。

问题：为什么 AI 能够发现这个漏洞？

AI 并不是有目的地寻找漏洞，而是通过生成复杂的、非典型的代码结构（如本例中的考拉兹猜想伪证），无意中触发了内核在处理特定嵌套归纳类型时的逻辑缺陷。

问题：nanoda 和 Lean 内核是同一个东西吗？

不是。Lean 内核是官方的类型检查器，而 nanoda 是由社区成员使用 Rust 语言独立实现的外部检查器。两者的目标是相互验证，以确保证明的正确性不受单一实现 Bug 的影响。