GitHub Advisory Database Hits Record Volume as Vulnerability Reports Outpace Reviews

GitHub’s Advisory Database hit a record in May 2026, publishing 1,560 reviewed advisories in one month. The figure was more than five times its normal monthly output and the highest total in the database’s history.

The record still did not clear the growing queue. GitHub said vulnerability reports, repository advisories, and CVE requests have all increased at the same time, pushing the review system beyond the volume it was originally built to handle.

In a new GitHub blog post, Madison Ficorilli said review times for new advisories are now longer because both volume and complexity have increased significantly.

GitHub published a record number of reviewed advisories

The GitHub Advisory Database is a security vulnerability database that includes CVEs and GitHub-originated security advisories for open source software.

In May 2026, the database published 1,560 reviewed advisories. GitHub said the surge was not a one-month anomaly. From March through May, it processed more than 6,000 advisory decisions per month.

Those decisions included publishing new advisories, updating existing records, and reviewing inbound submissions. GitHub said this exceeded any previous three-month peak.

Metric	Recent GitHub figure	Why it matters
Reviewed advisories in May 2026	1,560	Highest monthly total in database history
Advisory decisions from March to May	More than 6,000 per month	Shows sustained pressure, not a short spike
Private vulnerability reports	About 550 per week in January to more than 3,000 per week in May	Shows a major rise in direct vulnerability reporting
Repository advisories	About 650 per week to more than 5,000 per week	Shows maintainers are publishing more security disclosures
GitHub CNA CVE requests	Almost 4,000 in May	Nearly 10 times higher year over year

Review delays are now stretching into weeks

GitHub said the backlog started affecting its internal publication goals in mid-April. Processing times first moved to about a week, then stretched to multiple weeks for a meaningful share of submissions.

The company said longer publication times can increase exposure windows. That matters because GitHub-reviewed advisories feed tools that help developers identify affected dependencies and move to fixed versions.

The same GitHub analysis says existing alerts continue to work normally, but new advisories may take longer to trigger, with critical issues prioritized.

The review system still relies on human validation

GitHub said the issue is throughput, not data quality. Its pipelines and publishing infrastructure continued to operate, and reviewed advisories still go through human validation before publication.

A reviewed advisory is not just a reposted vulnerability record. GitHub curators map the vulnerability to the correct package ecosystem, validate affected and fixed versions, confirm upstream accuracy, check duplication, and review classification and scoring.

The public GitHub advisory-database repository describes the project as a free and open source database of CVEs and GitHub-originated advisories affecting the open source world.

• Curators confirm the correct package and ecosystem.
• They validate affected and patched version ranges.
• They compare upstream advisories, commits, and release history.
• They check for duplicate records and inconsistent data.
• They review severity and classification before publication.

Why advisory review now takes longer

Some advisories remain simple. If a report clearly names the package, ecosystem, affected versions, root cause, and fix, GitHub said a curator can validate and publish it within minutes.

The growing problem is that more submissions require deeper investigation. Some reports use unclear package names, omit affected version ranges, or conflict with upstream commits and CVE records.

GitHub said multi-ecosystem advisories can also slow review. A single vulnerability may affect packages across npm, NuGet, Maven, pip, or other registries, requiring separate verification for each package.

Review challenge	Example	Effect on publication
Package ambiguity	A report names a project but not the package registry name	Curators must identify the correct package manually
Missing version ranges	The advisory says a bug is fixed but does not list affected versions	Curators must reconstruct version history
Multi-ecosystem impact	The same vulnerability affects packages in more than one registry	Each ecosystem needs separate validation
Conflicting upstream data	The CVE record, maintainer advisory, and commits disagree	Curators must determine the accurate impact

Private vulnerability reporting is driving more submissions

GitHub said more than 1.7 million repositories have enabled private vulnerability reporting. That gives researchers a built-in way to submit vulnerabilities privately to maintainers instead of opening public issues.

GitHub’s documentation for private vulnerability reporting says anyone can privately report a security vulnerability to maintainers if a public repository has the feature enabled.

This is good for responsible disclosure, but it also increases the amount of vulnerability data that eventually moves into advisory workflows. More reporting means more findings, more coordination, and more records that need validation.

Repository advisories are also scaling quickly

Repository security advisories allow maintainers to privately discuss, fix, and publish vulnerability information for public repositories. They can also request CVEs and publish details after a patch is ready.

GitHub’s documentation on repository security advisories says maintainers can use the feature to collaborate on a fix in a temporary private fork and then alert the project community when the advisory is published.

That process helps projects disclose vulnerabilities more responsibly. It also means GitHub’s curation team has to convert more upstream disclosures into accurate global advisory records.

