@osbytesTL;DR
- GitHub published a status post today on the GitHub Advisory Database: 1,560 reviewed advisories in May 2026, roughly five times a typical month (~270/month two years ago), while the team processed 6,000+ advisory decisions per month from March through May.
- Inflow jumped across every channel: private vulnerability reports from ~550/week in January to 3,000+/week in May; repository advisories from ~650/week to 5,000+/week; GitHub CNA CVE requests hit ~4,000 in May alone (~10× year-over-year).
- Reviewed advisories still pass human validation; the pain is publication lag (first ~1 week, then multi-week for a growing share). Dependabot's existing alerts keep working; new alerts may arrive slower, with critical issues prioritized.
- If you file advisories: ship registry-accurate package names, complete version ranges, CVSS vectors, and CWEs — incomplete upstream data is what turns a five-minute review into a multi-day archaeology dig.
GitHub's security blog rarely names a capacity crisis this plainly. Today's post does, and the numbers are worth treating as infrastructure weather, not a one-off press release.
The queue grew faster than the publish rate
Two years ago the GitHub Advisory Database averaged about 270 reviewed advisories per month. In May 2026 it published 1,560 — the highest monthly total on record. That headline understates the load: GitHub also logged more than 6,000 advisory decisions per month from March through May (updates, new publishes, inbound triage), above any prior three-month peak.
The inflow curve is what changed the operating model:
| Channel | Earlier baseline | May 2026 scale |
|---|---|---|
| Private vulnerability reports (platform-wide) | ~550/week (January) | 3,000+/week |
| Repository advisories | ~650/week | 5,000+/week |
| GitHub CNA CVE requests | — | ~4,000 in May (~10× YoY) |
| CVE program (ecosystem-wide, cited for context) | — | 30,000+ CVEs published in 2026 so far |
| Repos with private vulnerability reporting enabled | — | 1.7M+ |
GitHub says imports still run, data integrity is intact, and reviewed advisories meet the same bar as before. CVE assignment quality held at 91–94% through the surge. The failure mode is throughput: since mid-April the team has not consistently hit internal publication goals. Longer queues mean longer exposure windows for issues sitting in "submitted but not yet reviewed" state.
That distinction matters if you consume GHSA data or Dependabot alerts. Reviewed is not "reposted the CVE JSON." Curators map packages to the correct registry identity, reconstruct affected and fixed version ranges against real release history, reconcile conflicting upstream records, and dedupe. Skipping that work would push false positives into Dependabot at scale — which GitHub argues is worse than delay.
Why some advisories eat a week
Not every submission costs the same. A well-formed repo advisory with the right npm/PyPI/Maven name, a sane version range, and a tagged fix can clear in minutes.
The growing tail is harder:
- Package disambiguation when upstream says
foobut three unrelatedfoopackages exist across registries. - Version range reconstruction when the CVE record, maintainer note, and git history disagree.
- Multi-ecosystem packages where one logical bug spans, say, a NuGet and an npm artifact with different release cadences.
- Conflicting upstream data that forces a human to pick the truth.
When volume was lower, the hard cases were absorbable noise. At May's scale both easy and hard cases arrive together; the hard ones compound because they block curator attention disproportionately. GitHub's post is explicit that the mix shifted, not just the count.
What changes for builders
Dependabot users: existing alerts are unaffected. New advisories may take longer to surface; critical-severity work is prioritized upstream of the long tail. If your patch cadence assumes GHSA publication within 48 hours of a maintainer merge, bake in slack.
API and feed consumers: reviewed records remain the trust anchor. Unreviewed advisories may be visible but are not validated to the same standard — treat them accordingly in automation.
Maintainers and researchers filing PVR or repo advisories: the post doubles down on concrete fields that shrink review time:
- Package name exactly as it appears in the registry, not the GitHub repo slug.
- Every affected package listed separately with its own ecosystem and version range.
- Full CVSS 3.1 or 4.0 vector string, not just a severity label.
- Relevant CWE classification.
- Request CVE IDs only when you intend to publish; orphan CVE requests steal queue capacity.
GitHub also says it deployed AI-assisted research tooling for curators (humans still decide), expanded automation on predictable extraction tasks, and is investing in risk-based prioritization signals (package usage, exploitation evidence, ecosystem impact). Those are throughput plays, not a promise to drop the review bar.
The wider picture
The post frames May as structural, not a spike: more repos enabled private disclosure, more researchers filed, more maintainers published fixes, and the CVE program itself is running hotter. GitHub is one choke point in a pipeline that now moves faster than any single curator fleet was sized for.
If you only read release notes, the actionable read is narrower: your advisory hygiene directly affects how long everyone waits. A missing ecosystem tag or hand-wavy version range is not a paperwork annoyance; at this scale it is queue debt that shows up as delayed Dependabot coverage for downstream repos you may never meet.