Open Source Vulnerability Trends 2025: What the Data Actually Says

TL;DR

• GitHub published 19% more advisories for newly reported vulnerabilities in 2025, but fewer total advisories because they're running out of old unreviewed CVEs to backfill
• npm malware advisories jumped 69% year-over-year, driven by campaigns like SHA1-Hulud
• Cross-site scripting (CWE-79) remains the most common vulnerability type, but resource exhaustion and SSRF saw unusual spikes
• GitHub's CNA published 35% more CVE records in 2025, outpacing the overall CVE Project's 21% growth

The Big Picture

GitHub published 4,101 reviewed advisories in 2025. That's the fewest since 2021. On the surface, this looks like good news — maybe open source is finally getting more secure?

Not quite. The drop isn't because fewer vulnerabilities exist. It's because GitHub has nearly exhausted the backlog of old, unreviewed CVEs that predate the Advisory Database itself. When you isolate newly reported vulnerabilities from GitHub's active feeds, the number actually grew 19% year-over-year.

This matters for developers because it changes what you'll see in Dependabot alerts. You should get fewer notifications about ancient vulnerabilities and more about current threats. The data also reveals which vulnerability types are surging, how malware campaigns are evolving, and where the CVE ecosystem is headed.

The 2025 data set includes 4,101 reviewed advisories, 7,197 malware advisories, and 2,903 CVE records published through GitHub's CNA. That's enough signal to spot real trends.

How the Advisory Database Actually Works

GitHub's Advisory Database launched in 2019 as a curated list of known security vulnerabilities and malware affecting open source packages. It pulls from multiple sources: the National Vulnerability Database, security advisories from language ecosystems, and direct reports from maintainers.

The "unreviewed" label is misleading. Most unreviewed advisories have been examined by a curator and found not to affect any package in a supported ecosystem. They may never be fully reviewed because they're out of scope.

In 2025, GitHub reviewed 3,734 advisories from active feeds and only 367 from backfill campaigns. Compare that to 2024: 3,142 from feeds and 2,093 from backfill. The backfill work is winding down because there's less historical debt to clear.

The cumulative totals tell the story. By the end of 2025, the database contained 24,668 reviewed advisories, 20,649 malware advisories, and 283,447 unreviewed entries. That unreviewed pile is mostly noise — CVEs that don't map to supported ecosystems or lack enough detail to review.

If you find an unreviewed advisory that affects a supported package, GitHub wants to know. You can suggest edits directly through the database. In 2025, 675 community contributions improved the data quality.

Ecosystem Distribution and Vulnerability Types

The 2025 ecosystem breakdown looks similar to the overall database, with one exception: Go is overrepresented by 6%. That's due to internal campaigns to re-examine packages with inconsistent coverage.

Maven leads at 22.24% of 2025 advisories, followed by Composer at 19.40%, Go at 17.33%, Pip at 17.16%, and npm at 14.92%. Rust, Nuget, RubyGems, GitHub Actions, Erlang, and Swift make up the rest.

Cross-site scripting (CWE-79) remains the most common vulnerability type with 672 advisories in 2025. Path traversal (CWE-22) ranks second with 214. Incorrect authorization (CWE-863) jumped nine spots to third place with 169 advisories, but that's largely due to reclassification away from deprecated higher-level CWEs.

The real story is in the unusual spikes. Resource exhaustion (CWE-400 and CWE-770), unsafe deserialization (CWE-502), and server-side request forgery (CWE-918) all saw significant increases. CWE-770 (allocation without limits) jumped seven spots in the rankings and ten spots compared to the overall database.

The biggest quality improvement: advisories without any CWE dropped 85%, from 452 in 2024 to just 65 in 2025. CWE-20 (improper input validation) is still common, but now it's usually paired with more specific CWEs that describe the actual failure mode. That added specificity makes the data actionable for triage.

You can filter Dependabot alerts by CWE using auto-triage rules. If you're drowning in alerts, start by filtering out low-severity CWE-20 issues and focusing on deserialization, SSRF, and resource exhaustion bugs.

How to Prioritize What Actually Matters

GitHub provides two scoring systems: CVSS measures impact severity, and EPSS predicts exploitation likelihood in the next 30 days. Used together, they help you triage.

The 2025 data shows most vulnerabilities skew moderate to high on the CVSS scale. Only 475 advisories scored low, and just 392 scored critical. EPSS tells a different story: 1,872 vulnerabilities have very low exploitation probability, while only 11 critical-severity issues have high EPSS scores.

