The surge in vulnerability reports impacts the speed of security patching and alert generation. Understanding these bottlenecks helps engineers improve disclosure quality, ensuring faster publication of critical security data and reducing the exposure window for open-source dependencies.
In May 2026, the GitHub Advisory Database published 1,560 reviewed advisories—more than five times our typical monthly output and the highest in its history.
And it still wasn’t enough to keep up.
Over the past few months, the vulnerability ecosystem has shifted in a fundamental way. Input across private vulnerability reports, repository advisories, and CVE requests has increased simultaneously, pushing the entire system to a new operating scale.
This blog builds on an ongoing GitHub community discussion tracking the evolving nature of vulnerability reporting, as well as PVR and Advisory Database roadmap developments. A recurring theme in that thread is the downstream impact of platform changes on advisory curation and data quality. This aligns with GitHub’s broader shift toward emphasizing quality and shared responsibility in vulnerability reporting, which in turn directly shapes how advisory data must be curated and maintained.
Review times for new advisories are longer because vulnerability volume and complexity have increased significantly. Advisory quality has not changed: reviewed advisories are still human-validated, and existing alerts continue to function normally. If you want to help, focus on three things: submit complete vulnerability data, coordinate closely with maintainers and researchers, and request CVEs only when there is a clear intention to publish.
May was not a one-time spike. From March through May, we sustained more than 6,000 advisory decisions per month. This included updating existing advisories, publishing new advisories, and reviewing inbound advisories, and exceeded any prior three-month peak.
At the same time, inflow accelerated across every source:
This is not a localized surge. It reflects structural change across the vulnerability disclosure ecosystem.
Since mid-April, due to this surge, we have not consistently met our internal goals for publication. Processing times extended first to about a week, then to multiple weeks for a meaningful share. Longer publication times can increase exposure windows. We take that seriously, and timeliness is a core part of the value this database provides.
Our data pipelines and publishing infrastructure have continued to operate through this period. Imports are running, data integrity is intact, and published advisories are accurate. Advisories that reach reviewed status today meet the same quality standard as before.
CVE assignment quality has remained strong. Our assignment rate has held between 91–94% through the entire surge, consistent with or better than historical norms and showing that there hasn’t been a clear degradation in the requests we receive.
The issue is throughput. The system that validates, enriches, and publishes advisory data is functioning; it is now operating beyond the volume and complexity it was designed to handle.
Not every security advisory requires the same level of effort. Some arrive well formatted: the advisory details clearly name the affected package and its relevant ecosystem, the version range is documented, and the fix is tagged. A curator can validate and publish these in under a few minutes.
But a growing share of incoming advisories require more investigation:
Historically more straightforward advisories dominated, and the harder ones could be absorbed. When volume surges, the queue fills with both, and the complex ones take disproportionately longer, creating a compounding effect. The mix now matters much more. This isn’t just more work; it’s significantly more complex.
A reviewed advisory is not simply a republished record; it’s the result of verification.
Curators:
This is what allows downstream tools to rely on the data without additional validation.
Publishing faster by skipping verification would increase false positives at scale, which can create more risk than delay.
This trend extends beyond GitHub.
The volume of reported and published vulnerabilities continues to grow rapidly, and organizations across the ecosystem are adapting to that change.
The system is working as designed. More vulnerabilities are being reported, disclosed, and tracked than ever before. That creates pressure downstream, including during advisory curation.
To support this new scale, we are investing in:
Include complete data in vulnerability reports. Providing affected version ranges, root cause, and clear reproduction steps makes a direct difference in how quickly and accurately advisories can be reviewed. When this data is complete, curation can take minutes. When it isn’t, curators must reconstruct missing details from source code, release history, and conflicting upstream signals. At this scale, those gaps compound quickly. High-quality upstream data is one of the most effective ways to improve both speed and accuracy across the ecosystem.
Include the right advisory details. Our best practices guide covers ecosystem categorization, package names, and version range formatting, but a few additional details make a direct difference in how quickly and accurately advisories can be reviewed and published to the GitHub Advisory Database.
For more guidance, see the best practices for writing clear, complete security advisories.
Be intentional when requesting CVEs. Requesting a CVE ID signals that a vulnerability will be disclosed and tracked publicly. When requests are made without plans to publish, it can divert time and attention from advisories that are actively moving toward release. Aligning CVE requests with clear publication intent helps ensure that effort is focused on where it has the most immediate impact and keeps the system responsive for everyone.
Coordinate closely with maintainers and other researchers. High-quality advisory data depends on shared context. Aligning affected packages, version ranges, and fixes helps reduce ambiguity and conflicting information across sources. At this scale, small gaps in coordination can become large inconsistencies downstream.
Improve advisory quality by contributing pull requests to the Advisory Database. Every correction to version ranges, package mappings, or fixes improves the accuracy that developers rely on.
Recognize the scale of this ecosystem shift and take part in it. The increase in vulnerability reporting reflects real progress. More issues are being found, fixed, and disclosed than ever before. Maintaining quality at this scale depends on researchers, maintainers, and data consumers and producers working together toward the same goal.
Two years ago, the database published ~270 advisories per month.
In May 2026, it published over 1,500 while processing thousands of additional decisions across the system.
This reflects a broader shift:
That growth creates pressure on systems like ours. But it also represents meaningful progress.
Every advisory improves visibility. Every alert reduces risk.
We are scaling to meet that reality, and we will continue to share progress as we do.
The post Inside the Advisory Database and what happens when vulnerability volume breaks records appeared first on The GitHub Blog.
Continue reading on the original blog to support the author
Read full articleThis report highlights that while historical vulnerability backlogs are shrinking, new security threats and malware in open source ecosystems are increasing. Engineers must remain vigilant as the volume of new advisories rises, particularly in popular ecosystems like Maven, Go, and npm.
This update changes how developer data is handled for AI training. Engineers using individual tiers must decide whether to contribute their code patterns to improve Copilot's accuracy or opt out to maintain privacy, while enterprise users remain protected by default.
Supply chain attacks exploit trust in package managers and CI/CD. These updates disrupt the attack lifecycle—from initial account compromise and 'pwn requests' to credential exfiltration—by enforcing stricter defaults, read-only caches, and secretless publishing.
Automated update tools often pull malicious code before it can be vetted. A mandatory cooldown period significantly reduces the risk of supply chain attacks by allowing time for the community to identify and pull poisoned releases from public registries.
