CVSS 4.0 Examples: 15 Common Pentest Findings Scored

CVSS 4.0 was published by FIRST on 1 November 2023. The change that matters for a tester is that it stopped folding "what else does this reach" into a single Scope flag and started asking about it directly, through a separate set of impact metrics for systems beyond the vulnerable one. The fifteen findings below are the ones that turn up in nearly every web, infrastructure, Active Directory, cloud and API test. Each has a full 4.0 base vector, the score that vector gives, its 3.1 vector and score beside it, and a short account of which metrics decided the number.

Every score on this page was computed from the vector with the same method the reference calculator uses, not read off from memory, and a sample was checked against the worked examples FIRST publishes. The point of the page is the reasoning: a score you cannot reconstruct from your own description is a score you cannot defend when a client pushes back.

Reading a 4.0 vector

A 4.0 base vector has eleven metrics. Four are familiar from 3.1 (Attack Vector, Attack Complexity, Privileges Required, User Interaction). The rest are where 4.0 earns its keep, and three of them trip people up most often.

Attack Requirements (AT) is new, and it carries weight that used to be crammed into Attack Complexity. It is None when the attack does not depend on the target being in a particular state, and Present when it does: a race that has to be won, or a position on the network path that has to be held, as with an on-path attacker. Attack Complexity in 4.0 is now reserved for the attacker actively defeating a defence, such as a mitigation that has to be bypassed, so a reliable on-path attack is AC:L/AT:P, not AC:H.

The subsequent-system impacts (SC, SI, SA) are the other half of the split. The three V metrics (VC, VI, VA) describe the loss on the vulnerable system itself. The three S metrics describe loss on anything beyond it, which is where a container escape, an authentication relay or a cross-tenant effect lands. When the impact stays inside the vulnerable component, the subsequent set is N across the board. This is the direct replacement for 3.1's Scope, and it behaves very differently, as the comparison section shows.

User Interaction (UI) now has three values, not two. None needs no victim at all. Passive is limited, involuntary interaction, such as a user viewing a page that renders a stored payload. Active means the victim has to be led into a specific, conscious action, such as following a crafted link or submitting a particular string. Stored cross-site scripting is usually Passive; reflected and self cross-site scripting are Active. In 3.1 both collapsed into UI:R, so two findings that felt different scored the same.

Web: SQL injection (unauthenticated)

Reachable over the network with no account and no victim, so AV:N, PR:N, UI:N. It is reliable once found, so AC:L/AT:N. The injection reads and writes the database the application speaks to, which is the vulnerable system, so VC:H/VI:H with availability untouched at VA:N. Nothing crosses into another security authority in this base case, so the subsequent set stays N. If you went on to reach the host or a separate backend, that is its own finding with its own vector, not a reason to raise this one.

Web: stored cross-site scripting

A low-privileged account plants the payload, so PR:L. The victim does nothing deliberate beyond viewing the page that renders it, which is Passive interaction, UI:P. The payload runs in the victim's browser, a system other than the application that stored it, so the loss is recorded as subsequent, SC:L/SI:L, and the vulnerable-system impacts are N. Keep the impacts Low unless you actually demonstrated session theft or a privileged action, in which case they rise and you say why.

Web: reflected cross-site scripting

No account is needed to craft the link, so PR:N, but the victim has to be led into following it, which is a conscious action, so UI:A. As with the stored case the effect lands in the victim's browser, so the impact is subsequent and Low. This is the clearest reason to prefer 4.0 for a client who reads scores: 4.0 separates the passive stored case from the active reflected case, where 3.1 scored both as UI:R and left the difference in the prose.

Web: broken access control (IDOR)

An authenticated user changes an identifier and reads records belonging to other users, so PR:L, UI:N, confidentiality VC:H and integrity untouched at VI:N. The data sits inside the same application, so there is no subsequent-system impact. The same facts land this finding in High under 4.0 and Medium under 3.1, which is worth knowing before a client who has seen the 3.1 number questions the 4.0 one.

