This report highlights that while historical vulnerability backlogs are shrinking, new security threats and malware in open source ecosystems are increasing. Engineers must remain vigilant as the volume of new advisories rises, particularly in popular ecosystems like Maven, Go, and npm.
GitHub published 4,101 reviewed advisories in 2025. This is the fewest number of reviewed advisories since 2021. Does this mean open source is shipping more secure code? Let’s dig into the data to find out.
Fewer advisories reviewed doesn’t mean fewer vulnerabilities were reported. The drop is because GitHub reviewed far fewer older vulnerabilities. When you look only at newly reported vulnerabilities from our sources, GitHub actually reviewed 19% more advisories year over year.
So why the change? Quite frankly, we are running out of unreviewed vulnerabilities that are older than the Advisory Database. At the same time, the number of newly reported vulnerabilities hasn’t dropped.
It’s also worth clarifying that “unreviewed” in the database can be misleading: most advisories marked unreviewed have already been looked at by a curator and found not to affect any package in a supported ecosystem, so they may never be fully reviewed.
This means that you should be receiving fewer brand-new Dependabot alerts about old vulnerabilities.
Note: If you find an unreviewed advisory that affects a supported package, please let us know so we can get it reviewed!
The distribution of ecosystems in advisories reviewed in 2025 is similar to the overall distribution in the database, with the exception of Go. Go is overrepresented in 2025 advisories by 6%. This is largely due to dedicated campaigns to re-examine potentially missing advisories found through an internal review for packages where we had inconsistent coverage.
| Rank | Common Weakness Enumeration (CWE) | Number of 2025 Advisories* | Change in Rank from 2024 | Change in Rank from the Overall Database |
|---|---|---|---|---|
| 1 | CWE-79 | 672 | +0 | +0 |
| 2 | CWE-22 | 214 | +2 | +1 |
| 3 | CWE-863 | 169 | +9 | +8 |
| 4 | CWE-20 | 154 | +1 | +1 |
| 5 | CWE-200 | 145 | -2 | -1 |
| 6 | CWE-400 | 144 | +4 | +0 |
| 7 | CWE-770 | 136 | +7 | +10 |
| 8 | CWE-502 | 134 | +5 | +1 |
| 9 | CWE-94 | 119 | -3 | -1 |
| 10 | CWE-918 | 103 | +5 | +8 |
* An advisory may have more than CWE. For example, an advisory might have both CWE-400 and CWE-770. It would then count for both.
As usual, cross-site scripting (CWE-79) is by far the most common vulnerability type. However, there are significant changes in the following areas. Resource exhaustion (CWE-400 and CWE-770), unsafe deserialization (CWE-502), and server-side request forgery (CWE-918) were unusually common in 2025. CWE-863 (“Incorrect Authorization”) saw a significant jump, but that is largely due to reclassification away from CWE-284 (“Improper Access Control”) and CWE-285 (“Improper Authorization”), which are higher level CWEs that the CWE program discourages using.
One of the biggest quality improvements in 2025 was more specific, more consistent CWE tagging. Advisories without any CWE dropped 85% (from 452 in 2024 to 65 in 2025). CWE-20 (“Improper Input Validation”) is still common, but in prior years it was often the only CWE listed on an advisory.
In 2025, advisories far more often list CWE-20 plus one or more additional CWEs that describe the concrete failure mode. This added specificity makes the data more actionable for triage, prioritization, and remediation.
To find out how to filter Dependabot alerts by CWE, see our documentation on auto-triage rules.
We provide two scoring systems for prioritization:
Together, they can give you a head start on your risk assessment process.
As you can see, when considering impact, most vulnerabilities skew moderate to high of the impact range. Low-impact vulnerabilities are likely more common than the CVSS data suggests but are often not considered worth the time and effort for researchers and maintainers to report. The EPSS scores for moderate to high impact vulnerabilities support this decision.
So should you trust the EPSS or CVSS scores? To judge that, let’s look at how they match up to vulnerabilities in CISA’s Known Exploited Vulnerabilities Catalog. The exploited vulnerabilities are at least scored moderate, and most are critical or high. While CVSS has more of the exploited vulnerabilities as critical, it also has far more vulnerabilities in the range in general. Combining the two can help you prioritize which vulnerabilities to address to prevent exploitation.
2025 was a huge year for npm malware advisories. Due to large malware campaigns, such as SHA1-Hulud, GitHub saw a 69% increase in published malware advisories compared to 2024. This is the most malware advisories GitHub has published since our initial release of historical malware when we added support in 2022.
You can receive Dependabot alerts when your repositories depend on npm packages with known malicious versions. When you enable malware alerting, Dependabot matches your npm dependencies against malware advisories in the GitHub Advisory Database.
2025 was a big year for the GitHub, Inc. CNA. We saw a 35% increase in published CVE records, outpacing the overall CVE Project’s increase of 21%.
In fact, we saw 10 to 16% growth every quarter. If this trend continues, GitHub will publish over 50% more CVEs in 2026.
You can help make that a reality by requesting a CVE from us the next time you publish a repository security advisory about a vulnerability!
Every year, GitHub sees more organizations use its CNA services. 2025 is no exception with a 20% increase in new organizations requesting CVE IDs.
Unlike reviewed global advisories, which are always mapped to packages in ecosystems we support, any maintainer on GitHub can request a CVE, even if they don’t publish that package to a supported ecosystem. In fact, 2025 is the first year that GitHub has published more CVEs from organizations that do not use a supported ecosystem than those that do.
We would like to thank all 987 organizations that published CVEs with us in 2025 and highlight the top 10 most prolific organizations.
| Top 10 organizations using the GitHub CNA | |
|---|---|
| Organization | Number of 2025 CVEs |
| LabReDeS (WeGIA)* | 130 |
| XWiki | 40 |
| Frappe | 28 |
| Discourse | 27 |
| Enalean | 27 |
| FreeScout* | 27 |
| DataEase | 26 |
| Nextcloud | 25 |
| GLPI | 24 |
| DNN Software* | 23 |
* Organizations that published CVEs through GitHub for the first time in 2025
The data from 2025 shows incredible growth:
These numbers represent real security improvements for millions of developers.
You can be part of this in 2026. Here’s how:
Publishing CVEs shouldn’t be complicated. Request a CVE directly from your repository security advisory, and we’ll take care of curating and publishing it for you. It’s free, it’s fast, and it helps the entire ecosystem understand and respond to vulnerabilities.
Found an unreviewed advisory affecting a supported package? See incorrect severity scores or missing affected versions? Suggest edits. Your edits will be reviewed by the Advisory Database team and ultimately, will help make the database more accurate for everyone. In 2025, 675 contributions from the community improved the quality of this data for the entire software industry!
The most direct impact you can have is protecting your own code. Enable Dependabot to automatically receive security updates and explore GitHub Advanced Security for comprehensive protection.
Let researchers know how to report to you and what you will and will not accept by creating a security policy for your repository. Enable private vulnerability reporting to make the coordination process smooth and secure.
Let’s make 2026 even better. See you in next year’s review! 🚀
The post A year of open source vulnerability trends: CVEs, advisories, and malware appeared first on The GitHub Blog.
Continue reading on the original blog to support the author
Read full articleThis update changes how developer data is handled for AI training. Engineers using individual tiers must decide whether to contribute their code patterns to improve Copilot's accuracy or opt out to maintain privacy, while enterprise users remain protected by default.
This incident highlights how minor sanitization failures in internal protocols can lead to critical RCE. It underscores the importance of defense-in-depth, showing how removing unused code paths and robust telemetry can mitigate risks and verify the absence of exploitation.
Circular dependencies can paralyze recovery during outages. By using eBPF and cGroups, engineers can enforce network isolation for deployment scripts without impacting production traffic, ensuring that critical infrastructure remains deployable even when primary services are offline.
Legal and policy shifts regarding copyright liability and age assurance directly impact how engineers build, share, and secure software. These updates ensure that neutral infrastructure and security research remain protected from broad regulations that could stifle open-source innovation.
