虚假 SQLite CVE 混入可信信息源并获评严重等级

研究人员发现，来自一个账户的 55 份漏洞公告中有 54 份疑似为伪造后，Google News 报道了这起令人不安的安全事件。尽管这些公告存在动摇其可信度的基础技术错误，其中多份仍获得了正式 CVE 标识符和严重风险评分。

这些报告瞄准了 SQLite——一种嵌入在浏览器、操作系统、移动应用以及无数开发者工具中的数据库引擎。报告描述了严重的内存安全问题，包括释放后使用（use-after-free）漏洞，即软件在释放内存后仍访问该内存。

然而，JFrog 的研究人员表示，报告引用的函数有时根本不存在。其他公告则援引了无关代码、不存在的修复方案，或无法引发所承诺崩溃的概念验证程序。

眼前的问题并不在于某个 AI 系统写出了可疑的安全文案。更深层的问题是，可疑报告进入了可信漏洞基础设施，而其中的标识符和严重性元数据为它们赋予了机构层面的可信度。

这带来了代价高昂的逆转。自动化原本应帮助防御者更快发现真实漏洞。但验证不足的自动化，反而可能为维护者、数据库运营方、安全厂商和企业响应团队制造看似可信的工作。

当前的核心冲突在于自动化漏洞生产与基于证据的验证之间。前者几乎可以毫无阻力地扩展，后者却仍依赖稀缺的人类专业知识、可复现测试与细致审查。

SQLite CVE 流程发生了什么变化

一批可疑的 SQLite 漏洞公告不再局限于私有代码库，并获得了成熟安全情报体系的标志。

2026 年 7 月 30 日，JFrog 发布了一项调查，针对一个新创建的 GitHub 账户发布的漏洞公告。该代码库包含 50 多项 CVE 声明，其中数项指向 SQLite。

JFrog 的 SQLite CVE 审计审查了所报告的代码路径、受影响版本、拟议修复方案和概念验证载荷。研究人员得出结论：该账户的 55 份公告中，除一份外均疑似为伪造。

其中六条 SQLite 记录受到特别细致的审查，分别为 CVE-2026-51302、CVE-2026-51303、CVE-2026-51300、CVE-2026-51297、CVE-2026-51296 和 CVE-2026-51304。

这些报告声称存在多处释放后使用问题。若攻击者能够控制释放内存中残留的数据，此类漏洞可能相当严重，潜在后果包括崩溃或未授权代码执行。

不过，危险漏洞需要的不只是一个看似合理的类别和自信的说明。调查人员必须证明受影响代码确实存在、攻击者能够触及该代码，以及相关行为会产生安全后果。

JFrog 表示，这些基础条件均未满足。CVE-2026-51302 引用了所述 SQLite 版本中并不存在的函数。报道称，CVE-2026-51303 描述的修复方案也无从查找。

另一份公告引用的代码行与其声称的漏洞无关。其中一份展示了真实函数，却给出了错误的参数数量。JFrog 测试时，概念验证载荷未能触发崩溃。

SQLite 也维护着自己的安全时间线，记录影响该项目的 CVE，并解释存在争议或被误解的声明。JFrog 进行审查时，受质疑的记录并未出现在其中。

仅凭这一缺失不足以证明某个 CVE 为虚假。供应商可能尚未更新其公开公告页面时，记录就已经出现；争议也可能数周未获解决。

但结合不存在的函数和无法运行的演示，缺少供应商确认就显得重要得多。这表明下游系统在未完成基本技术核对的情况下接受了这些声明。

这些记录仍获得了严重性元数据。JFrog 报告称，国家漏洞数据库（NVD）将其中数项评为严重，包括评分高达 9.8 的记录。

据报道，CVE-2026-51302 最初获得 Red Hat 的 10.0 评分，之后改为 7.6。这一变化降低了其严重性，但并未回答更根本的问题：该漏洞是否真实存在。

CVSS 评分衡量的是所描述漏洞的潜在技术严重性。它并不能独立证明描述准确、路径可达或结果可复现。

这种区别往往在企业仪表板中消失。一条标记为“严重”的记录，可能在任何人核实底层报告前，就触发服务工单、高管升级、合规审查和紧急补丁调查。

Google News 放大了公众讨论，但运营层面的影响更早就已开始。它始于未经验证的声明进入机器可读系统，而组织将这些系统视为可靠的安全输入。

为什么虚假漏洞会变成真实工作

伪造漏洞会消耗真实预算，因为防御系统会在工程师完成验证底层声明之前，先对元数据作出响应。