Infrastructure: unsupported software with a known unauthenticated RCE

A network service running a version with a public, unauthenticated remote code execution flaw: AV:N, PR:N, UI:N, and full loss of confidentiality, integrity and availability on the host, VC:H/VI:H/VA:H. Both versions make it Critical. Where a published exploit exists you may record that in a threat metric rather than inflating the base, which the threat-metrics section covers.

Infrastructure: default credentials on an administrative interface

The documented default password still works on an interface that administers the system. PR:N because the credential is public knowledge rather than something the attacker already holds, which is the common error here: the interface asking for a login does not make this PR:L. Full administrative control gives VC:H/VI:H/VA:H. If the interface governs other systems too, the subsequent set rises and the finding is more serious still.

Infrastructure: weak transport encryption

Deprecated protocol versions or weak ciphers, where an attacker who can sit on the path may recover some traffic. The attack depends on holding that path, which in 4.0 is AT:P with AC:L, not the overloaded AC:H that 3.1 forced. That single modelling change is why the same weakness is Medium in 4.0 and Low in 3.1. Keep confidentiality Low unless you actually recovered sensitive data, in which case it is a stronger finding on its own facts.

Infrastructure: SMB signing not required

The server that does not require signing is not itself harmed. The risk is that an on-path attacker relays authentication to a different system, so the impact is recorded as subsequent, SC:H/SI:H, with the vulnerable-system impacts N, AV:A for the network position and AT:P for the on-path condition. This is the sharpest disagreement on the page: 4.0 reads subsequent-only impact as Medium, while 3.1 modelled the relay as a scope change with high confidentiality and integrity and reached High. The 4.0 number is the more honest description of a weakness whose consequence is entirely on another host.

Active Directory: Kerberoasting

Any domain account can request the tickets, so PR:L. Success depends on a service account having a password weak enough to recover offline, which is a condition of the environment rather than the attacker, so AT:P. This vector assumes the recovered account grants broad domain access, hence the full subsequent-system impact; where the account is unprivileged, the impact set and the score drop, and you say which case you are describing. Scoring the realistic consequence rather than the worst imaginable one is the habit that keeps findings defensible.

Active Directory: AD Certificate Services misconfiguration

A certificate template that lets a low-privileged account obtain a certificate for a higher-privileged identity is a reliable path to domain compromise: PR:L, AC:L/AT:N, and full impact on the vulnerable system and on the domain beyond it. Both versions rate it Critical. The subsequent-system impacts carry the "this reaches the whole domain" meaning that 3.1 expressed with a scope change.

Active Directory: LLMNR and NBT-NS response spoofing

Answering name-resolution broadcasts to capture authentication material needs a position on the local segment, so AV:A, and depends on a host actually making a mistyped or failed lookup, which is a condition outside the attacker's control, so AT:P. The captured material is a confidentiality loss, VC:H. As with weak transport encryption, 4.0's AT:P is a lighter and more accurate description of the on-path condition than 3.1's AC:H.

Cloud: public object storage exposing data

A storage container readable by anyone on the internet, holding sensitive data: AV:N, PR:N, UI:N, confidentiality VC:H, with integrity and availability untouched. 4.0 scores a clean single-property confidentiality loss higher than 3.1 does, 8.7 against 7.5, which surprises people the first time they see it. If the data is not sensitive, confidentiality is VC:L and the finding is modest, so the write-up has to say what was actually exposed.

Cloud: IAM privilege escalation to account administrator

A low-privileged principal that can grant itself administrator rights, through a permissive policy or a usable escalation path, compromises the whole account. PR:L for the starting identity, full impact on the vulnerable identity service and on every other service it then governs, so the subsequent set is H throughout. Both versions make this Critical, correctly.

API: broken object-level authorisation (BOLA)

