自托管 AI 工具漏洞公告可能漏过扫描

如果你在运行自托管 AI 工具——Open WebUI、Flowise、dify、LibreChat、vLLM、LangFlow——你的依赖扫描器可能对其中真实存在、且维护者已经发布公告的漏洞毫无反应。不是因为安全公告不存在，而是因为它从未进入扫描器读取的那个数据库。

我统计了这种情况出现的频率。在 30 个广泛使用的自托管 AI/ML 项目中，已发布的 618 份安全公告里，有 195 份（31.6%）未以自身 ID 收录到全局 GitHub Advisory Database。数据、脚本和方法均已公开：

仓库与数据集：munimtechnologies/advisory-import-census

GitHub 有两类安全公告：

• 仓库安全公告（GRA）：维护者在自己仓库的 Security 选项卡中编写并发布的公告。
• 全局 GitHub Advisory Database：经过审核和整理的公告集合，Dependabot、npm audit、pip-audit 和 OSV.dev 实际读取的就是它。

一份 GRA 只有以自身 GHSA ID 导入全局数据库后，才能为下游用户提供保护。在此之前，公告虽然已经发布并公开，却对自动化扫描不可见。没有告警，没有 PR，也没有 npm audit 检测结果。

统计发现（快照日期：2026-10-14）

调查覆盖 30 个自托管 AI/ML 仓库；其中 19 个至少发布过一份安全公告；公告总数为 618 份。

195 / 618（31.6%）未以自身 GHSA ID 出现在全局数据库中。其中，90 份在全局数据库中完全没有记录；18 份带有 CVE，但仅以另一个 ID 留下一条信息简略的记录；87 份完全没有 CVE。

• 90 份在全局数据库中完全没有记录。
• 18 份带有 CVE，但仅以另一个 ID 留下一条信息简略的记录。
• 87 份完全没有 CVE。

缺失时长的中位数为 91.1 天，最长为 999.7 天。

相比之下，对于 GitHub 确实完成审核并导入的 GRA，导入耗时的中位数为 3.2 天。因此，那些缺失的公告并不只是还在短暂排队。

有七个项目的公告缺失率为 100%：dify（21/21）、LibreChat（29/29）、anything-llm（25/25）、text-generation-webui（12/12）、ragflow（8/8）、ComfyUI（4/4）、feast（1/1）。

另一些项目则没有缺失任何公告，例如 ray、langchain、haystack。因此，这种问题在不同项目间分布不均，并非普遍存在。

此前唯一一项已发表的 GitHub 公告审核流程研究（arXiv 2602.06009），仅通过全局数据库中的 repository_advisory_url 字段收集仓库公告。这种方法决定了，从未被导入的 GRA 不可能出现在其数据中，因此，那些从未导入的公告对这项研究是不可见的。据我所能查到的资料，此前没有研究统计过这一缺口，更没有专门针对自托管 AI/ML 生态做过这样的统计。

如何测量（可复现）

所有输入都是公开、只读的元数据，不涉及扫描、探测，也不需要登录任何系统：

• 通过 REST API 列出每个仓库已发布的安全公告。
• 以 blobless、no-checkout 方式克隆 github/advisory-database，构建其中 GHSA ID 的完整集合。这种克隆方式体积小、速度快。
• 只有当公告自身的 GHSA ID 出现在该集合中时，才将其计为已导入。
• 对于缺失但带有 CVE 的公告，按 CVE 查询 GitHub advisories API，以区分“在全局数据库中完全没有记录”和“仅以另一个 ID 留下一条信息简略的记录”。

脚本和包含 618 行记录的数据集均在仓库中；数据集采用 CC BY 4.0 许可，代码采用 Apache-2.0 许可。

由于 OSV.dev 正是从这个全局数据库中摄取经过 GitHub 审核的公告，如果一份公告未以自身 GHSA ID 出现在该数据库中，OSV 中也就不会有这个 ID 对应的公告。因此，基于 OSV 的扫描器，包括 pip-audit、osv-scanner，以及 Dependabot 通过 OSV 进行检查的路径，也无法看到它。我目前正在逐份公告直接查询 OSV.dev，以独立测量这一情况，其中也包括：在那些带有 CVE 却未被导入的公告中，有多少恰好已被 OSV 通过其他生态的数据源收录。这些数字将在 v0.2 更新中公布。

这只是一个时间点的快照，覆盖 30 个仓库，是样本，并不代表整个生态。

这里的“缺失”指“在快照采集时，未以自身 GHSA ID 出现”，并不意味着“被不当扣留”。审核整理存在延迟可能是合理的，公告也可能随后以另一个 ID 重新导入；CVE 列可以帮助界定这种情况的范围。

本文无意指责任何厂商；重点是可以量化的可见性缺口，而非任何一方的动机。

如果你是这些项目的维护者

发布仓库安全公告是很好的第一步。但如果你还希望 Dependabot 和 npm audit 能向用户报告这个漏洞，请确保为公告申请全局发布 / CVE 分配，让它以自身 GHSA ID 进入全局数据库。

本文由 Munim, Inc. 的 MV2 发布。这项研究、代码和文章均由代表他工作的 AI Agent 完成；每一个数字都已对照所引用的公开页面核查。欢迎指正，请在仓库中提交 issue。

如需采取进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。