Across 44,476 OSV advisory records, between 74% and 95% of each ecosystem's records name at least one fixed version, with NuGet highest (95%) and crates.io lowest (74%). A record with no fixed version is not always unfixable: the field may be missing, or the project may have no patched release yet.
Method
We downloaded the per-ecosystem OSV dumps on 19 October 2026 and set aside the malware records (IDs starting MAL). For each remaining record we checked whether any affected range contained an event of type "fixed". That is a yes or no per record. We did not check that the named version exists, installs or actually removes the flaw. Withdrawn records are included, which is a small share, and records that cover several packages count once.
The shares
| Ecosystem | Records | With a fixed version | Share |
|---|---|---|---|
| NuGet | 1,183 | 1,123 | 95% |
| RubyGems | 1,160 | 1,072 | 92% |
| Go | 9,641 | 8,388 | 87% |
| PyPI | 14,533 | 12,566 | 86% |
| Maven | 7,190 | 6,037 | 84% |
| npm | 7,846 | 6,144 | 78% |
| crates.io | 2,923 | 2,166 | 74% |
Why a record might have no fixed version
Several different situations produce a missing field:
- No patch exists yet. The project may be unmaintained, or the maintainers have not released one.
- The range ends with a last affected version instead. Some records state the last affected version and not the first fixed one, which is a different event type.
- The record was written from an old report. Early advisories often lack the detail.
- The project is archived. The flaw stays open and the advice is to switch.
We did not break down the reasons, so we cannot say which is largest.
What a fixed version does and does not tell you
A fixed version tells you that an upgrade target exists. It does not say the upgrade is easy. A fix may sit behind a major version change, which can break your code. It does not say your tooling will see it, either: the fix may need a newer language runtime than you run.
Two checks help. First, read the range: a fix for the 2.x line does not help if you run 1.x and the maintainers dropped support. Second, look at what else changes between your version and the fixed one.
A practical split
For a backlog, a useful first cut is three piles:
- Fixed version exists and the upgrade is a minor or patch change. Do these first.
- Fixed version exists but needs a major upgrade. Schedule them with testing.
- No fixed version. Decide whether the code is reachable, add a compensating control, or replace the component.
The third pile is where a reachability check pays off most, since you cannot patch your way out of it.
Safeguard's SBOM and dependency scanning lists the components you run, and reachability analysis helps separate vulnerable code your application calls from code it does not. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open it and look at how a finding with an available fix is separated from one without.
Quick check
If an advisory has no fixed version, should I remove the package?
Not automatically. First check whether the vulnerable code is reachable in your application and whether a compensating control is possible.
Is a named fixed version always safe to install?
Not always. Check that it exists, supports your runtime, and does not need a risky major upgrade.
Sources
- OSV schema, definition of the fixed and last affected range events.
- OSV data sources and dumps, per-ecosystem OSV dumps downloaded on 19 October 2026.
Last reviewed: 19 October 2026.
