GitHub's vulnerability advisory pipeline broke its own records in May and still couldn't keep up.
From March through May 2026, the GitHub Advisory Database processed more than 6,000 advisory decisions per month — the highest three-month stretch in its history. May alone saw 1,560 reviewed advisories published, five times the typical monthly output. The inflow driving that number was even more striking: private vulnerability reports jumped from around 550 per week in January to more than 3,000 per week by May, repository advisories scaled from roughly 650 to more than 5,000 per week, and CVE requests to GitHub's CNA nearly hit 4,000 for the month — close to 10x year over year. Since mid-April, GitHub has not consistently met its internal publication timelines, with processing times stretching from about a week to multiple weeks for a meaningful share of submissions.
The backlog isn't just a volume problem — it's a complexity one. Many advisories arrive incomplete: no ecosystem specified, no version range, conflicting data between the CVE record and the maintainer's own changelog. Each of those requires a curator to trace commits and release history by hand. When easy and hard advisories pile up together, the hard ones compound the delay disproportionately. GitHub is deploying AI-assisted research tooling to speed up the routine parts, but curators still make every call — skipping human validation to clear the queue faster would trade short-term speed for long-term data quality that downstream security tools depend on.
This isn't a GitHub-specific strain. The CVE program has already published more than 30,000 CVEs in 2026, and the broader disclosure ecosystem is structurally busier than it was even a year ago. GitHub's 91-94% CVE assignment rate has held steady through the surge, which is reassuring — but a database that can't publish fast enough still widens exposure windows, even if the data it eventually publishes is accurate. Speed and quality are both part of the product, and right now only one of them is holding.