Most open source advisories record a fixed version, but not all. In OSV exports from 19 October 2026, the share with no fixed version ranges from 4.6 percent for NuGet to 25.0 percent for crates.io, and 20.4 percent for npm. A missing field does not prove no patch exists, but it should change how you plan.
Method
We downloaded eight OSV ecosystem exports on 19 October 2026 and kept vulnerability advisories (IDs that do not start with MAL-), excluding withdrawn records. For each, we looked through every affected range for an event with a fixed value. If none had one, we counted the advisory as having no fixed version recorded.
Limits: an advisory that gives only a last affected version counts as no fix here, even if the maintainers shipped a patch under a new version. And a fix may exist in a form the record does not describe. So this is a measure of what the data says, not of what exists.
What the numbers say
| Ecosystem | Advisories | No fixed version recorded |
|---|---|---|
| NuGet | 1,142 | 4.6% |
| RubyGems | 1,091 | 6.1% |
| PyPI | 13,941 | 11.6% |
| Go | 9,464 | 12.2% |
| Packagist | 7,147 | 12.9% |
| Maven | 7,077 | 15.8% |
| npm | 7,447 | 20.4% |
| crates.io | 2,799 | 25.0% |
The spread is wide. In NuGet and RubyGems almost every advisory names a fix. In npm one in five does not, and in crates.io one in four.
We did not investigate causes. Possible reasons include abandoned packages, advisories filed before a fix, and records that give a last affected version instead.
What to do when there is no fix
A finding with no fixed version needs a different playbook from one with a patch. Work through these in order.
- Check upstream. Read the project's repository and release notes for a fix that the advisory has not caught up with.
- Check reachability. Does your code actually call the vulnerable function? If not, the practical risk may be low, and you should record that decision and its date.
- Mitigate. Configuration changes, input validation, network restrictions or feature flags can close the path without a new version.
- Replace. If the package is abandoned, plan a swap and set a deadline.
- Accept explicitly. If none of the above works, record who accepted the risk, why, and when it will be reviewed.
Avoid leaving the finding open with no owner. An unowned finding with no fix is how a backlog quietly fills.
Safeguard's reachability analysis helps with step 2, and policies can hold a no-fix finding for review instead of failing a build for something nobody can patch.
Try it yourself
Open the demo and look at how a finding with an available fix is presented compared with one without.
Click through it at your own pace, or open it full screen.
Quick check
Does a missing fixed version mean the project is abandoned?
No. It can also mean the advisory predates the fix or records only a last affected version. Check upstream before concluding anything.
Should I fail builds on findings with no fix?
Usually not by default. Hold them for review with an owner and a date, and fail the build for findings you can fix.
Sources
- OSV data sources and per-ecosystem downloads, fetched 19 October 2026
- OSV schema, fetched 19 October 2026
Last reviewed: 19 October 2026.
