For Ubuntu packages, follow Ubuntu's priority first, because it reflects how the flaw behaves on Ubuntu, and read the CVSS score as a second opinion. Ubuntu says its priority levels are distinct from CVSS base scores, so the two can legitimately disagree. Add exploitation evidence on top of both.
The five Ubuntu priority levels
The Ubuntu Security team reviews new vulnerabilities, assesses the impact on supported releases and assigns a priority. Vulnerabilities are addressed in priority order. Ubuntu's own guidelines say the priority is based on many factors including severity, importance, risk, estimated number of affected users, software configuration and active exploitation.
| Priority | Meaning in Ubuntu's guidelines |
|---|---|
| Critical | A very damaging problem, typically exploitable for nearly all users in a default install, such as remote root privilege escalation or remote data theft |
| High | A significant problem, typically exploitable for nearly all users in a default install, such as serious remote denial of service or local root privilege escalation |
| Medium | A significant problem, typically exploitable for many users, such as network daemon denial of service or cross-site scripting |
| Low | Hard to exploit, needs a user-assisted attack, has a small install base, or does little damage. Often included only when higher priority issues force an update |
| Negligible | Technically a security problem but theoretical, needs a very special situation or does no real damage. Typically not fixed unless the fix is easy |
Low and Negligible matter for planning. Ubuntu says low priority fixes tend to ship only when higher priority issues require an update, so a Low finding may sit open for a while by design.
Why the scores differ
CVSS describes a vulnerability in general terms. It does not know that a service is not installed by default on Ubuntu, that a hardening feature blocks the attack path, or that your host has no network exposure. Ubuntu does know the first two, and mentions its proactive security features as one factor.
You know the third. That is why none of the scores is final for your environment.
A combined reading
Use the signals in layers:
- Is it on the CISA Known Exploited Vulnerabilities list? If yes, act first.
- What is Ubuntu's priority? Critical and High move to the front of the queue.
- Does the package run on a host that is reachable from untrusted networks?
- What is the CVSS base score, as a tie-breaker between similar items?
Write the order down in your policy, so two analysts reach the same answer. Our article on vulnerability scoring signals compares them in more detail.
Fixing a specific CVE
Ubuntu's documentation says you can update all installed packages with an apt update and upgrade, and recommends not cherry-picking updates from individual packages. If you have the Ubuntu Pro client set up, the pro fix command with a CVE ID applies the fix for a specific CVE. Check the CVE page for notes if no fix is available yet, since mitigations are sometimes listed there.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare how a raw severity looks next to the exploitability view for the same finding.
Safeguard does reachability analysis and vulnerability policies, so a Critical in a package your code never calls can be ranked below a High that it does. A free scan shows the idea on your own project.
Quick check
Does Ubuntu use the NVD severity?
Ubuntu says its priority levels are distinct from CVSS scores, its own or from sources such as the NVD.
Will Ubuntu fix every Low priority CVE quickly?
Not necessarily. Low priority fixes tend to be included when higher priority issues require an update.
Sources
- Ubuntu, About CVEs
- Ubuntu, Security notices
- CISA, Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
