What is CVSS and what a 9.8 score actually means

What CVSS actually is

CVSS is a fast way to describe how dangerous a vulnerability looks from the technical side. It is not a verdict. It is more like a quick ruler for sorting problems.

A 9.8 score sounds scary, but by itself it is just a number. It does not know whether your service is actually in the danger zone, whether the attacker needs a login, whether a user must click something first, or whether the issue affects confidentiality, integrity, or availability.

Problem / context

Security feeds love the number 9.8. It is dramatic, easy to share, and very bad at explaining real-world risk.

The same CVSS score can mean very different things:

• for a public service without authentication, it can be genuinely urgent;
• for an internal tool behind a VPN, the risk is often lower;
• for a system where the vulnerable feature is disabled, it may be almost noise.

So CVSS is not “panic now”. It is “look closer”.

How to read the score without magic

1. Do not stop at the number

The base score is the main number from 0 to 10. It helps you sort issues quickly: some need immediate work, some can wait a little.

But the number does not know your architecture. It does not see whether the service sits behind a VPN, whether it is internet-facing, whether another layer of protection exists, or whether users can even reach the vulnerable spot.

2. Read the vector

The vector is the short technical line next to the score. It is there not for decoration, but so you can understand why the score came out the way it did.

The most important questions in the vector are:

• the attack vector — where the attack can start;
• privileges required — whether the attacker already needs access;
• user interaction — whether a person has to do something first;
• the impact on confidentiality, integrity, and availability.

If the attack comes over the network, needs no login, and needs no user action, the practical risk is usually higher. If it requires privileges, local access, or a tricky manual sequence, the real danger is often lower than the headline suggests.

3. Do not confuse severity with your real risk

CVSS severity is a technical score. Your service risk is that score plus your actual context.

The same issue can be:

• almost irrelevant on a closed internal test box;
• very unpleasant on a public endpoint;
• urgent if there is already a POC, exploit, or active exploitation.

So the real question is not “what is the number?” but “does this number actually reach my service”.

Practical workflow

Step 1. Find the exact product and version

Start with the facts: what is installed, and which version is it. Without that, any CVE or CVSS news item is just noise.

Step 2. Read the official note

You need more than the score. You need to know:

• which versions are affected;
• whether the issue exists in the default configuration;
• whether a specific feature must be enabled;
• whether a patch already exists.

Step 3. Look at the vector

You do not need to memorize every letter. Just answer a few simple questions:

• where does the attack start;
• does the attacker need to steal or guess something first;
• does a user need to click;
• what breaks if the attack succeeds.

Step 4. Check whether it is actually reachable in your environment

Public service, internal service, disabled feature, a separate VPN-protected admin path — all of that changes the picture much more than the score alone.

Step 5. Judge urgency

Look at three things together:

• the CVSS score;
• whether there is a POC or exploit;
• whether active exploitation is already happening.

If those three line up, patch fast. If they do not, you may still use a testing window, but do not forget to use it.

Step 6. Pick an action

The usual options are:

• patch — if the update is available and the risk is truly high;
• mitigation — if you need to reduce the risk temporarily until the update;
• observation — if you are not affected or the issue does not currently reach your system.

Common mistakes

1. Believing only the number

9.8 is not a magic “everything is burning” button. Sometimes it is real danger, sometimes it is just a loud headline.

2. Ignoring a moderate score

Even a 5.0 can be unpleasant if the service is public, the data matters, and the patch already exists.

3. Forgetting context

CVSS does not know that your vulnerable feature is disabled or hidden behind another layer of protection.

4. Patching without checking

After the update, do not just celebrate. Check the service, login flow, critical paths, and logs. Otherwise you may close one hole and open another problem.

Conclusion / action plan

CVSS is useful as a prioritization filter. But the final decision always belongs to your context.

A simple flow works well:

1. Look at the number.
2. Read the vector.
3. Compare it with how your service actually works.
4. If the service is internet-facing, the attack is easy, and there is already a POC or exploit, move toward patching without delay.
5. If you are not affected yet, record it and move on.

CVSS does not tell you everything by itself. It tells you where to look first.

Official sources:

• https://www.first.org/cvss/
• https://www.first.org/cvss/specification-document
• https://nvd.nist.gov/vuln-metrics/cvss