CVE 系统为公开披露的漏洞提供标准化标识符。参与其中的 CVE 编号授权机构会分配记录，下游服务则补充严重性、产品和利用信息。

由美国国家标准与技术研究院运营的 NVD，会为许多记录补充 CVSS 向量和受影响产品配置。安全扫描器和资产管理平台随后会将这些信息与企业资产清单进行匹配。

这种分层设计使新披露的漏洞能够迅速传达给防御者。但这也意味着，在维护者或独立研究人员提出质疑前，错误可能已经传播至多个服务。

设想一家运行内置 SQLite 产品的组织。扫描器发现一项严重的 SQLite CVE，并在该组织的软件资产中某处检测到匹配的版本号。

安全团队随即启动事件响应。工程师必须确定 SQLite 的编译方式、所称函数是否存在，以及任何应用是否暴露了报告中所述的执行路径。

采购团队可能联系软件供应商。产品团队可能暂停发布。合规人员可能要求提供修复证据，而客户则会要求就暴露情况发表声明。

如果该记录为虚假，所有这些工作都不会带来任何安全改进。组织只是将有限的响应能力耗费在证伪一个机器生成的故事上。

对开源维护者而言，负担更为沉重。他们必须回复报告者、检查代码、复现演示、解释设计假设，有时还要质疑已经发布 CVE 的数据库。

这种不对称使 AI 生成的 CVE 在经济层面具有危险性。制作一份打磨精美的公告可能只需几分钟，而证伪它却可能需要多名专家和数小时的协同测试。

Cloud Security Alliance 在其披露流程分析中描述了这种失衡。报告称，curl 收到的提交量达到其历史水平的八倍，其中 2025 年提交的 95% 被证实无效。

同一分析称，2025 年 CVE 发布量达到 48,185 条，创下连续第九年的年度纪录。根据所引用的研究，NVD 仅完整分析了新记录中的 28%。

AI 并非导致这一整体增长的唯一原因。更多参与机构、更广的供应商覆盖范围和不断增加的安全研究，同样会推高发布总量。

不过，低成本自动化提交恰恰在系统已面临信息补充积压之处增加了压力。一份看似可信的虚假报告，会与真实漏洞争夺同样的验证能力。

虚假记录还会让下游自动化更加复杂。修复代理可能搜索不存在的函数、提出无关补丁，或建议无法解决任何真实暴露问题的升级方案。

安全助手随后可能用自信的语言总结这些行动。每一个自动化环节都可能将不确定性转化为表面上的确认，尤其是当每个环节都信任前一系统的元数据时。

这就是虚假漏洞如何成为组织事实。它们会在有人回到源代码之前，先出现在仪表板、工单、报告和风险登记册中。

Google News 揭示了信任的逆转

安全生态系统曾为更快传播而优化，但 AI 生成的噪声已让验证成为更慢、也更有价值的环节。

传统漏洞披露假定，撰写可信报告需要专业知识。这种投入在历史上曾起到过滤作用，尽管早在生成式 AI 出现前，低质量和存在争议的提交就已存在。

现代编码代理削弱了这一过滤机制。它们可以检查代码库、识别可疑模式、生成技术说明、制作概念验证代码，并批量格式化漏洞公告。

生成的报告往往看起来很专业。它们包含漏洞类别、函数名称、严重性论证、攻击叙述和建议补丁。

语言质量不再是技术质量的可靠信号。一段润色完善的说明可以像蹩脚的说明一样，轻易掩盖一条根本不存在的调用路径。

Google 的 Chromium 安全团队现已维护内部指南来应对这一问题。其公开的 AI 报告指南将虚构 API、不可能出现的堆栈跟踪、无关的 CVE 引用和过度复杂的演示列为警示信号。

该指南建议分诊人员在阅读影响叙述前，先找出报告的技术核心。它还建议，在运行概念验证代码前，先检查引用资料，并审视其是否仅具备表面合理性。

最重要的是，Chromium 警告不要在没有可运行演示或 sanitizer 跟踪的情况下接受可达性声明。可达性意味着攻击者控制的输入确实能够到达易受攻击的操作。

这一要求针对的是生成报告中的常见失败模式。AI 模型可以识别孤立代码中的危险之处，却可能误解周围的控制机制、状态转换或应用架构。

一个函数可能看上去不安全，却始终无法被不可信输入访问。一项内存操作可能显得可疑，但在任何受支持的执行路径中都不会造成损坏。

反之亦然。在研究人员验证结果并与维护者协调的情况下，AI 辅助研究也能发现真实且难以发现的漏洞。

