"Fix available" means the maker of the software has released a version that no longer has the flaw. It does not mean the fix is installed, tested with your code, or free of side effects. You still have to choose the version, upgrade, test and confirm the flaw is gone.
TL;DR
- Fix available is a starting gun, not a finish line.
- Fixes come in three sizes: a small patch, a minor update, or a major version jump.
- Smaller jumps are usually safer. Major jumps need testing.
- Always confirm by scanning again after the change.
What does "fix available" actually tell you?
A scanner marks a finding as fix available when it knows of a newer version of the affected package where the flaw was repaired. A package is a ready-made piece of software your code uses. A version is the numbered release of that package, such as 2.4.1.
Think of a recall on a car part. The notice says a repaired part exists. It does not say your garage has installed it, or that the new part fits your model without any adjustment. Someone still has to book the appointment.
That is why this label is useful but incomplete. It tells you a path exists. It says nothing about how hard the path is.
CISA gives this idea weight in its Known Exploited Vulnerabilities catalog. One of the three requirements for a flaw to be listed is that there is a clear remediation action, such as a vendor provided update. So for the most urgent class of flaws, a fix path is by definition expected.
What are the three sizes of fix?
Most open source packages use a numbering style often called semantic versioning, written as major, minor and patch, for example 3.8.2. Here 3 is the major number, 8 is the minor number, and 2 is the patch number. The idea is shared across many projects, although each project decides how closely to follow it.
| Size | Example | What it usually means | Risk of breaking your code |
|---|---|---|---|
| Patch | 3.8.2 to 3.8.3 | Bug and security fixes only | Low |
| Minor | 3.8.2 to 3.9.0 | New features, meant to stay compatible | Low to medium |
| Major | 3.8.2 to 4.0.0 | Changes that may break existing use | Medium to high |
The word "usually" matters. Projects differ, and a patch can occasionally break things. Treat this table as a rule of thumb and not a guarantee. For more on this topic, see semantic versioning and security.
How do you apply a fix safely?
Follow these numbered steps.
- Find the lowest fixed version. Look for the smallest upgrade that removes the flaw. The smallest jump has the least chance of side effects.
- Check what else changes. Read the release notes for anything that affects how you use the package.
- Upgrade in a branch. A branch is a separate copy of your code where you can try changes without touching the live version.
- Run your tests. Automated tests check that the main features still work. If you have few tests, click through the key screens by hand.
- Deploy gradually if you can. Send the change to a small share of users or to a staging copy first.
- Scan again. Confirm the finding is gone. This step is easy to skip and important to do.
- Write it down. Note the date, the version and who did it.
What if the fix is a big jump?
Sometimes the only fixed version is a major release. Then you have choices.
- Plan the upgrade as real work. Put it in a sprint with time for testing.
- Reduce exposure in the meantime. For example, turn off the affected feature or limit who can reach it.
- Check whether the flaw matters for you. If the vulnerable code is not used by your program, the urgency may be lower. See exploitability versus breakability for how to weigh the danger of the flaw against the danger of the change.
- Record a short term exception with an owner and an end date.
For flaws on the CISA exploited list, do not wait long. CISA recommends that organizations include a requirement to address those items right away in their vulnerability management plan.
A worked example with invented numbers
These numbers are invented to show the thinking, not taken from a real project.
Your scan lists a flaw in a package at version 2.3.0. Fixed versions exist at 2.3.5, 2.6.0 and 3.0.1.
| Option | Jump | Estimated effort | Estimated break risk |
|---|---|---|---|
| 2.3.5 | Patch | 1 hour | Low |
| 2.6.0 | Minor | 4 hours | Low to medium |
| 3.0.1 | Major | 3 days | Medium to high |
You pick 2.3.5. It removes the flaw, takes an hour, and keeps risk low. You note that 3.0.1 is on the roadmap as a planned upgrade, because older versions eventually stop receiving fixes.
If 2.3.5 did not exist and only 3.0.1 did, you would plan the three days, add a temporary guard such as restricting access, and set a deadline.
What are common mistakes?
- Upgrading to the newest version by habit. The newest may be a major jump you do not need today.
- Trusting the label without confirming. Some "fix available" findings are false matches or are fixed in a different branch of the package.
- Forgetting indirect packages. Your code may use a package that uses the vulnerable one. The fix may require updating the outer package, or forcing a version through a setting.
- Skipping the rescan. Without it, you only believe the flaw is gone.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how the tool shows the lowest fixed version for a finding, which is the idea behind step 1 above.
How can Safeguard help?
Safeguard scans your dependencies and can show fixed versions for findings. With autonomous remediation, it can open a fix pull request for you to review. This feature is off by default and every category starts on Manual, so nothing is proposed or merged until you choose. The Safeguard CLI can also write code, which can help when a fix needs a small change in your own files beyond a version bump. Policies and gates can then check the result before it merges. Try the free scan at gold.safeguard.sh/scan.
Quick check
If a fix is available, why has my scanner not cleared the finding?
The fix has to be installed and the scan has to run again. Also check whether the vulnerable package is pulled in indirectly by another package.
Is a patch version upgrade always safe?
Usually, but not always. Run your tests anyway. Projects differ in how strictly they follow version numbering rules.
What should I do if no fix is available?
Reduce exposure, switch off the affected feature if you can, and record a time limited exception. See when to fix versus mitigate for options.
Sources
Last reviewed: 19 October 2026.
