Methodology

What “in limbo” means

An advisory is in limbo when all of these are true:

• A maintainer has published it as a GitHub repository security advisory.
• It isn’t in GitHub’s reviewed Advisory Database, either under its own ID or as a duplicate: an already reviewed advisory for the same CVE.
• It isn’t in OSV.
• Its package is in an ecosystem GitHub reviews, such as npm, PyPI, Maven, Go, RubyGems, crates.io, NuGet or Packagist.

Dependabot alerts, npm audit, pip-audit and OSV-Scanner read GitHub’s reviewed database or OSV, as do many tools built on them, so they don’t report these advisories until GitHub reviews them. Tools with other sources may.

Likely permanent

Advisories in ecosystems GitHub doesn’t review (C/C++, container images, free-text package names, “other”) are counted separately, as likely permanent: 15,045 today. Scanners that read GitHub’s database will probably never see them. They aren’t in the headline number.

Sources

• GitHub repository security advisories, read through the GitHub REST API from each watched repository.
• GitHub’s reviewed Advisory Database, synced every day.
• OSV.dev, queried by advisory ID.
• The CVE List (cvelistV5) and CVE Services, for whether a CVE is reserved or published, and for CVEs other CNAs published that point to an advisory.
• The Go module proxy, for which Go module contains each package path an advisory names, so a package is matched against its module’s version.
• The NVD API, for NVD’s status. This product uses the NVD API but is not endorsed or certified by the NVD.

Facts are recorded only when they change, and each change is kept as an event, so every advisory page shows its history.

Coverage: every number is a floor

GitHub has no public list of every repository advisory, and an advisory waiting for review isn’t in its global database, not even as “unreviewed” (FINDINGS F-012). So Limbowatch can only see the repositories it checks: 67,471 today, chosen by this logic:

A repository can be on the list for several reasons, so these add up to more than the total. Repositories found through earlier advisory activity (the first two rows) publish most of the advisories we see.

• Once a repository is on the list it stays, and every advisory it publishes is tracked.
• Repositories with an advisory in limbo are re-checked daily, those with other advisories every 3 days, and the rest every 30 days. Repositories are also checked about a day and about three days after their package releases on npm, PyPI, Go, Maven, NuGet, crates.io, RubyGems or Packagist, because most advisories are published right after the fix ships. 67,028 are up to date on that schedule right now. Unchanged repositories cost nothing to re-check.
• The full list is public: repos.txt (those with advisories) and watchlist.json (every repository, with when it was last checked). Because it includes repositories chosen from ecosyste.ms package rankings, those two files are licensed CC BY-SA 4.0; advisory data stays CC BY 4.0.
• The most-used packages are being added in stages: the top 1,000 per ecosystem on 7 November 2026, then the top 10,000, first for NuGet, Packagist, Maven and RubyGems, where coverage was weakest, then from 9 November for npm, PyPI, Go and crates.io (FINDINGS F-099, F-100). A run checks at most 2,500 new repositories, so the daily re-checks keep their turn.

How much that covers. In the 7 days to 2026-11-11, the tracker saw 1,441 newly published advisories, in every ecosystem. GitHub said in June 2026 that it receives more than 5,000 repository advisories a week, so Limbowatch sees roughly one in four of everything published (FINDINGS F-098, an estimate). Coverage of what real projects depend on is far higher: the upstreams of the projects in our October report were almost all already watched (F-085).

Coverage of the most-used packages. The source repositories of the top packages in each ecosystem, by dependent repositories (ranking from ecosyste.ms, 2026-11-09):

What it can’t see. A repository whose first advisory has no CVE, hasn’t been reviewed, and isn’t a dependency of a project we follow. It appears once a CVE or a review reveals it. When the list grows, older advisories are found for the first time; the daily report counts these separately, so coverage growth isn’t mistaken for new limbo.

The weekly flow

“Published in the last 7 days” counts advisories whose maintainer published them in that window, in watched repositories and ecosystems GitHub reviews: 847 this week. “Reviewed” counts advisories that left limbo in the same window because GitHub reviewed them: 107. 108 left limbo in total, including duplicates and withdrawals. Both counts are floors, and a repository checked every few days can add its new advisories a few days late.

How waits are measured

A wait runs from the maintainer’s publication time on GitHub. “Median wait so far” is for advisories still waiting, so it understates how long they will wait in the end. Completed waits, from publication to review, are in the tracker’s “left limbo” tab and the October report, which measured a median of 23 days for 990 reviewed advisories.

How we check ourselves

• Findings are checked against primary sources only (GitHub, OSV, the CVE List, NVD), never web search or AI summaries.
• In November 2026 we rechecked 657 project findings live: none was contradicted (F-085). The 16 demo findings were rechecked one by one (evidence).
• On 8 November 2026 we rechecked 1,140 findings in 13 projects with each ecosystem’s own version library (semver, packaging, Gem::Requirement, golang.org/x/mod): 1,080 confirmed, 29 reported only as possible, 26 that depend on reading a malformed range, and 5 false positives. The false positives were Go modules whose path sits below another module’s; release 0.1.0a4 fixed them by asking the Go module proxy which module contains each path (F-112, F-113, F-114). In the same projects Dependabot alerted on none of the 1,140 (comparison).
• Version ranges are as entered by maintainers and haven’t been reviewed. A range that contradicts its own fix is reported as “possibly affected”, never as certain. Versions are compared with each ecosystem’s own rules, never as text.
• Package names are cleaned only where the fix is certain (stray spaces, a URL around the name, canonical spelling), and the original is kept. Advisories scanners can’t match lists the rest.
• Everything we learn goes into a public research log, with method, sample and caveats.

What we publish, and what we don’t

Facts only: IDs, repository, package, ecosystem, version range, fixed version, severity, CVE state, dates and links. We don’t copy advisory titles, descriptions, authors or credits; every record links to the maintainers’ advisory.

What helps, if you maintain a project

• Request a CVE when you publish the advisory, so CVE-based tools have something to find.
• Fill in both the affected range and the fixed version, with the package’s exact name in the right ecosystem.
• Check advisories scanners can’t match: a typo in a package name keeps an advisory invisible even after it’s reviewed.

Corrections

If a number or an advisory page is wrong, open an issue on GitHub or write to the address on the press page. Corrections are fixed in the code and logged in the research log.

Reproduce it

The tracker, the site and the analysis are open source under Apache-2.0. The tracker’s daily state is committed to the tracker-data branch, so any number here can be recomputed. The data is CC BY 4.0.