Two databases can disagree on affected versions because each records the range differently: some mark the version that contains the fix, others mark the last known vulnerable version, and some list versions one by one. Your version can fall inside one record and outside another. Read the range, not just the verdict.
How a range is written
The OSV schema is a good reference, because it states the rules plainly. An affected entry names a package and an ecosystem. It then describes affected versions with ranges, a list of versions, or both. In the schema's words, a version is considered affected if it lies within any one of the ranges or is listed in the versions list.
Ranges are built from events. Two of them matter for this post.
- fixed marks the version that contains the fix.
- last_affected marks the last vulnerable version as of publication, assuming a later fix.
The schema says it strongly recommends fixed instead of last_affected where possible, and that last_affected can allow false negatives. It describes it as the hard ceiling of the vulnerability at the time of publication.
Where disagreement comes from
| Source of difference | Effect on your version |
|---|---|
| One record uses fixed, another uses last affected | A later patch release may be inside one range and outside the other |
| One record lists versions explicitly, another uses a range | Versions with unusual numbering may be matched differently |
| Range type differs (SemVer, ecosystem, git) | Ordering rules differ, so edge versions land differently |
| One database revised the entry, the other did not yet | Your version flips after the update |
The schema notes that SemVer ranges follow strict SemVer 2.0 ordering, while ecosystem ranges use version strings that are not interpreted generically. That is why it recommends an explicit version list for ecosystem ranges, so consumers can answer whether a given version is affected without ecosystem specific logic.
A three step check for your own case
- Open both advisory entries. Find the affected and fixed fields. Write down the range each one gives.
- Place your version. Is it below the fixed version in each? If one record only has a last affected value, check whether your version is above it, and whether the maintainers have since said anything about later releases.
- Read the project's own notice. The maintainers' advisory or release notes are the closest to the source. If it says your release is patched, that outranks a database entry that has not caught up.
If the two databases still conflict, record the conflict, note which source you followed, and set a date to look again.
Do not treat a quiet scanner as proof
A tool that stays silent might be reading an entry with a narrow range. That is a data question, not proof of safety. Before you close a ticket on the strength of one tool, confirm your exact version against the fixed value in at least one advisory you have read yourself.
Why this matters for gates
If a build gate blocks on a finding that rests on a last affected ceiling, you may be blocking a version the maintainers already fixed. If a gate passes because a range was too narrow, you may ship a vulnerable version. In both cases the gate is only as good as the entry behind it. Keep an override path with a written reason so that a human can resolve the conflict without disabling the gate.
Quick check
Which is safer to rely on, fixed or last affected?
Fixed. The schema recommends it, and it names the version that contains the repair. Last affected is a ceiling at publication time and can miss later vulnerable releases.
Can one flaw have several IDs and different ranges?
Yes. Aliases link the same flaw across databases, and each database may record its own range. Compare them before you decide.
Sources
Last reviewed: 19 October 2026.
