GitHub's Advisory Database published 1,560 reviewed advisories in May 2026. That is more than five times the typical monthly output and the highest in the database's history.
And it still wasn't enough.
The team published a long-form post on June 29 laying out what is happening, what is breaking, and what the community can do to help. The short version: vulnerability inflow has structurally changed. Review times have stretched. Quality has held. Bottlenecks are showing.
What the numbers look like
The May surge is not an isolated spike. From March through May, GitHub sustained more than 6,000 advisory decisions per month. That includes updates, new publications, and reviews of inbound reports. It exceeded any prior three-month peak.
Input accelerated across every source:
- Private vulnerability reports across the platform jumped from roughly 550 per week in January to more than 3,000 per week for most of May
- Repository advisories scaled from roughly 650 per week to more than 5,000 per week
- GitHub CNA CVE requests reached almost 4,000 in May alone, nearly 10x year-over-year
- The CVE program has already published more than 30,000 CVEs in 2026
- More than 1.7 million repositories have enabled private vulnerability reporting
These are not numbers that look like a temporary spike. They look like a new operating scale for the vulnerability disclosure ecosystem.
What is breaking
Since mid-April, GitHub has not consistently met its internal goals for publication. Processing times extended first to about a week, then to multiple weeks for a meaningful share of incoming reports.
That matters. Longer publication windows mean longer exposure windows for users. A vulnerability that sits in the queue for three weeks is a vulnerability that ships in three weeks more containers, three weeks more production deploys, three weeks more potential incidents.
CVE assignment quality has held. The assignment rate stayed between 91 and 94 percent through the entire surge, consistent with or better than historical norms. So the work being done is good. There is just a lot more of it, and the queue is growing.
What is still working
A few pieces have held up:
- Data pipelines and publishing infrastructure kept operating
- Imports kept running
- Data integrity stayed intact
- Published advisories remained accurate
- CVE assignment quality stayed strong
- Existing alerts in customer repositories continued firing as designed
This is not a "the whole system is collapsing" story. It is a "the inflow has outgrown the review capacity" story. Subtle difference, but it changes the response.
What is driving the surge
Three forces compound.
First, the volume of software being written is up. More code, more dependencies, more surface area. Each piece of code is a potential source of vulnerabilities. The numbers scale with the ecosystem.
Second, automated vulnerability discovery has matured. AI-assisted fuzzers, AI-assisted static analysis, and AI-assisted auditing surface more real issues faster. The signal-to-noise ratio is better than it was five years ago, so more reports actually get filed.
Third, disclosure culture has changed. Researchers, maintainers, and platforms have built better reporting pipelines. Private vulnerability reporting on GitHub crossed 1.7 million enabled repos. That is a sign of trust in the system, and trust brings volume.
What engineering teams should do
For most engineering teams, the practical response is not "wait for GitHub to scale." It is to take ownership of your own vulnerability surface.
First, enable Dependabot alerts and security updates if you have not. The plumbing exists. It works.
Second, treat high-severity advisories as same-day work. The queue is growing, but you should not wait for GitHub to publish before you patch known critical issues in your stack. Subscribe to vendor security advisories directly. Monitor your own dependencies.
Third, invest in a software bill of materials. SBOMs let you answer "are we affected by CVE-2026-XXXX?" in seconds, not days. The harder the inflow gets, the more SBOMs pay off.
Fourth, build a triage playbook. Which severities get patched within 24 hours. Which get a week. Which can wait for the next sprint. Document it. Run drills. When volume is high, the teams with a playbook outpace the teams improvising.
Fifth, consider private vulnerability reporting for your own repos. Even small open-source projects benefit from a clean intake channel. The 1.7 million repos with PVR enabled are not all big names. They include lots of mid-sized libraries where researchers want a way to report responsibly.
The takeaway
Vulnerability volume is now structurally higher than it was two years ago. The advisory databases, the CNAs, and the disclosure platforms are scaling to keep up. Some of them are keeping up better than others.
For engineering teams, the lesson is that vulnerability management is no longer a quarterly checklist. It is an operational function with real workload. Build the muscle. Automate the boring parts. Own the triage. Let the databases do what they are good at, and do not outsource your own risk posture to them.
The May numbers were a record. They will probably be broken later this year. Plan accordingly.
Sources
- Inside the Advisory Database and what happens when vulnerability volume breaks records (GitHub Blog, June 29, 2026)
