CVSS: how the severity of a vulnerability is calculated

Three groups of metrics feed the score. The base ones describe the flaw itself: where it can be exploited from, how complex the attack is, and what breaks. The second group covers circumstances that change over time, above all whether a public exploit exists. The third adjusts the result for a specific environment. Version 4.0 adds a supplemental group on top, which doesn’t enter the number.

• Can it be exploited over the network from outside, or does the attacker have to sit on the same segment?
• Does it need an account, and if so, is an ordinary user without privileges enough?
• Does someone have to click, or does it happen without any help from the operator?
• What breaks: the confidentiality of the data, its integrity, or the availability of the service?

The base part is calculated once and the same way for everyone, which is why it can be taken from databases. Nobody outside will calculate your environment for you, though. The same score of 8.8 means one thing on a test instance and something else on the system that sends out payments. A scanner prints the number and supplies no context, and where a scan ends and a manual test begins has its own comparison.

The vector writes every metric into a single line so the number can be recalculated and checked. It is read from left to right in pairs of metric and value: first the version of the standard, then where the attack comes from, how complex it is, whether it needs an account and user interaction, and finally the impact on confidentiality, integrity, and availability.

In version 3.1 there is one more field before impact, scope, meaning whether the consequence spills beyond the affected system. In version 4.0 the impact components come as two sets, one for the vulnerable system and one for the subsequent system.

It pays to read even when you trust the number. Two findings with the same score of 7.5 can have completely different vectors, one with impact on data and the other only on availability, and what you do with them differs accordingly. The vector is also the most reliable way to tell which version of the standard a number came from, because it carries the version right in its first field.

The number converts into a level expressed as a word, and that is what reports mostly work with. The standard distinguishes five levels, because it counts None for a score of 0.0 as well. A report works with four of them in practice, the ones in the table below, and we use them too so that a report can be compared with a deliverable from somewhere else.

The boundaries are sharp, reality isn’t: in live operation there is no visible difference between a finding of 6.9 and one of 7.0, even though one is Medium and the other High. The level is also only a description of the flaw, not of the system. The identifier of a vulnerability and how it comes about is a different matter from its rating.

Version 4.0 from 2023 answers three complaints about version 3.1 from 2019. It separates the impact on the vulnerable system from the impact on subsequent systems, it adds a metric for whether the attack can be automated, and it handles the public availability of an exploit better. The automation metric belongs to the supplemental group, so it doesn’t enter the number.

The range of 0 to 10 stays, but the calculation itself changed in 4.0: instead of the formula from 3.1, the result is read from tables that are part of the specification.

In practice you run into both, and the numbers don’t have to agree. Some records carry a rating under the old version next to one under the new, and a difference of a few tenths is normal. Before you compare two findings, check that they were calculated the same way: FIRST keeps the 3.1 specification publicly available next to the new version.

The move to 4.0 has a practical consequence too. The new version tends to give higher scores than 3.1, so more findings land in the High and Critical bands. For a company that means more items under pressure from internal SLAs and from the audit, even though nothing has actually changed on the systems and the score was only recalculated under a different version of the standard.

The score measures the properties of the flaw, not the value of the system the flaw sits in. Ten findings with a score of 7.5 can mean ten different risks depending on what runs on those systems and who can reach them. Sorting by the number therefore produces a list where things of widely different urgency meet at the top.

The score is only the start. The remediation priority also takes in how easily the finding can be exploited, how reachable the system is, and what sits behind it in the company. That is why a finding with a lower number sometimes goes into remediation first. The whole procedure of how we put the remediation priority together step by step is the subject of a separate article. How the score feeds into the remediation priority, and why a report carries both, is on the penetration testing page.

Our CVE-2026-39042 in MikroTik RouterOS has a score of 7.5 and the level High. The whole number rests on a single component of the vector, availability: an unauthenticated attacker takes the service down but doesn’t reach the data, so the impact on confidentiality and integrity is zero.

It is a textbook example of why the vector is read next to the number. The rating is public in the CVE-2026-39042 record in the NVD dated July 13, 2026, and what a finding whose score we calculated ourselves means for testing network devices belongs with that service.