OpenClaw advisory wave exposes a growing split between GitHub and CVE tracking

OpenClaw’s rapid rise on GitHub has turned into something else entirely: a live stress test for vulnerability disclosure at scale. In just a few weeks, the project published more than 200 GitHub Security Advisories, and that pace exposed a practical gap between GitHub’s GHSA system and the older CVE-driven workflows that many enterprise tools still depend on.

The problem is simple. Maintainers can publish GitHub advisories quickly, but CVE assignment still moves through a separate coordination process. When a project produces disclosures faster than CVEs arrive, security teams can end up with two parallel records of the same risk, or no CVE at all for issues that already have a public GHSA.

That matters because many scanners, patch tools, SBOM workflows, and compliance programs still treat CVEs as the main vulnerability key. GitHub’s own documentation makes clear that advisories fall into different categories, and Dependabot does not generate alerts for unreviewed advisories.

Socket.dev says VulnCheck tried to call DIBS on 170 OpenClaw advisories that lacked CVE IDs after the project published more than 200 GHSAs in roughly three weeks. DIBS is an informal signal used by CVE Numbering Authorities to show intent to evaluate and possibly assign a CVE.

That request did not stand. According to Socket.dev, MITRE’s TL-Root pushed back and argued that DIBS is meant for identifying specific vulnerabilities that meet the rules, not for marking an entire supplier or project as a bulk target. The request was later closed.

This dispute turned OpenClaw into a very visible example of a broader issue that has been building for years. GitHub has become a fast publication layer for vulnerability data, while CVE still acts as the common language across much of enterprise security. When those two systems drift apart, defenders lose consistency.

GitHub’s own docs show why maintainers often prefer GHSAs first. GitHub says security advisories can be published there directly, and if maintainers include enough package and version data, GitHub can add them to the Advisory Database as GitHub-reviewed advisories. That is often much faster than waiting for outside CVE coordination.

At the same time, GitHub also states that Dependabot alerts do not get created for unreviewed advisories. That means disclosure volume alone does not guarantee downstream users will receive actionable alerts.

The OpenClaw case also produced its own workaround. Security engineer Jerry Gamblin created a public tracker that cross-references OpenClaw advisories across GitHub’s Advisory Database, repo-level advisories, and the CVE V5 registry, with hourly updates. That tracker exists because the normal path does not yet give defenders one clean, unified record.

The research backdrop reinforces the point. A 2026 paper analyzing more than 288,000 GitHub advisories found major differences in review speed and structure across the GHSA pipeline. The paper describes a fast path dominated by GitHub repository advisories and a slower path dominated by NVD-first advisories.

Why OpenClaw turned into a tracking problem

OpenClaw became popular very quickly, which attracted both users and researchers. That combination can create a burst of disclosures in a short period, especially for software that connects to local systems, plugins, credentials, browsers, and external services. This is an inference based on the advisory surge documented by Socket.dev and the project’s public advisory activity on GitHub.

Once the number of advisories grows fast enough, the gap between a GHSA and a CVE stops being a paperwork issue. It becomes an operational problem. One team may track the GHSA. Another may only ingest CVEs. A third may wait for Dependabot or another scanner to surface the issue. Those teams can end up looking at the same risk through different lenses, or miss it entirely. This is an inference supported by GitHub’s documentation on advisory types and alert behavior.

What the official documentation shows

What security teams should take from this

• Do not rely on CVE feeds alone for fast-moving open source projects.
• Check both GitHub advisories and CVE records when a project starts publishing vulnerabilities at high volume.
• Treat unreviewed advisories carefully, but do not ignore them just because Dependabot has not raised an alert.
• Watch for projects that need their own cross-reference dashboards when the public record becomes fragmented.

Why this matters beyond OpenClaw

OpenClaw is not the whole story. It is the clearest recent example. GitHub’s advisory ecosystem has grown into a major publication channel, but enterprise vulnerability management still leans heavily on CVEs because those identifiers remain the most portable across scanners, vendor bulletins, reporting tools, and governance processes.

That leaves the industry in an awkward middle stage. GHSA can publish faster. CVE still carries more universal operational weight. Until the tooling around both systems aligns better, projects that move fast will keep exposing the seam. OpenClaw just exposed it in public and at scale. This is an inference based on the documented DIBS dispute, GitHub’s advisory model, and the need for third-party reconciliation tools.

FAQ