CVSS v4 vs CVSS 3.1 – What's New and Improved

Recently an update to CVSS scoring was released – CVSS V4. But, the real question is why was an update needed? What was wrong with CVSS 3.1? A few things were wrong. Amongst them are:

• No inputs for real-time threat or supplemental input to risk analysis
• Scores are often too high
• Insufficient granularity in scoring
• Lacked new attack vectors and systems like OT, ICS, HHS, etc.

What does v4 now do better? Numerous things. But here are just a few:

• User interaction now has passive vs. active – a key facet of many web attacks.
• A better indicator of risk – CVSS 4 takes into account threat intelligence, environmental metrics, and if the exploit is automatable, and the effort it takes to mitigate and/or recover.
• CVSS 4 now takes into account the impact on subsequent systems not just a single ‘Scope’ variable
• And much more!

Let’s take a look at NIST’s actual CVSS forms for both version 3.1 and version4.

And then, the CVSS 4.0 form:

And you can see, v4 has many more dials to help hone in on a true score and risk. But what does this look like in practice?

CVSS 3.1 vs CVSS v4: Rating the Kubernetes Ingress Nightmare Vulnerability

The Kubernetes Ingress NGINX Nightmare vulnerabilities are a textbook example of where CVSS v3.1 starts to fall short.

These vulnerabilities allow remote code execution in the Ingress NGINX controller, potentially leading to full Kubernetes cluster compromise under certain conditions. While CVSS 3.1 correctly flags this as critical, it fails to express how much the real-world risk depends on deployment context.

Below, we compare how this vulnerability is rated using CVSS 3.1, how practitioners would rate it using CVSS v4, and how an organization like NIST is likely to publish it under CVSS v4.

CVSS 3.1 Rating (As Published)

Most advisories and the NVD converged on the following CVSS 3.1 rating for the Ingress Nightmare vulnerabilities.

CVSS 3.1 Base Metrics

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVSS 3.1 Score – 9.8 Critical

What CVSS 3.1 Cannot Express

• Whether the ingress controller is internet-facing
• Whether the vulnerable webhook is reachable externally
• Whether exploitability is theoretical or weaponized
• Differences between managed and self-hosted clusters

CVSS v4 Rating (Practitioner View)

CVSS v4 separates technical severity, threat realism, and environmental exposure, which allows for a far more honest assessment of Kubernetes vulnerabilities.

Base Metrics (CVSS v4)

From a purely technical standpoint, the vulnerability remains severe.

Base Severity: Critical

Threat Metrics

This vulnerability was rapidly weaponized after disclosure.

These metrics increase confidence that exploitation is realistic, not theoretical.

Environmental Metrics (Where CVSS v4 Changes Things)

CVSS v4 allows the same vulnerability to be scored differently depending on deployment context.

Practitioner Summary

This vulnerability is always serious — but it is not equally catastrophic in every environment.

That distinction simply isn’t possible in CVSS 3.1.

CVSS v4 Rating (How NIST Would Do It)

Historically, NIST and the NVD publish base scores only, intentionally avoiding environmental assumptions.

Under CVSS v4, that approach is unlikely to change.

Likely NIST Approach

Likely Published Outcome

Critical (approximately 9.3–9.6)

In practice, this means:

• CVSS v4 scores published by NIST will still resemble a single “headline number”
• Organizations are expected to apply environmental and threat adjustments themselves

In other words: CVSS v4 doesn’t remove responsibility — it formalizes it.

Side-by-Side Comparison

Key Takeaway

CVSS 3.1 wasn’t wrong, it was just not complete.

The Kubernetes Ingress Nightmare vulnerabilities demonstrate why a single severity number is often insufficient for modern, highly contextual systems like Kubernetes.

CVSS v4 builds on v3.1 to make risk clearer in modern, varied environments.