因此，全面禁止 AI 撰写的提交会错过真正的问题。关键区别不在于作者是人类还是机器。

区别在于研究是否经过验证。

一份可信报告应明确受影响版本、提供确定性的复现步骤、记录运行环境，并展示可观测的安全影响。对于内存安全声明，这类证据通常包括来自 AddressSanitizer 等工具的崩溃跟踪。

高质量的 AI 辅助研究人员能够满足这些要求。以提交量为优化目标的批量报告系统通常无法做到。

这是登上 Google News 的报道背后的核心反转。更快的发现不再保证更快的修复，因为系统的瓶颈已从发现可疑代码转向证明其可被利用。

攻击者和合法研究人员都能从更快的分析中获益。与此同时，维护者接手的却是一条混杂着真实缺陷、重复报告、推测性发现和伪造漏洞的队列。

安全社区无法仅靠为入站记录附加更自信的评分来解决这个问题。它需要的是在记录向下游流转时仍然可见的证据信号。

严重性评分无法验证漏洞

CVSS 描述的是在既定假设下漏洞可能造成的影响，但无法判断这些假设是否成立。

受到质疑的 SQLite 记录显示，严重性如何可能掩盖有效性。9.8 或 10.0 的评分看起来结论明确，尤其是在按风险从高到低排序的仪表板中。

然而，CVSS 计算依赖于输入。分析人员需要选择描述网络访问、攻击复杂度、所需权限、用户交互、影响范围和潜在后果的取值。

如果一则公告声称存在无需认证的远程代码执行，得出的评分可能非常严重。该公式不会检查应用程序源代码，也不会复现所称的漏洞利用。

CVE-2026-51302 说明了这一差距。JFrog 表示，该公告引用了一个不存在的函数，而下游评分仍然生成了严重级别为“关键”的元数据。

将评分从 10.0 改为 7.6，修正的是解释层面的一部分。它并不能验证该记录的技术前提。

随着新的参考资料、厂商评估或受影响版本详情的出现，NVD 记录本身也可能发生变化。这种灵活性是必要的，但自动化使用者并不总能区分初步数据与成熟分析。

因此，组织应将新的 CVE 视为证据质量各异的声明。一个标识符只能确认某条记录存在，并不能证明其中的每项陈述都已得到独立验证。

官方 CVE 项目已承认这一日益严峻的挑战。2026 年 6 月的一篇 CVE 讨论指出，AI 生成的发现可能识别出可疑代码，但未必能清晰映射为已确认的漏洞。

这一中间类别至关重要。可疑模式可以证明开展调查、甚至进行防御性代码修改是合理的，却不足以支撑“存在关键级可利用漏洞”的公开声明。

安全项目往往会将这些类别压缩为一类。它们的工具摄取 CVE、附加评分、匹配版本，然后生成修复期限。

更好的工作流程应当分开回答四个问题。

第一，相关代码是否存在于已部署版本中？第二，不可信输入能否到达它？第三，可复现的测试是否会触发所称的故障？第四，该故障是否会造成所述的安全影响？

厂商确认也应具有重要权重。维护者了解受支持的配置、编译时选项、回移补丁以及通用扫描器可能忽略的预期信任边界。

这并不意味着厂商应拥有绝对否决权。厂商可能低估缺陷、与研究人员存在分歧，或响应迟缓。

独立复现仍然必不可少。目标是多来源确认，而不是自动信任任何单一数据库、厂商或研究账号。

企业团队还可以纳入漏洞利用信号。CISA 的已知已被利用漏洞目录、漏洞利用预测评分系统以及厂商公告，能够提供基础 CVSS 评分所缺乏的背景信息。

没有任何一种是完美的。但与让一个严重数字主导紧急工作相比，它们组合起来的证据仍更有价值。

一个值得审视的问题是，增加更多关卡是否会拖慢真实漏洞的披露。确实可能，尤其当小型项目缺乏复现复杂发现的资源时。

因此，证据要求应与声明的严重程度相匹配。一则可能触发大范围紧急行动的关键级公开公告，应当比一项私下检查可疑代码的请求获得更强的验证。

目标不是隐藏不确定的报告，而是在下游系统将其误认为事实之前标明不确定性。

AI 安全研究仍会产出真实发现

SQLite 事件指向的是未经验证的自动化，而非 AI 在漏洞发现中的所有应用。

AI 系统正越来越有能力定位值得关注的漏洞。它们可以追踪数据流、比较代码模式、生成测试用例，并比单纯的人工审查更快地搜索大型代码仓库。

