OpenClaw安全公告激增，暴露GitHub与CVE漏洞跟踪体系的割裂

自托管的AI Agent项目OpenClaw发布仅仅数周，就在GitHub上收获了最多的星标，吸引了大量开发者社区和研究人员。但恐怕没人能想到，它的快速走红，竟成了一场针对全球漏洞跟踪体系的意外“压力测试”。

安全公告爆发式增长

从2月下旬开始，这个项目开始以惊人的速度发布安全公告，这种速度在开源世界里实属罕见。短短三周内，OpenClaw发布了超过200份GitHub安全公告（GHSA）。目前，其安全公告页面上密密麻麻列出了255条记录，多数问题涉及命令执行控制、授权检查、允许列表绕过和插件边界模糊等。

这种披露的速度，完全超出了传统CVE编号分配流程的处理能力，直接导致大量公告缺少对应的CVE编号。

有安全分析师指出，OpenClaw公告的快速堆积，直接暴露了漏洞披露领域长期存在的碎片化问题，而这早在AI驱动开发重塑开源世界之前就已埋下隐患。单个项目如此大规模的披露，让GHSA与CVE两大跟踪体系间的鸿沟，变得比以往任何时候都更加刺眼。

CVE分配机制遭遇挑战

事件在VulnCheck向CVE项目工作组提交一个“DIBS”请求时进一步升级。该请求针对的是170个缺乏CVE编号的OpenClaw公告。DIBS是CVE编号机构（CNA）之间使用的一种非正式协调信号，表示某个组织打算评估特定漏洞并可能为其分配CVE编号。VulnCheck的研究副总裁表示，此举是为了确保这些漏洞在被武器化之前就能获得CVE覆盖。

然而，MITRE的TL-Root反驳了这一做法，指出DIBS的设计初衷是标记符合特定标准的单个漏洞，而不是将整个项目进行批量归类。最终，这个请求被关闭了。

OpenClaw项目本身也曾更名为Clawdbot和Moltbot，这段命名历史进一步加剧了其漏洞在多数据库和公告系统中的索引复杂性。像OpenClaw这样代表用户跨外部服务执行命令的自动化平台，本身就暴露了大量攻击面。一旦研究人员开始对这类工具进行系统性审查，漏洞披露数量在短时间内激增也就不足为奇了。

GHSA与CVE体系的分化加剧

问题根源在于两条并行的披露路径。GitHub安全公告为维护者提供了一条捷径：研究人员报告问题后，维护者可以直接在仓库发布公告，无需与外部机构协调。相比之下，申请一个CVE编号需要通过CVE编号机构、格式化元数据并等待分配，流程要繁琐得多。因此，许多项目现在默认只使用GHSA，完全跳过了CVE申请。

这会造成什么问题呢？对于企业安全团队而言，这形成了一个实际的“盲区”。因为包括漏洞扫描器、补丁管理系统、SBOM工具和合规框架在内的大多数企业安全工具，都是围绕CVE标识构建的。这意味着，那些仅以GHSA形式披露的漏洞，对这些系统来说是完全“隐形”的。

有研究数据可以印证这种割裂的严重性。加州大学欧文分校2024年的一项调查发现，GitHub公告数据库中存有超过21.3万条未经审核的公告，而每日审核量不足6条。按此速度，需要95年才能完成清理。另一项2026年的研究分析了超过28.8万条GHSA，发现仅有8%经过了GitHub的正式审核。未审核的公告不会触发Dependabot警报，导致下游项目可能永远不知道自己的依赖包里藏着漏洞。

应对建议：交叉比对是关键

面对这种局面，一些安全从业者已经开始行动。例如，有安全工程师构建了专用跟踪器，每小时交叉比对GitHub公告数据库与CVE项目的代码库，专门追踪OpenClaw的公告，并包含修复版本数据以避免混淆漏洞状态。Anchore的安全副总裁指出，许多组织仍然会忽略没有CVE编号的漏洞，这种割裂构成了实实在在的运营风险。

因此，依赖AI驱动和自动化平台的安全团队，在审查自身的风险暴露时，必须对GHSA和CVE数据库进行交叉比对。随着AI加速开发让公告披露的速度持续提升，如果仅依赖单一的跟踪源，可能导致已知漏洞在你的部署环境中完全未被检测到。

参考来源：
OpenClaw Advisory Surge Exposes Gap Between GitHub and CVE Vulnerability Tracking
https://cybersecuritynews.com/openclaw-advisory-surge-exposes-gap/