一个被打上9.8分Critical的漏洞,引用的核心函数在目标版本的SQLite里根本不存在——这函数是2025年年中才写进代码库的。这不是段子,是安全公司JFrog这几天核实一批SQLite CVE时撞见的真事。
发生了什么
GitHub账号programmervuln/cveadvisory-这段时间批量提交了一批SQLite漏洞报告,NVD一度标记为Critical,CISA的授权数据发布方(ADP)也跟着打了高分。JFrog的人把这些报告拿去较真,结果发现整套证据链站不住:
- 函数不存在.CVE-2026-51302声称
exprComputeOperands()存在use-after-free,但这个函数在报告所指的3.41版本里压根没写出来。 - 补丁是编的.CVE-2026-51303说漏洞在3.51.3被修复,JFrog拿两个版本的
expr.c一比,一行代码都没改。 - PoC是非法SQL.好几个报告的触发语句连SQLite解析器都过不了,根本走不到声称出问题的那段逻辑。
- 行号张冠李戴.引用的代码行要么是注释,要么是无关的内存分配,和报告描述的漏洞机制毫无关系。
JFrog把这个账号发的55个报告整体审了一遍,54个是纯编造,只有1个混着真漏洞的元数据算是半真半假。把这批文档扔进AI检测工具Gptzero,直接触发AI生成内容警告。
三天之内,一个CVE的漂流
CVE-2026-51302这一个案例值得单独拎出来看,因为它把CVE生态里各方各说各话的乱象暴露得最清楚。
JFrog原文说的是"Red Hat把评分从10.0降到7.6"。但对照NVD和CVE官方记录,打分的其实是CISA ADP,7月28日给的是9.8分Critical,7月30日改判7.5分High,MITRE CNA自己从没出过分数。到7月31日,MITRE直接把这条CVE整条rejected——不是降级,是彻底作废。目前这条记录里只剩一个被拒绝的CNA容器,CISA ADP此前加的评分、CWE、引用全部被清空。
另外一个容易被误读的细节:检索不到这条CVE的Red Hat页面,不代表Red Hat否定了它。Red Hat从6月12日起就不再为不影响自家产品的第三方CVE单独出页面,这是政策调整,不是态度表态。JFrog原文对这两处都没说清楚,拿它当结论用之前,值得先核实一遍。
为什么这批假货能混进权威数据库
MITRE的提交表单不需要身份核验,任何人都能填一份漏洞描述、提一个CVSS分数。过去NVD的分析师会人工核实、补全,这道闸门是2024年2月被冲垮的——报告量暴涨,NIST干脆停了深度分析。CISA和其他授权发布方想补位,但整条流水线现在是碎片化的,积压严重。
- 结论.今天的CVE审核链条里,没有任何一环强制要求提交可复现的PoC或代码级验证,一份写得像模像样的AI报告就能一路滑到GHSA和企业扫描器里。
谁会真的为此买单
依赖NVD/CISA评分自动分级、自动开工单的安全团队首当其冲——Critical分数一出现,应急流程就会被触发,团队去查一个不存在的漏洞,浪费的是真实工时。用AI做漏洞分诊和自动修复的团队风险更大:AI agent遇到这种报告,可能会去找一个不存在的函数,生成一份修复根本不存在问题的补丁。
- 风险.虚假CVE混进供应链扫描器,不只是噪音,还会带偏自动化修复流程,引入不必要的代码改动。
《左传》讲"其兴也勃焉,其亡也忽焉",放在CVE审核这套系统上倒也贴切——它建立时靠的是信任提交者,如今被大规模、低成本的AI生成内容一冲,漏洞就露出来了。programmervuln账号剩下的那五十多个CVE会不会被MITRE批量撤销、NVD会不会补上代码级核验这道关,眼下还看不清,但这次至少证明了一件事:分数好打,代码难编,想核实一条CVE是不是真的,终究还是得回去读源码。