Advisory output hits record levels as vulnerability volume outpaces curation

The GitHub Advisory Database published 1,560 reviewed advisories in May 2026 — more than five times its typical monthly output and the highest total in the database’s history. That record, however, was not enough to keep pace with incoming vulnerability reports.

Over the last several months, input has risen across all reporting channels at once: private vulnerability reports, repository advisories, and CVE requests. The result is a sustained shift in the operating scale of the entire vulnerability disclosure ecosystem, not a temporary spike.

The numbers behind the surge

Between March and May, the advisory team sustained more than 6,000 advisory decisions per month across updates, new publications, and inbound reviews — exceeding any prior three-month peak. Inflow accelerated across every source during that window:

  • Private vulnerability reports across the platform grew from roughly 550 per week in January to more than 3,000 per week through most of May.
  • Repository advisories rose from about 650 per week to more than 5,000 per week.
  • GitHub CNA CVE requests reached almost 4,000 in May alone, nearly 10 times year-over-year volume.
  • The CVE program has already published more than 30,000 CVEs in 2026.
  • More than 1.7 million repositories have enabled private vulnerability reporting.

Since mid-April, publication times have stretched beyond internal goals — first to roughly a week, then to multiple weeks for a meaningful share of advisories. That delay can widen exposure windows, and the team acknowledges timeliness as a core part of the database’s value.

What remains intact

Despite the backlog, data pipelines and publishing infrastructure have operated normally. Imports continue to run, data integrity holds, and advisories that reach reviewed status meet the same quality standard as before the surge. CVE assignment quality has also remained steady, with an assignment rate of 91–94% throughout the entire period — consistent with historical norms.

The bottleneck is throughput, not correctness. The validation, enrichment, and publishing pipeline is functioning but now operates beyond the volume and complexity it was designed to handle.

Why not every advisory is easy to process

Some advisories arrive in near-final form: the affected package is clearly named, the version range is documented, and the fix is tagged. A curator can validate and publish those in minutes. But a growing share of inbound advisories require substantial investigation:

  • Package disambiguation. An advisory that says “foo” does not identify whether that is foo on npm, python-foo on PyPI, or an unrelated foo on Maven. When upstream data omits the ecosystem, curators must determine it.
  • Version range reconstruction. Many advisories arrive with missing or inaccurate affected version ranges. Curators trace commits, changelogs, and tags to establish what releases are actually impacted.
  • Multi-ecosystem advisories. Projects that ship the same vulnerable logic to multiple registries — for example, a .NET package on NuGet and a JavaScript package on npm — require independent verification across each ecosystem.
  • Conflicting upstream data. When a CVE record, a maintainer’s advisory, and commit history disagree about the scope of a vulnerability, a curator must determine which source is correct.

Historically, straightforward advisories dominated the queue and absorbed the harder cases. Under surging volume, both types pile up, but complex ones take disproportionately longer — a compounding effect. The workload is not merely larger; it is materially harder per advisory.

What “reviewed” means in practice

A reviewed advisory is not a republished record. It represents a verification pass in which curators map the vulnerability to the correct ecosystem package, validate affected and fixed versions against release history, confirm upstream accuracy, check for duplication, and validate classification and scoring. That process is what allows downstream tooling to consume advisory data without additional validation.

Skipping verification to publish faster would multiply false positives at scale — a risk that can outweigh the cost of delay.

Current and planned responses

The advisory team is taking several steps to handle the new volume:

  • Better triage for community contributions. Submissions are now prioritized earlier, with high-quality contributions identified sooner and moved through the queue faster, while still meeting the same validation bar.
  • Scaled curation infrastructure. Backend capacity for sustained throughput has been increased, with ongoing modernization of the data infrastructure supporting analytics and queue management.
  • AI-assisted research tooling. Curators now have AI-powered assistance during the research phase. Curators still make every decision, but routine investigation can be completed faster.
  • Expanded automation. Extraction of data from upstream CVE records and handling of community contributions against already-reviewed advisories have been automated further, cutting time per decision without lowering quality.
  • Documentation and training. Operational documentation has been expanded so new team members reach proficiency faster and decisions stay consistent across the team.

Planned work focuses on reducing time-per-advisory for the most common cases, adding risk signals — such as package usage, evidence of active exploitation, and ecosystem impact — to review prioritization, improving upstream data validation so corrections happen closer to the source, and ongoing transparency about progress and setbacks.

Impact on consumers

For Dependabot users, existing alerts are unaffected. New advisories may trigger more slowly, with critical issues handled first. API and feed consumers will still see accurate reviewed data, while unreviewed advisories remain visible but not yet validated. Maintainers can expect repository advisories to continue flowing into the global database, with prioritization influenced by project impact and severity.

What makes a high-quality advisory

The GitHub Advisory Database relies on structured, complete data to function efficiently. Advisory curators review reports and map them to the correct ecosystems, package names, and version ranges. When that information is accurate, a report can move through curation in minutes. When it is incomplete, curators must reconstruct the missing pieces from source code, release history, and upstream signals—work that compounds quickly at current volume.

Submitters should include affected version ranges, root cause details, and clear reproduction steps. Beyond those basics, GitHub’s best practices guide covers ecosystem categorization and version formatting. A few additional recommendations improve the review process directly:

  • Use the registry package name. Advisory package names must match the registry, not the repository or project name. Downstream systems match advisories to dependencies using registry identifiers; a mismatch means alerts may never reach affected users.
  • List every affected package. Vulnerabilities often span multiple packages in one project. Since advisories are consumed at the package level, omitting a package leaves its users unprotected. Each affected package needs its own ecosystem, name, and version range.
  • Supply a full CVSS vector string. The Advisory Database supports CVSS 3.1 and 4.0. Severity labels like "High" are summaries; a complete vector string includes attack complexity, privileges, and user interaction. That structure supports consistent interpretation and automated prioritization. Use the official calculators and include the full vector.
  • Add a specific CWE classification. A CWE describes the underlying weakness—XSS, SQL injection, unsafe deserialization—in a form downstream tools can filter, compare, and apply policy against. The more specific the CWE, the more useful the advisory becomes for security teams.

Beyond data quality, coordination matters. CVE requests should align with an actual plan to publish; speculative requests divert attention from advisories close to release. Researchers and maintainers should align on affected packages, version ranges, and fixes before publication to avoid downstream inconsistencies. Even small coordination gaps scale into larger problems at current volumes. Corrections can also be submitted directly as pull requests to the Advisory Database, which improves the version ranges and package mappings that developers depend on.

The state of the database

Volumes have shifted dramatically. Two years ago, the database published about 270 advisories per month. In May 2026, it published more than 1,500 while processing thousands more decisions across the system. That growth reflects more repositories enabling responsible disclosure, more researchers reporting issues, and more maintainers publishing fixes. The ecosystem is moving toward greater transparency, and that progress puts operational pressure on the database—but it also means more visibility for vulnerabilities and better risk reduction downstream. The database is scaling to meet that reality.