A blank fixed version can mean four things: no fix exists, the advisory record does not state one, the package is malicious so no safe version exists, or the fix is on a release line the tool did not match. Check the advisory and the maintainers' notes before you decide the flaw is unfixable.
Four reasons for an empty fix column
1. No fix exists yet. The maintainers have not released one. This is a real answer, and you need a mitigation or a replacement.
2. The record lacks the field. The OSV schema allows a range to use either fixed or last affected. It says last affected marks the last vulnerable version at publication, assuming a later fix, and strongly recommends fixed where possible. A record that uses last affected tells a tool the ceiling, not the repair, so a tool may show no fix version even though one was released later.
3. A malicious package. The GitHub Advisory Database documentation says malware advisories have no fix version, because there are no safe versions. The remedy is to stop using the package and replace it.
4. A different release line. A project may fix its 2.x line and its 3.x line separately. A tool may report the fix for one line and leave the other blank, or compute a single answer from a wider range.
Triage steps
- Open the advisory in both tools. Compare the affected and fixed fields.
- Check whether it is a malware advisory. If so, remove the package and investigate how it entered.
- Read the project's release notes for your release line. Look for a patched version after the date of the advisory.
- Search for a newer release of the package and read its changes.
- If no fix exists, decide between mitigation, replacement and accepted risk, with an expiry.
| What you find | What to do |
|---|---|
| Fix released, record not updated | Upgrade, note the record gap, tell the tool vendor or maintainers |
| No fix released | Mitigate or replace, record the decision |
| Malware advisory | Remove, investigate, rotate anything the package could reach |
| Fix on a different line | Upgrade within your line if available, else plan a move |
What not to do
Do not suppress a finding just because no fix is listed. A flaw without a fix is often more urgent to decide, since you cannot simply upgrade out of it. Do not trust a single tool's empty field as proof that nothing can be done.
Mitigation basics when no fix exists
Reduce exposure first. Check whether the vulnerable feature is used at all. Restrict inputs that reach it, limit network exposure of the component, and add monitoring. Then check weekly for a release. If the package is unmaintained, start planning a replacement.
If you accept the risk, record it with a reason, an owner and a short expiry, so it returns for review instead of vanishing.
Quick check
Does a blank fix column mean the package is unfixable?
No. It may mean the record has no fixed field, or the fix is on another line. Check the advisory and release notes.
What should I do for a malware advisory?
Remove the package, replace it with a legitimate one, and investigate how it entered your tree.
Sources
Last reviewed: 19 October 2026.
