Why Vendor Severity and CVSS Scores Disagree on the Same Bug

Vendor severity and CVSS scores disagree because they answer different questions. A CVSS base score rates the worst-case technical impact, assuming the conditions for attack exist. A vendor rating often reflects how likely real-world exploitation seems. Neither one tells you whether attackers are using the flaw, which is what CISA's KEV catalog tracks. Good triage reads all three signals and then adds your own exposure.

A recent example of the split

WordPress CVE-2026-119977 shows how far apart the signals can land on one bug:

• The WordPress advisory rates it Low.
• The CVE record, from Wordfence as the numbering authority, scores it CVSS 8.1 High.
• Patchstack scored the attack complexity as high and said it "would not call it practical to exploit."
• CISA added it to the KEV catalog on November 3, with a November 6 deadline for federal agencies.

A team that reads only the first line may file this as routine. A team that reads only the last may declare an emergency on a site that patched itself a week ago. Each reaction misses part of the picture.

Why do vendor severity and CVSS scores disagree?

CVSS base scores measure the inherent characteristics of a flaw, while a vendor may also weigh how realistic an attack seems in practice. The two can differ widely when a flaw has severe impact but difficult conditions.

The CVSS 3.1 specification makes this explicit. It lists "repeated exploitation to win a race condition" as an example of high attack complexity. It also says that if a specific configuration is required for an attack, the base metrics should be scored assuming the component is in that configuration. A flaw that needs precise timing can therefore still score 8.1, because the score assumes the attacker reaches the vulnerable state.

Rescana's analysis quotes Wordfence making the same point: its score "reflects the eventual impact." That follows the specification. A vendor's Low rating and a numbering authority's High rating can both be defensible for the same TOCTOU race condition.

What each signal actually measures

Treat each rating as an answer to one narrow question:

• CVSS base score: how bad is this if the conditions exist? The specification says vendors and analysts generally supply the base and temporal metrics, and that the score can be refined later.
• Vendor severity: how does the publisher rate this in its own product? Scales and criteria vary. WordPress, for example, rated this flaw Low and published no CVSS score.
• KEV listing: has this been exploited in the wild? CISA requires reliable evidence and does not use exploitability as a criterion.
• Researcher commentary: what did someone who read the code conclude? This is often the most useful context, but it is one party's judgment at one point in time.
• Your environment: do you run it, is it exposed, and what does it reach? Only you can answer this one.

Does a CISA KEV listing mean sites were compromised?

No, not necessarily. CISA's criteria count both attempted and successful exploitation as active exploitation, so a listing can reflect attempts that failed.

The criteria are also stricter than they might appear. Scanning alone does not qualify, and neither does a public proof of concept. So a listing means CISA has reliable evidence of real attack activity, even when the public record stops short of a confirmed victim. For WordPress CVE-2026-119977, the public reports we read describe attempts, and CISA has not published the evidence behind its entry.

Why does a low-rated bug still need action?

A low vendor rating says little about your specific deployment, and attackers do not consult it when choosing targets. Wordfence reported more than 18,500 requests in 21 hours against the WordPress flaw that its vendor rated Low.

Difficult conditions also do not stop attackers from trying. Repeated polling improves their odds, and the WordPress window returns on every update, including unattended ones, as Patchstack notes. The bug needs no account, so anyone who can reach the site can try.

A triage order that handles disagreement

Work through these questions in order, and let the first strong answer set the priority:

1. Do you run it? Include sites run by agencies, hosts and other teams, because a site missing from your inventory never reaches triage.
2. Is it in KEV or otherwise reported as exploited? If yes, move it ahead of anything scored higher but not exploited. CISA recommends using the catalog as an input to your prioritization framework, even for organizations outside the federal mandate.
3. Is the vulnerable path exposed in your environment? For the WordPress flaw, that means testing whether wp-content/upgrade/ is reachable. Our guide on how to block web access to wp-content/upgrade covers the test and the fix.
4. Has the fix already applied? Auto-updated software may already be patched. Verify the version instead of assuming it.
5. What is the impact if the attack works? Use the CVSS impact ratings here, alongside what the system can reach.

A high impact rating with a difficult attack vector should still mean action, on a schedule you can defend. It may not justify an overnight change on a site that has already updated.

Write the disagreement into your policy

A policy that maps a single number to a deadline breaks down when sources conflict. It needs three additions.

First, name the source of truth. Decide which rating your deadlines follow, and say what happens when another source is higher. A simple rule is to take the most urgent credible signal, then let documented exposure facts lower it.

Second, record the reasoning. "Vendor rates Low, CVSS 8.1, KEV listed, path blocked at the web server, version verified" is a decision an auditor or insurer can follow. A bare score is not.

Third, make exploitation status override the score. Our article on why vulnerability chaining beats CVSS in triage makes a related case about how much a single base score can miss.

Check your scanner as well. The WordPress advisory still showed "No known CVE" when we read it, while the CVE record already existed. Tools keyed to one source can miss the other, so a clean scan report is weak evidence during the first days of a disclosure.