拿10分的假CVE，和一个不存在的函数

前几天刷到个事，真给我绊了一下。

GitHub 上一个账户给 SQLite 提了五十多个 CVE。NVD 照单全收，Red Hat 甚至给其中一个打了 10.0 满分。后来 JFrog 去验证，55 个里面 54 个是纯捏造的。

先停一下，问个问题：这批假东西，凭什么能过审还拿满分？

最外层的答案很好找——流程兜不住了。MITRE 提交 CVE 不验身份，NVD 投递量太大放弃了深入分析。下游数据库再从 NVD 同步，一条假数据顺着管道往下流，每过一个节点就被盖一层"权威认证"的章。

但这只是流程层。再往下呢？——它为什么能让人觉得"像真的"？

JFrog 的报告里有个细节特别精准。有一条 CVE 说 SQLite 的 exprComputeOperands() 函数有内存问题。函数名、文件名、行号、漏洞类型全有，看起来非常专业。但你去翻 SQLite 3.41 的源码，这个函数压根不存在。另一条引用了 jsonBlobEdit() 函数——这个函数确实存在于 SQLite 里，但要到后续 JSONB 实现时才加进去，3.41.0 里面根本没有。还有一条更离谱，它指了 expr.c 的特定行号说是漏洞代码，你翻过去一看，那些行是注释和内存分配。

这底下是一层我剥了很久的东西：模型不是在描述一个它"见过"的真实漏洞，它是在预测"一个真实的漏洞公告应该长什么样"。函数名要听起来像 SQLite 的风格，行号要在合理范围内——这些统计上它都做对了。但"长得像"和"是"之间有条缝。

我一开始也觉得……假的东西总会被发现的嘛。但 JFrog 那边有个细节让我后背发凉：他们把官方 SQLite 编译出来，用 ASan 跑了所有 PoC，一个都没崩。连可复现的 PoC 都是编的——编得能跑，但触发不了任何真实的内存错误。

所以真正让我在意的，不是有人造假，是这批假货一路绿灯拿满分的过程里，没有任何一个人去翻一眼对应的源码行。Red Hat 给了 10.0 然后降到 7.6，说明他们一开始也没翻，是 JFrog 报过来之后才回头去看的。

再往下剥，这其实是 vibe coding 那套问题的另一个切面。

我们老说 AI 生成的代码"看起来对"所以危险。但这次的事说明，危险不止在代码层——一条漏洞公告，本质上是"一段声称世界是怎样的文本"。以前写这种文本需要去读代码、找 bug、写 PoC，这个苦力过程自带验证。现在 LLM 把描述这一步单独拎出来了——它可以跳过验证，直接生成一段看起来经过了验证的东西。

这层的答案是 trade-off：我们得到了"快速生成结构化文本"的能力，代价是"验证"从生成流程的内置步骤变成了一个必须外挂的步骤。以前验证是免费的——你不跑通就写不出 PoC。现在验证要额外花钱花时间，而且极容易被跳过，因为文本看起来太对了，对到你会觉得"没必要再查了吧"。

NVD 和 Red Hat 就是栽在这上面。他们信任了文本的"样子"。

JFrog 这帮人发现问题，靠的也不是什么高科技——就是去翻了源码。exprComputeOperands() 不存在，编译跑不过，PoC 不触发崩溃。任何一个愿意打开编辑器去对照的人，十分钟就能发现这些是假的。

再往下就是怎么重建验证链的问题了——是让数据库做自动编译验证，还是改 CVE 提交的身份认证机制。这个我还没想明白，先放这儿。