"Fixed in" is the first release of a package that contains the patch for a vulnerability. Any version at or above it, on the same release line, is generally unaffected. It does not mean the upgrade is safe for your build, and it does not tell you whether a fix exists on the line you use.
Where the value comes from
Most vulnerability databases record affected versions as ranges. The OSV schema, an open format used by several databases, describes a range as a timeline of events: an introduced version, then a fixed version. The specification says a fixed event precisely identifies the version that contains the fix, and strongly recommends it over the alternative field, last_affected, which is only a hard ceiling when no fixed version is known.
So when your report says "fixed in 2.4.9," the database is saying versions from the introduced point up to but not including 2.4.9 are affected.
Four things to check before you upgrade
- Is your current version below the fix? Compare the exact version in your lockfile, not the range in your manifest.
- Is it a patch, minor or major jump? A move from 2.4.1 to 2.4.9 is usually small. A move to 3.0.0 may break callers.
- Is there a fix on your release line? Some projects backport fixes to older lines. Others do not, and the only fixed version is a new major.
- Does the parent allow it? If the vulnerable package is indirect, your direct dependency may pin a range that excludes the fixed version.
What the npm tooling does with this
The npm documentation explains that npm audit fix applies remediations that do not require changes to dependency ranges, and that fixes needing a major version change need the force option. It also warns that some vulnerabilities cannot be fixed automatically and need manual review. The same logic applies whatever tool you use: a compatible fix is cheap, a breaking fix is a planned change.
| Situation | What it usually means | Typical action |
|---|---|---|
| Fixed in a patch version | Low risk upgrade | Upgrade and run tests |
| Fixed in a new major | Possible breaking change | Plan and test, or check for backports |
| No fixed version listed | No patch published | See the no-fix guide below |
| Fixed version excluded by a parent | Parent pins old range | Upgrade the parent or override |
If no fix is listed at all, read what to do when an SCA report shows no fix available.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how the fixed version is shown next to the version you run.
Where Safeguard fits
Safeguard's autonomous remediation can open fix pull requests. It is off by default, and every category starts on Manual, so a person approves each change.
Quick check
Does "fixed in" mean upgrading is risk free?
No. It only says the patch exists in that version. Test the upgrade, especially across a major version.
Why is the fixed version not offered by my package manager?
A parent dependency may restrict the version range, so the fixed release falls outside what it allows.
Sources
Last reviewed: 19 October 2026.