The API accepts an authenticated token but does not check that the object requested belongs to that caller, so a user reads and alters other users' objects: PR:L, confidentiality and integrity VC:H/VI:H, availability untouched. Where the endpoint only exposes data and offers no change, drop integrity to VI:N and the score falls, which is the common adjustment between a read-only and a read-write BOLA.

API: no rate limiting on an authentication endpoint

An authentication endpoint that does not throttle attempts lets an attacker try credentials at scale. Success depends on a weak or reused credential existing in the first place, a condition of the environment, so AT:P, with modest confidentiality and integrity impact modelled as Low because a single guessed account is the realistic outcome of the weakness itself. If you demonstrated a full takeover, that takeover is the finding, scored on its own.

Where 3.1 and 4.0 disagree, and why

Across the fifteen, four mechanisms account for nearly every difference, and naming them settles most arguments before they start.

• Attack Requirements replaced an overloaded Attack Complexity. In 3.1 an on-path condition had nowhere to go but AC:H, which crushed the score. In 4.0 it is AT:P with AC:L, and Attack Complexity is kept for actively defeating a defence. Weak transport encryption rises from Low to Medium on this change alone.
• Subsequent-system impact is not a scope flag. 3.1's scope change raised a finding when the impact crossed a boundary. 4.0 records the impact where it lands, and a weakness whose only consequence is on another system, such as SMB relay, scores as Medium rather than High. This is deliberate, and it is the harder number to explain to a client used to 3.1.
• User Interaction has three values. Passive against Active separates stored from reflected cross-site scripting, which 3.1 scored alike.
• A single clean impact scores higher in 4.0. A public bucket losing only confidentiality is 8.7 in 4.0 against 7.5 in 3.1. The curves are simply different, and a finding that is High in both can still carry two different numbers.

None of this means one version is right and the other wrong. It means a report must say which version it used, because the same facts give two defensible numbers. The guide on penetration testing severity levels covers mapping either score onto your own scale.

Threat metrics and base-only publishing

The base metrics are the whole of what this page scores. 4.0 also defines threat metrics (whether a usable exploit is known) and environmental metrics (how exposed and how valuable the asset is to a specific client). FIRST names the combinations: CVSS-B is base only, CVSS-BT adds threat, CVSS-BE adds environmental, and CVSS-BTE carries all three.

• Publish the base score (CVSS-B) in the finding, because it is comparable across clients and does not go stale.
• If you want to reflect a known exploit, set Exploit Maturity rather than inflating the base. Leaving it undefined is scored as the worst case, so an unset threat metric never lowers a base score by accident.
• Environmental adjustment belongs to the client's own view of an asset, so a tester gives the base and explains in the narrative what would raise or lower it, rather than guessing the client's environment.
• Supplemental metrics (such as recovery or value density) are informational only and never change the number.

For most reports, a base score plus a plain sentence on exposure is clearer than a single environment-adjusted number the client cannot reproduce. The reasoning on CVSS scoring mistakes in pentest reports makes the same case for keeping the base visible.

Settling a scoring dispute

A finding with a shaky score invites a conversation about the score instead of the fix, so it is worth closing that door before it opens.

1. Agree the version first. A 3.1 number and a 4.0 number are both right for the same weakness, so half of all disputes are really about which version is on the page.
2. Read the vector back against the description. If a competent reader could not rebuild your vector from your own words, one of the two is wrong, and that is the thing to fix.
3. Check the arithmetic from the vector, not from how severe the issue felt. The score a vector gives is fixed, so a number that does not match its vector is indefensible.
4. Separate base from exposure. If the client thinks it should be higher or lower, that is usually an environmental point, and it belongs beside the base score rather than inside it.
5. Record the one sentence of reasoning that names what decided the vector. A finding that carries its own justification rarely gets argued twice.

When your firm reuses a weakness, the vector it already argued about should travel with it, so instances start consistent and get adjusted rather than invented from scratch each time. That is the case for keeping scored findings in a reusable library rather than in last month's reports.