北京
7月30日，JFrog安全团队发布了一项调查结果，足以让每一个依赖自动化漏洞扫描的开发者团队警惕：一个新建的GitHub账号批量提交了SQLite漏洞通告，其中54个被证实为完全虚构，由机器生成、伪装成安全研究的内容。
这批虚假通告的传播路径并不复杂，却异常顺畅。NVD（美国国家漏洞数据库）迅速将其标记为严重级别，CISA的ADP（富化程序）也给出了同样的判断。Red Hat最初为其中一个编号为CVE-2026-51302的漏洞给出了10.0分的CVSS满分评分。
JFrog的调查揭示了这些通告的破绽：通告中引用的函数在声称涉及的SQLite版本中根本不存在，引用的代码行号超出了文件实际长度，所谓“已在3.51.3版本修复”的说法经比对后确认是幽灵补丁——3.51.2到3.51.3的diff中，通告点名的文件没有任何改动。
虚构漏洞的三个典型特征
JFrog将这批虚假通告合并分析后发现，AI生成内容检测工具立即给出了高置信度的判定。以下是这批虚构漏洞暴露出的共同模式，也是未来识别类似问题的关键线索。
不存在的函数。CVE-2026-51302（9.8分严重级别）声称在exprComputeOperands()函数中存在释放后使用漏洞。但该函数在通告指定的SQLite 3.41.0版本中并不存在，它直到2025年年中才被加入。通告还声称sqlite3ReleaseTempReg()会留下悬垂指针，但该函数只是将寄存器索引回收至数组，设计上就不可能产生释放后使用问题。
超出文件末尾的行号。CVE-2026-51296（7.5分高危）引用了json.c文件的第3555行和第3575行。在SQLite 3.41.0版本中，该文件总共只有2706行，引用的行号根本不存在。
不存在的补丁。CVE-2026-51303（9.8分严重级别）声称漏洞修复已在3.51.3版本中完成。但3.51.2到3.51.3的diff中，src/expr.c文件没有任何变更。
PoC从未真正执行
JFrog在隔离的Docker容器中构建了SQLite，并在AddressSanitizer（内存错误检测工具）下运行了每一个PoC（概念验证代码）。其中一个PoC是无效的SQL语句，在解析阶段就终止了，根本没有到达其声称利用的代码路径。其他PoC运行干净，未出现任何内存错误。
在分析的6个CVE中，全部为虚构。更广泛的审计发现，同一账号发布的55个通告中，54个为完全捏造，剩余1个包含真实漏洞但元数据未经核实。Hacker News上的讨论达到727分、373条评论，从业者最集中的担忧是：大多数组织对这类攻击没有任何防御手段。
Red Hat在收到质疑后，将CVE-2026-51302的评分从10.0悄然下调至7.6。但此时，虚假通告已经走完了标准流程：MITRE表单、NVD、GHSA（GitHub安全通告），并进入了所有同步这些数据源的企业扫描器。
如果你的CI（持续集成）配置会在检测到严重级别CVE时自动失败构建，或者通过Dependabot、Snyk告警自动创建Jira工单，那么这个故事与你直接相关。JFrog在报告中给出了针对Java管道的漏洞分流工作流建议，核心思路是：在自动化信任漏洞通告之前，先验证函数是否存在、行号是否有效、补丁是否真实。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
