1,560 reviewed advisories in May 2026 — more than five times GitHub's typical monthly output — and the Advisory Database still couldn't keep up.
Private vulnerability reports across the platform jumped from ~550/week in January to over 3,000/week for most of May. Repository advisories scaled from ~650/week to over 5,000/week. GitHub's CNA processed nearly 4,000 CVE requests in May alone, pushing the year's total past 30,000 CVEs already. More than 1.7 million repositories now have private vulnerability reporting enabled. This isn't a spike; it's a structural shift.
Why Curation Time Exploded
Review times that used to take a few days stretched to multiple weeks starting mid-April. The queue isn't just longer — it's harder. A growing share of incoming advisories require manual detective work: disambiguating package names across ecosystems (is "foo" on npm, PyPI, or Maven?), reconstructing version ranges from commit history, and reconciling conflicting upstream data between CVE records, maintainer advisories, and commit logs.
GitHub's curators validate each advisory against actual release history, check for duplication, confirm classification and scoring. A well-formed advisory with complete version ranges and a clear fix can be published in minutes. But when volume surges, the hard cases — which take disproportionately longer — clog the queue. The mix matters more than the total count.
What 'Reviewed' Actually Means at This Scale
Reviewed doesn't mean copy-pasted. Every advisory that gets the green check has been: mapped to the correct ecosystem package, validated against release history, checked for upstream accuracy, deduplicated, and scored with a full CVSS vector. Skipping that verification to publish faster would flood downstream tools with false positives — more dangerous than a delay.
Existing Dependabot alerts are unaffected. API consumers still get accurate data on reviewed advisories. The bottleneck is human judgement applied to an increasingly complex input stream. GitHub's assignment rate held steady at 91–94% through the surge, so the quality of incoming requests hasn't degraded — the volume has.
How GitHub Is Scaling Without Cutting Corners
GitHub is investing in three concrete areas: AI-assisted research tools that help curators complete routine validation faster, smarter risk-based prioritization using package usage and exploitation signals, and tighter feedback loops with upstream data sources to fix quality issues closer to the origin. They've also strengthened triage so high-quality submissions move through faster.
The longer-term bet: reduce time-per-advisory for the most common cases through automation, freeing human curators for the genuinely ambiguous ones. GitHub is also expanding operational documentation to accelerate onboarding and maintain consistency.
What This Means for the Ecosystem
Two years ago the database published ~270 advisories per month. Now it's 1,500+. The growth reflects real progress — more researchers reporting, more maintainers publishing fixes, more repositories enabling responsible disclosure. That pressure is a feature, not a bug. The challenge is keeping curation quality intact while the pipeline runs at 5x capacity. GitHub's transparency about where it's breaking — and what it's building — sets a bar for how a platform should handle scaling trust in the vulnerability ecosystem.
Source: Inside the Advisory Database and what happens when vulnerability volume breaks records
Domain: github.blog
Comments load interactively on the live page.