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
| Metric | Value |
|---|---|
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| Scope | Changed |
| Confidentiality Impact | High |
| Integrity Impact | High |
| Availability Impact | High |
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.
| Metric | Value |
|---|---|
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| Scope | Changed |
| Impact | High |
Base Severity: Critical
Threat Metrics
This vulnerability was rapidly weaponized after disclosure.
| Threat Metric | Value | Rationale |
|---|---|---|
| Exploit Maturity | Functional / High | Public PoCs emerged quickly |
| Threat Actor Interest | High | Kubernetes ingress controllers are high-value targets |
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.
| Deployment Scenario | CVSS v4 Effective Severity |
|---|---|
| Internet-facing ingress controller | 9.5–9.7 (Critical) |
| Internal-only ingress controller | 8.8–9.2 (Critical) |
| Admission webhook restricted to cluster | 8.0–8.5 (High–Critical) |
| Managed Kubernetes with strong network controls | 7.5–8.0 (High) |
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
| Component | Treatment |
|---|---|
| Base Metrics | Included |
| Threat Metrics | Possibly included |
| Environmental Metrics | Not applied |
| Deployment Context | Worst reasonable case |
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
| Scoring Model | Result | What It Optimizes For |
|---|---|---|
| CVSS 3.1 (NVD) | 9.8 Critical | Simplicity and consistency |
| CVSS v4 (NIST-style) | ~9.4 Critical | Worst-case standardization |
| CVSS v4 (Practitioner) | 7.5–9.7 | Real-world risk |
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.