These are status labels a distribution assigns per package and release. Needs evaluation means not assessed yet. Not affected means the flaw does not apply. Deferred means affected but the fix is postponed. Ignored means it will not be fixed. Each needs a different response from you.
The statuses, from Ubuntu's documentation
Ubuntu publishes status definitions for each package in each supported release. The main ones:
| Status | Meaning (summarized from Ubuntu) | What you should do |
|---|---|---|
| Needs evaluation | Vulnerability of this package is not known for the release yet | Treat as unknown, watch for an update |
| Not affected | Package is related to the CVE but not affected, usually with an explanation | Record the reason, close the finding |
| Vulnerable | Package is affected | Plan the fix by your priority |
| Vulnerable, work in progress | Affected, and the security team is working on a fix | Check for a mitigation, track the update |
| Vulnerable, fix deferred | Affected, but fixing has been postponed | Decide whether you can live with it, or mitigate |
| Fixed | A fixed version is available | Update the package and redeploy |
| Ignored | Will not be fixed, for example because the package is unsupported, the CVE was withdrawn, or the fix would break other functionality | Mitigate, replace, or accept with an exception |
| Not in release | Package is not part of that release | Nothing to do |
Debian uses similar ideas. Its tracker offers urgency levels and a no-dsa tag as filters, so read the tracker notes for the specific reasoning.
Why Deferred and Ignored need care
These two mean the distribution will not give you a patch soon, or at all. The vulnerability is still in your system. You must choose what to do.
For Deferred, the distribution may have judged the issue low risk. Read the notes. If your use is unusual, such as exposing the affected service to untrusted input, your risk may be higher than the average.
For Ignored, the options are narrower. If the package is unsupported, it may be time to upgrade the release or replace the component. If fixing would break functionality, a mitigation may be the only route.
A practical response flow
- Find the status for your exact package and release, not just the summary.
- Read the explanation on the page.
- Check whether your usage matches the risky scenario.
- Choose: patch, mitigate, replace, or record an exception with an expiry date.
- Re-check on a schedule, since statuses change over time.
Ubuntu itself recommends double checking the status on the individual CVE page for the specific packages and releases you use, instead of relying on the summarized view.
Pair it with your own signals
The status tells you what the distribution will do. It does not say whether your application reaches the code or whether your service is exposed. Combine it with exploitation evidence, exposure, and reachability.
Try it yourself
Open the demo and look at which findings already have a fixed version. Think about how the other items would be handled when a vendor offers no fix.
Click through it at your own pace, or open it full screen.
Quick check
Does Ignored mean the vulnerability is harmless?
No. It means the distribution will not fix it, for reasons given in the notes. The flaw may still be exploitable in your setup.
Is Needs evaluation the same as Not affected?
No. It means nobody has decided yet. Treat it as unknown.
Sources
Last reviewed: 19 October 2026.
