CVSS 4.0 Misreadings: What Security Teams Get Wrong

Misreading: Base Score Means Immediate Danger

Correct reading: The base score in CVSS 4.0 represents the intrinsic characteristics of a vulnerability, independent of your environment. It does not indicate immediate danger to your specific infrastructure. A high base score simply means the vulnerability is severe if exploited. It does not mean an attacker is currently exploiting it or that your systems are exposed. You must separate the theoretical severity from the actual exposure. Relying solely on the base score ignores the reality that many high-severity flaws require specific conditions to trigger.

Misreading: Attack Vector Is Static

Correct reading: Attack vector in CVSS 4.0 describes how an attacker reaches the vulnerable component. It is not static because the score incorporates environmental factors that change the effective distance. A network-based attack vector might be downgraded if your exposure management reveals the asset is air-gapped. Conversely, a local attack vector becomes critical if an attacker has already breached the perimeter. You must evaluate the attack vector against your current network segmentation. The metric reflects the path of least resistance, which shifts as your defence posture changes.

Misreading: Privileges Required Are Binary

Correct reading: Privileges required in CVSS 4.0 are not a simple yes-or-no check for admin rights. The framework distinguishes between low, high, and no privileges. This granularity matters because a vulnerability requiring low privileges is far more dangerous than one requiring high privileges. Many teams assume that if a user account is not an administrator, the risk is low. This is a dangerous assumption. Low-privilege accounts often have access to sensitive data or can escalate privileges through other flaws. You must assess the actual permissions of the affected accounts.

Misreading: User Interaction Is Rare

Correct reading: User interaction in CVSS 4.0 measures whether a user must perform an action to trigger the vulnerability. Teams often dismiss vulnerabilities requiring user interaction as low priority. This is incorrect because social engineering attacks make user interaction highly probable. Phishing campaigns and malicious attachments bypass technical controls by leveraging human error. A vulnerability requiring user interaction has a lower base score but a higher likelihood of exploitation in practice. You must factor in your organisation’s security awareness training effectiveness. Ignoring this metric leaves you vulnerable to targeted attacks.

Misreading: Safety Mechanisms Reduce Base Score

Correct reading: Safety mechanisms, such as address space layout randomisation or stack canaries, do not reduce the base score in CVSS 4.0. They influence the attack potential metric instead. The base score reflects the vulnerability itself, while attack potential reflects the difficulty of exploiting it given existing protections. Teams often expect these mitigations to lower the overall severity number. This expectation is flawed. The framework separates the flaw from the defence. You must report the base score accurately and use attack potential to prioritise remediation. This distinction ensures you do not underestimate the underlying flaw.

See also: Industrial Control System Vulnerabilities: Hidden Risks and Fixes · How to Read CSAF Advisories Without Misinterpreting Scope

Misreading: Environmental Confidence Is Subjective

Correct reading: Environmental confidence in CVSS 4.0 is not a subjective guess. It is a structured assessment of how likely an attacker is to exploit the vulnerability in your environment. It considers factors like the presence of mitigations and the likelihood of user interaction. Teams often skip this step, treating it as optional. This leads to inaccurate risk prioritisation. You must evaluate your specific context to assign a confidence level. High confidence means you are certain the vulnerability is exploitable. Low confidence means you are unsure. This metric helps you focus on threats that are actually relevant to your operations.

Misreading: CVSS 4.0 Replaces Qualitative Assessment

Correct reading: CVSS 4.0 does not replace qualitative assessment. It provides a standardised numerical framework to support human judgment. The scores are inputs for decision-making, not the final decision. Teams often treat the score as the sole determinant of action. This is a mechanical approach that ignores business context. A vulnerability with a moderate score might affect a critical revenue-generating system. You must combine the CVSS score with business impact analysis. The framework supports your assessment; it does not automate it. Relying on numbers alone blinds you to the actual risk.

Misreading: Older Versions Are Obsolete

Correct reading: CVSS 3.1 and earlier versions are not obsolete. They remain valid for vulnerabilities that occurred before the adoption of CVSS 4.0. The new version introduces additional metrics and a different calculation method. Teams often try to retrofit old vulnerabilities into the new framework. This creates inconsistency and confusion. You should use CVSS 4.0 for new vulnerabilities and continue using legacy scores for historical data. Mixing versions in reporting tools can skew your risk dashboard. Maintain separate views for legacy and current vulnerabilities to ensure accurate trend analysis.

Misreading: Attack Potential Is Fixed

Correct reading: Attack potential in CVSS 4.0 is not fixed. It changes as your environment changes. If you implement virtual patching or change management for security patches, the attack potential decreases. Teams often calculate this metric once and forget it. This is a static view of a dynamic reality. You must update attack potential as you deploy mitigations and workarounds. The metric reflects the current state of your defences. Ignoring this dynamic nature means your risk assessment becomes stale quickly. Regular reviews ensure your prioritisation remains aligned with your actual security posture.

Misreading: Complexities Are Always High

Correct reading: Attack complexity in CVSS 4.0 is not always high for remote exploits. Some vulnerabilities are trivial to exploit, requiring no special conditions. Teams often assume that remote attacks are inherently complex. This assumption is dangerous. Simple exploits can cause widespread damage. You must evaluate the specific requirements of each vulnerability. A low complexity score indicates that an attacker can exploit the flaw easily. This should trigger immediate action. Do not let the remote nature of the attack lull you into a false sense of security.

Misreading: Default Credentials Are Irrelevant

Correct reading: Default credentials are irrelevant to the CVSS 4.0 score itself. The framework assesses the vulnerability, not the configuration. However, weak password policies and default credentials dramatically increase the likelihood of exploitation. Teams often separate vulnerability management from identity management. This separation is artificial. A vulnerability with a moderate score becomes critical if attackers can easily authenticate. You must integrate identity risk into your vulnerability assessment. The CVSS score tells you about the flaw; your configuration tells you about the exposure.

Misreading: Penetration Testing Validates Scores

Correct reading: Penetration testing does not validate CVSS scores. It validates your defence posture. The scores are theoretical assessments of vulnerability severity. Penetration tests show how attackers can exploit those vulnerabilities in practice. Teams often expect pentest results to match CVSS prioritisation. This expectation is flawed. Pentesters may find low-score vulnerabilities that are easy to exploit due to misconfiguration. You must use pentest results to refine your understanding of attack potential. The test reveals the gap between theoretical risk and actual exploitability.

Key takeaways

• CVSS 4.0 measures attack potential, not just base severity, reflecting how easy it is to exploit in your specific context.
• Environmental confidence replaces the old exploitability metric, forcing teams to assess how certain they are about an attacker’s access.
• Base scores no longer dictate priority alone; dynamic factors like user interaction requirements and privilege levels shift the risk profile.

Frequently asked questions

Does CVSS 4.0 change how I report to management?

Yes, you must explain that scores are dynamic. Management needs to understand that risk changes as your defences improve. Base scores alone do not reflect the current state of security.

Can I use CVSS 4.0 for compliance?

Compliance frameworks often reference CVSS versions. Check your specific requirements. Some may still require CVSS 3.1. Ensure you are using the version mandated by your auditors.

How do I handle mixed-version environments?

Keep legacy and current scores separate. Do not mix them in calculations. Use CVSS 4.0 for new findings and legacy versions for historical data to maintain accuracy.

Is attack potential mandatory?

It is a core metric of CVSS 4.0. Ignoring it reduces the accuracy of your risk assessment. You should calculate it to understand the true difficulty of exploitation in your environment.

How this guide was produced: written by the Honeypot Daily editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.