To validate these scores, GitHub compared them against CISA's Known Exploited Vulnerabilities catalog. Every exploited vulnerability scored at least moderate on CVSS. Most were critical or high. CVSS flagged more of the exploited vulnerabilities as critical, but it also flags far more vulnerabilities overall. EPSS had fewer false positives but missed some exploited bugs.

The takeaway: use both. Prioritize vulnerabilities that score high on CVSS and have elevated EPSS scores. If you're using GitHub Advanced Security, Dependabot already surfaces this data in alert views.

The npm Malware Surge

2025 was the worst year on record for npm malware. GitHub published 7,197 malware advisories, a 69% increase over 2024. That's the most since the initial historical release in 2022.

The spike was driven by large-scale campaigns like SHA1-Hulud, which flooded the npm registry with malicious packages. These campaigns use automated tooling to generate thousands of packages with similar names, hoping developers will mistype a dependency or fall for a typosquatting attack.

Dependabot now detects malware in npm dependencies and alerts you when your repositories depend on packages with known malicious versions. This feature shipped in March 2026, but it's retroactive — it scans against the full malware advisory database.

If you're not using Dependabot malware alerts yet, enable them. The npm ecosystem is under sustained attack, and manual review doesn't scale.

GitHub's CNA Growth

GitHub's CVE Numbering Authority published 2,903 CVE records in 2025, a 35% increase over 2024. That outpaced the overall CVE Project's 21% growth. If the trend continues, GitHub will publish over 50% more CVEs in 2026.

The quarterly breakdown shows consistent 10-16% growth: 598 CVEs in Q1, 660 in Q2, 762 in Q3, and 883 in Q4. That acceleration suggests more maintainers are discovering the service.

2025 was the first year GitHub published more CVEs for vulnerabilities that don't affect supported ecosystems than those that do. That's because any maintainer on GitHub can request a CVE, even if they don't publish to npm, PyPI, Maven, or another supported registry.

679 new organizations used GitHub's CNA services for the first time in 2025, a 20% increase. The top publisher was LabReDeS (WeGIA) with 130 CVEs, followed by XWiki with 40, Frappe with 28, and Discourse with 27.

Requesting a CVE through GitHub is free and fast. You do it directly from a repository security advisory. GitHub handles the curation and publication. If you're maintaining an open source project and discover a vulnerability, use this instead of navigating the CVE Project's bureaucracy yourself.

What This Changes For Developers

The shift from backfill to real-time advisory review means Dependabot alerts will feel more relevant. You'll see fewer notifications about CVEs from 2018 and more about vulnerabilities disclosed in the last 90 days.

The CWE tagging improvements make it easier to filter alerts by vulnerability type. If your application doesn't deserialize untrusted data, you can safely ignore CWE-502 alerts. If you're not making outbound HTTP requests based on user input, SSRF bugs (CWE-918) are lower priority.

The malware surge in npm is a forcing function. If you're not scanning dependencies for malicious code, you're exposed. Dependabot malware alerts are a baseline defense, but they're reactive. Consider adding egress firewalls and dependency locks to your CI/CD pipeline to block malicious packages before they run.

The growth in GitHub's CNA means more vulnerabilities are getting CVE IDs. That's good for transparency, but it also means more alerts. Use CVSS and EPSS scores to triage. Focus on high-impact, high-likelihood issues first.

How to Contribute

You don't need to be a security researcher to improve the Advisory Database. If you spot an unreviewed advisory that affects a package you use, suggest an edit. If you see incorrect severity scores or missing affected versions, fix them. GitHub reviews all contributions, and your edits help everyone.

If you maintain an open source project, create a security policy and enable private vulnerability reporting. This makes it easier for researchers to report issues to you without broadcasting them publicly. When you fix a vulnerability, request a CVE through GitHub's CNA. It's faster than going through MITRE or another CNA, and it ensures the CVE gets published with accurate data.

Enable Dependabot on all your repositories. It's free for public repos and included with GitHub Advanced Security for private repos. Configure auto-triage rules to filter out noise and focus on vulnerabilities that matter to your stack.

The Bottom Line

Use this data to tune your Dependabot alerts. Filter by CWE to ignore vulnerability types that don't apply to your application. Prioritize high CVSS + high EPSS scores. Enable malware scanning if you use npm.

Skip the backfill advisories — GitHub's already done that work. Focus on newly reported vulnerabilities from the last 90 days. Those are the ones attackers are actively exploiting.

The real risk is in npm malware campaigns. If you're not scanning for malicious dependencies, you're exposed. The real opportunity is in GitHub's CNA growth. If you maintain open source software, requesting a CVE through GitHub is now the fastest path to publication. Use it.

Source: GitHub Blog