22,032 CVEs have been filed against GitHub-hosted code so far in 2026, more than in all of 2025. Half of them were written by someone other than the project. Here is who, what those records look like, and how to write the next one yourself.
When I recently proposed a question to Cloud Security Partners about exactly how mature an open-source project needs to be before it starts filing CVEs, the data revealed a stark reality: nobody in this system is waiting for a project to be ready. So far in 2026, 5,605 GitHub repositories have had a CVE published against them. For 3,189 of those projects (57%), it is the only CVE they received this year, and for 2,572 (46%) it is the only one they have ever received. But the most revealing metric isn't the volume, it's the author. Only 6.9% of those repositories had the record written by their own or their ecosystem's CNA. Another 37.5% asked GitHub to file it for them. For the remaining 3,116, more than half, every record was written by someone who does not maintain the code: independent researcher CNAs, MITRE, or a distribution.
TL;DR
The maturity question has the gate in the wrong place. Getting a CVE assigned to your project takes a GitHub account and a draft security advisory. You need no CNA, no foundation and no security team. What takes maturity is being on the receiving end of a CVE you didn't write, and that is the normal case. Of the 22,032 CVEs published so far in 2026 that reference a GitHub repository, GitHub's CNA filed 44% at the code owner's request, researcher CNAs filed 35%, MITRE filed 10%, and the project's own or its ecosystem's CNA filed 7%.
Put the other way: the project wrote or asked for 51% of them and someone else wrote 49%. In 2025 the project's share was 27%. The records strangers write arrive with no version range and a severity score nobody at the project chose. The fix is the same small set of things every guide already asks for: a SECURITY.md, private reporting turned on, a human who answers, and version numbers you can put in a range.
All statistics exclude REJECTED records and count by publication date. 2026 figures run January 1 to September 7 and are set against full-year 2025 only where the partial year is already larger. Data collected 2026-09-07.
Key Statistics at a Glance
"References a GitHub repository" means a reference or collection URL in the CNA's own part of the record points at github.com/owner/repo. That is a floor. MITRE records that cite only a project homepage are not counted, so the real share of CVEs about GitHub-hosted code runs higher.
Who Is Filing CVEs Against Your Code
The chart is the post. In no year has a project's own CNA filed more than one in ten of the CVEs about its code. Count the records the code owner requested through GitHub as the project's too, which they are, and the project's share is 51% this year. It was 24% in 2023, 26% in 2024 and 27% in 2025. The rest, half this year and nearly three quarters last year, was written by someone who does not maintain the code.
Worth being precise about the researcher bar. So far in 2026, VulDB has filed 3,634 CVEs that reference a GitHub repository and VulnCheck 3,427. Together that is more than four times what every project-run and ecosystem CNA filed combined (1,616). Both CNAs' scope on cve.org is any vulnerability not covered by another CNA. If your project isn't a CNA and you didn't ask GitHub, anyone with a valid scope can write the record about your code. Counted by repository rather than by record, more projects got their 2026 CVE from a researcher CNA (2,315) than from their own maintainer through GitHub (2,114), and 858 more got it from MITRE.
The 7% is worth a sentence too, because it is moving. In February it was 2.4% of the month's GitHub-referencing CVEs; by June it was 9.9% and it has held near 10% since. Almost none of that is small projects filing for themselves. It is three foundations that became CNAs in 2025 filing for their members: the Erlang Ecosystem Foundation (259 records this year), the CPAN Security Group (157) and OpenJS (106). That is the "ask your ecosystem's CNA" path working, and it is the one path in this post that scales past one maintainer.
The second chart is the trend underneath. MITRE's output as the CNA of Last Resort fell every year from 7,730 in 2019 to 5,203 in 2025, and stands at 2,918 for 2026 so far. GitHub's CNA went from 26 to 2,866 in the same window, then published 9,599 in the first eight months of this year. The code-owner path is now the largest single source of open source CVEs. The 2026 section below covers why this year looks like that.
What the Record Looks Like When a Stranger Writes It
I serve on the CVE Program's Quality, Automation and Consumer working groups, so this is the part of the data I spend the most time in. Nothing here is a program position.
What a 2026 CVE record arrived with, by who assigned it
Three more things about the MITRE column. The vendor field reads "n/a" on 86% of those records. The CVSS score, where one exists, was added afterwards by the CISA ADP on 82% of them. And of the MITRE records about GitHub repositories published from 2023 through September 2026, 245 of 12,681 (1.9%) carry the disputed tag. The GitHub CNA's count for the same window is zero of 16,299. Across the whole CVE List, 1,365 of the 1,498 disputed records are MITRE's.
A disputed tag is what a maintainer gets after the fact, instead of the phone call before it.
Downstream, none of this is cosmetic. Trivy and Grype key on the CVE ID and fall back to NVD for severity. FedRAMP requires the CVE ID and the NVD base score in machine-readable findings. So a MITRE-filed record about your project reaches your users' scanners with a stranger's description, no version range, and a score nobody at the project chose.
The projects that later took over their own CVEs show what the before looks like. I matched records on each project's own domain in the references, so these are floors:
The ip npm package is the version of this that made the news. In June 2024 a CVE against it was published at 9.8 CRITICAL without the maintainer's involvement. He archived the repository. His words: "Someone filed a dubious CVE about my npm package, and then I started getting messages from all people getting warnings from 'npm audit.'" GitHub lowered the severity to Low on his feedback and he un-archived it about a week later. The CVE had already done a week of work in every dependency scanner on earth.
How to File One Yourself
Three paths exist for a project that is not a CNA. Most readers need the first one.
The GitHub path, as the docs describe it:
- Turn on private vulnerability reporting. The report reaches you instead of your public issue tracker. This is free and takes one checkbox.
- Open a draft security advisory. Fill in the affected version range, the patched version, the CWE and a severity. The form is why GitHub CNA records score 100, 100 and 100 on completeness this year: it does not let you skip.
- Request a CVE. GitHub reviews the request. The ID is reserved and nothing is public. From the docs: "Requesting a CVE identification number doesn't make your security advisory public."
- Ship the fix, then publish the advisory. GitHub publishes the CVE record. The GHSA and CVE identifiers alias each other in OSV, Trivy and Grype, so your users' tooling sees a single vulnerability.
- If another CNA's scope covers you, GitHub will not assign and will tell you who to ask. Apache and Eclipse projects, for example, go through their foundations.
Three rules apply to whoever files. A CVE record "MUST NOT be the first Public Disclosure of a Vulnerability" (CNA Rules v4.2.0, 5.3.1), so the advisory publishes with or after the fix, never before. One CVE per vulnerability: the program said in June 2026 that it "does not support assigning a single CVE ID to multiple distinct vulnerabilities." And the record needs a public reference other than itself.
GitHub's own advice since 2022 has been to "always request a CVE and publish an advisory, even for very low severity vulnerabilities." I'd put it more bluntly. The CVE is the coordination handle every downstream tool uses. Withholding it leaves the bug the same size and hides it from the people patching.
What You Need Before the First Report Arrives
Four things, and none of them is a security team. A published way to report (the OpenSSF Best Practices Badge criterion reads "The project MUST publish the process for reporting vulnerabilities on the project site"). A private channel, which on GitHub is the checkbox from step 1. A human who answers within 14 days. That is the badge's response criterion, and the CNA rules ask the same of CNAs: "Automated responses do not qualify."
And version numbers good enough to write "affected < 4.2.1", because 100% of GitHub CNA records this year carry a range and 14% of MITRE's do. Most projects don't have these. In the 2022 OpenSSF Scorecard sweep, 3.2% of 832,422 npm packages and 2.5% of 191,483 PyPI packages had a security policy file. In a 2025 study of 2,581 projects that had already been the subject of a security advisory or a bounty report, 76.1% still had private vulnerability reporting turned off. The projects that lack these things are not too immature to file CVEs. They are too immature to be filed against, and that is most of them.
2026 Is Not Waiting Either
Through September 7, 59,817 CVEs have been published in 2026, against 48,153 in all of 2025. GitHub's CNA accounts for 9,599 of them, against 2,866 for all of last year. GitHub's explanation, in its June 29 post, is demand: private vulnerability reports rose from about 550 a week in January to more than 3,000 a week in May, and CNA CVE requests reached almost 4,000 in May alone, roughly ten times the year before. GitHub met it with a larger curation team and AI-assisted review tooling. No scope changed and no policy changed.
Their line: "This is not a localized surge. It reflects structural change across the vulnerability disclosure ecosystem." The queue shows it: the median GitHub CNA record went from reservation to publication in 7 days last year and 11 days this year, and the share published within two weeks fell from 75% to 55%.
The CVE Program's own Q1 report credits "AI-driven vulnerability discovery and requests." The reports are coming from tools now, about code the maintainer may not have touched in years. Full disclosure: I co-authored the FIRST forecast update in June that revised the 2026 total to about 66,000, so I have a stake in the number being right.
There is also a date. The EU Cyber Resilience Act's Article 14 reporting obligations apply from 11 September 2026, four days after I pulled this data. Open source stewards under Article 24 have to document "an effective handling of vulnerabilities." Stewards can't be fined. The manufacturers downstream of them can, and the first thing those manufacturers will ask a project for is the CVE ID.
If You Are Already Getting a Dozen a Year From Strangers
Then, and only then, read about becoming a CNA. The test in the rules is procedural: a public disclosure policy, an advisories page, two human contacts, a scope statement, a Root sponsor (Red Hat is the recommended Root for open source), a minimum of four weeks, and no fee. What it buys is the first right of refusal, which the program's own blog calls "the first opportunity to not assign," plus the authority to reject and dispute.
The workload is smaller than people assume: the median CNA tagged open source published 10 records in the last twelve months, and 32 of 143 published none. curl, a year in: "The actual being a CNA part is a low friction and low maintenance role." The better version of this for most projects is the one the Erlang, Perl and JavaScript foundations built in 2025: one CNA for the ecosystem, filing for everyone in it. Everyone else should stop at the GitHub form.
What To Do With This
If you maintain a project with users who are not you: turn on private vulnerability reporting, write the SECURITY.md, decide who reads the inbox. When a real report lands, draft the advisory and request the CVE yourself. It's free, it takes about two weeks this year, and the record will carry a version range and a score you chose.
If you run AppSec and consume open source: about half of this year's CVEs against GitHub-hosted code were written by someone who does not maintain it, and last year it was nearly three in four. Read the assigner field. A MITRE record with vendor "n/a", no version range and an ADP-supplied score is a different object from one the maintainer wrote, and your scanner treats them identically.
The vulnerability disclosure ecosystem does not check your contributor count or wait for you to stand up a security team. For 3,116 repositories so far in 2026, every single CVE record was published by someone who does not maintain the project.
Getting ahead of that does not require an enterprise apparatus. It takes a single repository checkbox and a draft form. Someone is going to describe your bug to downstream scanners; you might as well be the one choosing the version numbers.
Methodology and Reproducibility
- CVE List V5, the 2026-09-07_all_CVEs_at_midnight.zip release from CVEProject/cvelistV5 (tag cve_2026-09-07_1300Z). 386,996 records: 368,699 PUBLISHED, 18,297 REJECTED. All counts are of PUBLISHED records by datePublished. 2026 figures cover January 1 to September 7.
- CNA partner list: CNAsList.json from the CVEProject/cve-website repository, fetched 2026-09-07, 544 entries. Assigner groups use the program's own type tags; "project or ecosystem CNA" means a CNA carrying the Open Source tag that is not GitHub, MITRE, a Linux distribution, or a researcher, CERT or bug-bounty CNA. The Open Source tag also covers vendors that ship open source (Oracle and Chrome carry it), so that bar is a ceiling.
- "References a GitHub repository" means any reference URL or collectionURL in the CNA container matching github.com/owner/repo. "Affected version range" means a lessThan or lessThanOrEqual bound, a text range such as "< 4.2.1", or an explicit unaffected version.
- 63 assigner short names in the CVE List have no entry in the current partner list (renamed or departed CNAs). They are counted in totals and excluded from CNA-level tables.
- Data collected and analyzed on 2026-09-07.
About the Author
Jerry Gamblin is an industry-recognized security leader whose work bridges classic machine learning and emerging AI, from the statistical models that turn massive datasets into actionable intelligence to the shift toward agent-native security architectures. He is the founder of RogoLabs, an open-source lab that audits the global vulnerability infrastructure, where he builds and maintains tools like CVE.icu, VulnRadar, and CVEForecast to help the community navigate the "Vulnerability Anarchy" of the post-NVD era. A speaker, researcher, and builder who has presented at DEF CON and contributes to several CVE Program working groups, he is focused on building a more resilient, data-driven future for cybersecurity.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