同一份 Cloud Security Alliance 分析列举了若干正面案例。其中称，一次由 AI 驱动的 OpenSSL 审计发现了 12 个此前未知的漏洞，其中包括一个存在了 27 年的缺陷。

它还提到，OpenAI 的 Aardvark 研究产出了与 10 个 CVE 标识符相关的发现。这些工作采用了验证和协调披露流程，而不是将模型输出视为一份完成的公告。

差异在于流程设计。负责任的系统会在发现与发布之间加入漏洞利用确认、人工审查和与维护者的协调。

模型的首次输出是一项假设。研究人员随后会测试脆弱状态是否存在，以及攻击者可控输入能否触发它。

如果测试失败，系统应修订或舍弃该发现，而不应生成更具说服力的解释并提交同一项缺乏支撑的声明。

优质研究也会保留相关工件。维护者应收到受影响的提交、构建配置、精确输入、执行轨迹和预期行为。

这些材料使独立复现成为可能，也减少了维护者将冗长叙述转化为可测试技术断言所需的时间。

Chromium 指南也作出了同样务实的区分。它并不会仅因 AI 协助准备报告就拒绝该报告。

相反，它会降低推测性报告的优先级，并将分诊重点放在可运行的证明、可信的追踪信息和有效参考资料上。这一政策将有限的注意力导向证据。

AI 也可以帮助保护流程免受自身噪声的影响。模型可以将公告声明与源代码树进行比对、识别缺失的函数、在隔离环境中执行演示，并检测不同版本之间的矛盾。

不过，自动化验证必须产出可检查的结果。第二个模型自信地同意第一个模型，并不构成独立验证。

工具多样性同样重要。静态分析、模糊测试、消毒器、符号执行和受控漏洞利用分别提供不同的证据。

当结果依赖于威胁模型或部署假设时，仍需人工判断。一种在某个应用中危险的行为，在另一个应用中可能是有意设计且受到控制的。

这种平衡的方法避免两种代价高昂的错误。第一种是因为 AI 安全工具看起来很先进，就接受每一份生成的报告。

第二种则是因为低质量提交污染了渠道，就否定每一项 AI 辅助发现。那样会把合法发现与垃圾内容一同埋没。

持久有效的标准是可复现性。报告者使用的工具并不如另一位合格人员能否观察到同样的安全后果重要。

安全团队接下来应关注什么

下一阶段将由证据要求、可见的置信度标签，以及维护者在持续提交压力下的应对方式来定义。

第一个信号是，CVE 权威机构是否会为自动化或 AI 辅助报告引入强制性证据字段。有用的要求包括经过测试的版本、可复现输入、崩溃追踪，以及对报告者验证流程的声明。

如果这些字段变得可供机器读取，下游平台就能区分未经验证的声明与经厂商确认的缺陷。这将强化一种判断：生态系统正在适应变化，同时没有阻碍合法研究。

如果记录仍以有说服力的文字发布，却没有可复现工件，那么 SQLite 事件就不再像一次孤立失败。它将表明速度仍然优先于准确性。

第二个信号是，存在争议的 SQLite 记录如何在 NVD、厂商数据库和 CVE 列表中发生变化。撤回、拒绝通知、修订后的描述以及删除受影响版本声明，都将表明纠正机制正在发挥作用。

安全团队应关注这些修正是否会传播到其扫描器和工单系统中。如果陈旧的关键告警仍在客户环境中保持打开状态，数据库更新的价值就很有限。

第三个信号是维护者行为。更多项目可能会限制自动化报告、要求经过验证的演示、取消经济奖励，或关闭公开提交渠道。

这些措施可以减少噪声，但也会为新研究人员设置准入障碍。健康的应对方式应惩罚反复提交无效报告的行为，同时为有充分文档支持的发现保留通道。

对防御者而言，眼前的教训很实际。不要忽视高评分 CVE，但也不要将其评分与证据混为一谈。

在启动紧急修复之前，检查厂商公告、受影响源代码、构建配置和复现证据。将置信度与严重性分开记录，使不确定性在整个响应过程中始终可见。

处理大量依赖项的团队还需要一份可搜索的决策记录。结构化的工程知识库可以保存厂商声明、复现结果和例外情况，而无需依赖零散的工单。

这篇 Google News 报道应促使每个安全组织提出一个直接的问题：你们的漏洞工作流程能否区分严重声明与已验证的严重缺陷？

如果答案是否定的，现在就建立这一区分。跟踪每条告警是否具备厂商确认、可运行的复现证据和可达的代码路径。这些检查无法消除不确定性，但能避免下一批虚假漏洞演变成真正的紧急事件。