Advisory source	What it contributes
Private vulnerability reports	Reports from researchers directly to maintainers
Repository security advisories	Maintainer-published vulnerability disclosures
CVE requests	Formal identifiers for vulnerabilities
National Vulnerability Database	Imported vulnerability records
Community contributions	Corrections and improvements to advisory data

Dependabot users may see slower alerts for new advisories

GitHub said existing Dependabot alerts are unaffected. The main effect falls on new advisories, which may take longer to trigger while the review queue remains under pressure.

GitHub’s Dependabot alerts documentation says the feature helps users find and fix vulnerable dependencies before they become security risks.

That makes advisory timing important. When a reviewed advisory reaches the database, downstream projects can receive alerts that point them toward a fixed dependency version.

What GitHub is changing

GitHub said it is improving triage, expanding backend curation capacity, modernizing data infrastructure, and increasing automation where it can reduce repetitive work without lowering the quality bar.

The company also said it has developed AI-assisted research tools for curators. GitHub said those tools support the research phase of advisory review, while human curators still make every decision.

Future changes include smarter risk-based prioritization. GitHub said it is exploring signals such as active exploitation, package usage, and ecosystem impact so the most important advisories reach users first.

• Improve triage for high-quality submissions.
• Increase backend curation capacity.
• Use AI-assisted tools for routine research.
• Expand automation for upstream CVE data extraction.
• Improve documentation and reviewer training.
• Prioritize advisories using exploitation and package-impact signals.

Why high-quality reports now matter more

GitHub said complete reports can move through review much faster. Missing package names, unclear version ranges, and poor reproduction details force curators to reconstruct facts from source code, commits, changelogs, and upstream records.

The platform’s best practices for security advisories say a strong advisory should include accurate ecosystem and package names, affected versions, patched versions, severity, CWE details, and a clear description.

For maintainers, that means advisory quality now has a direct operational impact. Better reports can lead to faster review, more accurate alerts, and fewer downstream corrections.

Report detail	Why GitHub needs it
Registry package name	Lets advisory data match affected dependencies correctly
Ecosystem	Separates similarly named packages across npm, pip, Maven, NuGet, and others
Affected version range	Prevents unnecessary or missed alerts
Patched version	Helps users upgrade to a safe release
Clear reproduction details	Helps curators validate the vulnerability faster
CVSS and CWE data	Improves severity and weakness classification

The open source vulnerability pipeline is changing

The rise in submissions suggests the open source security ecosystem is becoming more transparent. More researchers are reporting vulnerabilities, more maintainers are publishing fixes, and more repositories are enabling responsible disclosure.

That progress creates a new bottleneck. Central databases must turn a larger stream of vulnerability reports into records that package managers, scanners, maintainers, and developers can trust.

The advisory-database repository says advisories are stored in OSV format and can receive community pull requests for improvements, although GitHub’s internal security advisory curation team still reviews proposed changes.

What maintainers should do now

Maintainers should make it easier for researchers to report issues privately, then publish complete advisories once fixes are available. That reduces confusion and helps affected users receive accurate alerts.

The private reporting feature can help maintainers avoid public vulnerability disclosures before a patch exists. It also gives researchers a clear path when a project has enabled it.

Maintainers should also align advisory details with actual release history. Incorrect package names or version ranges can cause false positives, missed alerts, and extra review work across the ecosystem.

• Enable private vulnerability reporting for public repositories.
• Use exact registry package names, not only project names.
• List every affected package separately.
• Provide affected and fixed version ranges.
• Include reproduction details and root cause information.
• Coordinate with researchers before publishing.
• Request CVEs only when there is a clear publication plan.

What developers and security teams should expect

Developers should expect some new GitHub-reviewed advisories to take longer to appear while the review queue remains elevated. Critical issues may still receive priority.

Security teams that rely on dependency alerts should combine GitHub advisory data with vendor advisories, maintainer posts, package release notes, and vulnerability intelligence from other trusted sources.

GitHub’s Dependabot documentation remains relevant because the alerting workflow depends on accurate advisory data, dependency graph information, and available patched versions.

The bottom line

GitHub’s record advisory volume shows both progress and strain. More vulnerabilities are being found and disclosed, but the review process now faces a level of demand that slows publication for some records.

The company is responding with better triage, backend scaling, automation, AI-assisted research support, and future risk-based prioritization. It is not removing human review from the process.

The fastest way to reduce delays is also the most practical one: researchers and maintainers should submit cleaner vulnerability data. Complete advisories help GitHub review faster and help developers fix vulnerable dependencies sooner.

GitHub’s repository advisory workflow and advisory writing guidance give maintainers a clearer path to publish useful, accurate security information.

For the open source ecosystem, the message is clear. Vulnerability disclosure has scaled up, and the systems that validate, enrich, and distribute those reports must now scale with it.

FAQ