skip to content

What does the CVSS v3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N tell you about a flaw?

level: middleimportance: must knowfreq 68%

answer

  1. eight fields, two halves
  2. how hard to reach versus how bad
  3. AV AC PR UI, then S, then C I A
  4. N means opposite things per half
  5. one field decides whose component

basics

~20 s

A CVSS v3.1 base vector: network-reachable with low complexity, needing no privileges and no user interaction, escaping its own security scope to fully compromise confidentiality and integrity in the component it reaches, with no availability impact.

solid answer

~40 s

It is a CVSS v3.1 **base** vector, so it describes only the flaw's intrinsic properties. The first four metrics are the exploitability half: `AV:N` means it is reachable over a routable network, `AC:L` that no special conditions outside the attacker's control are needed, `PR:N` that the attacker holds no account at all, and `UI:N` that no other person has to act. `S:C` says the exploit escapes the vulnerable component's own security authority, so the impact half rates the component it reaches: `C:H` and `I:H` are total loss of confidentiality and integrity there, `A:N` no availability loss. A concrete fit is an authentication bypass in an edge reverse proxy that an anonymous internet user reaches, exposing the credentials and routing configuration behind it. That combination scores 10.0, Critical.

go deeper

for a junior

Be able to expand all eight CVSS v3.1 base abbreviations on sight — AV, AC, PR, UI, S, C, I, A — and say which of the two halves each one belongs to.

for a middle

Expect to read a full vector aloud and justify every value from a described flaw, especially that Attack Complexity is about conditions outside the attacker's control rather than the effort involved.

for a senior

You will be handed a system description and asked to produce the vector yourself, then defend it against a colleague who scored User Interaction or Privileges Required differently.

for a principal

Own whether raters across your teams produce the same vector for the same flaw: written scoring guidance, worked reference vectors and periodic calibration are what make the numbers comparable at all.

## What a vector string is A CVSS vector string is a compact, machine-readable record of how one flaw was rated. It opens with the version prefix `CVSS:3.1/` and then lists metric abbreviations and their values, separated by slashes, in a fixed order. The vector is the analysis; the number is derived from it. That is why practitioners argue about vectors rather than about scores — two people who publish the same vector have agreed on every judgment that matters. CVSS v3.1 defines three metric groups: - **Base** — intrinsic properties of the flaw that do not change with time and do not depend on where it is deployed. This is the only mandatory group; a bare vector like the one in the question is a base vector. - **Temporal** — Exploit Code Maturity (`E`), Remediation Level (`RL`) and Report Confidence (`RC`). These act as multipliers that can only reduce the base score: no working exploit is known yet, an official fix shipped, the report is unconfirmed. - **Environmental** — modified copies of the base metrics plus security requirements, applied by whoever runs the software to reflect their own installation. ## The eight base metrics | Metric | Values | What it measures | | --- | --- | --- | | `AV` Attack Vector | Network, Adjacent, Local, Physical | how far from the target the attacker must be | | `AC` Attack Complexity | Low, High | conditions outside the attacker's control that must hold | | `PR` Privileges Required | None, Low, High | the account the attacker must already hold | | `UI` User Interaction | None, Required | whether a human other than the attacker must act | | `S` Scope | Unchanged, Changed | whether impact stays inside the vulnerable component's security authority | | `C` `I` `A` Impact | High, Low, None | loss of confidentiality, integrity, availability | The first four are the **exploitability** half — how hard the flaw is to reach and set off. The last three are the **impact** half — how bad it is once it fires. Scope sits between them and steers both, because it decides *whose* component the impact metrics describe. ## Walking this vector `AV:N` — reachable from any routable network, the widest value; the attacker needs no local presence and no adjacency to the target's link layer. `AC:L` — nothing beyond the attacker's control has to line up: no race to win, no per-target secret to collect, no unusual configuration. `PR:N` — no account, no session, nothing. `UI:N` — the attacker acts alone. `S:C` — the exploit crosses out of the vulnerable component's security authority. `C:H` and `I:H` — total loss of confidentiality and integrity on the component that impact reaches. `A:N` — nothing stops serving. A design that produces exactly this vector: an edge reverse proxy that terminates TLS and authenticates callers on behalf of the services behind it. An authentication bypass lets an anonymous internet user pass through as if authorized, reading and altering the credentials and routing configuration the proxy holds for those backends. The attacker position is the broadest one there is; the asset at stake is credentials and routing truth, not end-user records. The arithmetic follows: the exploitability half is at its maximum, two of three impact metrics are High, and Scope Changed applies its 1.08 multiplier, pushing the result to the 10.0 cap — Critical, the 9.0–10.0 band. Note that a flaw with no availability impact at all still reaches 10.0. Nothing about the base score is an average of the eight fields. ## The three things people misread **Attack Complexity is not attacker skill.** `AC:H` is reserved for conditions the attacker cannot arrange — winning a race, needing a machine-in-the-middle position, harvesting a target-specific value first. Work that is fiddly but succeeds every time is still `AC:L`. **Privileges Required is about the attacker, User Interaction is about someone else.** `PR` asks what account the attacker must already have on the vulnerable component. `UI` asks whether a different human — usually the victim — must click, open or approve something. **`N` means opposite things in the two halves.** In the exploitability half `None` means no barrier, which raises the score. In the impact half `None` means no damage, which lowers it. `PR:N/A:N` in one vector is not a contradiction. ## Change one fact and the vector moves If the same class of flaw sits in a mobile banking SDK where the customer must open a crafted deep link before anything happens, `UI:N` becomes `UI:R` — and that single letter is frequently the entire disagreement between two raters. If instead the affected system is an air-gapped process historian in a water-treatment plant, reachable only from a maintenance bay by someone with an engineering account, `AV:N` becomes `AV:P` and `PR:N` becomes `PR:H`. The exploitability half collapses and the base score drops sharply while `C`, `I` and `A` are untouched. That is the base group behaving exactly as designed: it measures the flaw, not your deployment. The temporal and environmental groups exist precisely because the base group refuses to.

  • The same flaw class appears in a mobile banking SDK where the customer must open a crafted deep link first. Which metric moves?
    User Interaction goes from `UI:N` to `UI:R`, because a human other than the attacker has to act before the exploit proceeds. Nothing else changes: the attacker still needs no account, so `PR` stays `None`, and the impact metrics are unaffected. `UI:R` lowers the exploitability half meaningfully, and it is one of the most common points of genuine rater disagreement — the test is whether the exploit can complete with no second party doing anything.
  • How would this vector change for an air-gapped process historian reachable only from a maintenance bay?
    `AV:N` becomes `AV:P` and `PR:N` typically becomes `PR:H`, since the attacker needs physical access to the bay and an engineering account. The exploitability half drops hard and the base score with it, while `C:H`/`I:H` stay exactly as they were — the consequence to the physical process has not changed at all. That gap is intentional: the base group rates the flaw, and the other metric groups exist to carry the deployment.
  • Why does a CVSS v3.1 base vector deliberately ignore whether a working exploit exists?
    Exploit availability changes over time, so it belongs to the temporal group — Exploit Code Maturity, alongside Remediation Level and Report Confidence — not to the base group, which is meant to be a stable, portable statement about the flaw itself. Temporal metrics act as multipliers that can only pull the base score down. Publishing a base-only vector is normal practice; it is the part everyone can agree on regardless of when or where they read it.

Reading a vector is like reading a lab result: each field is a separate measurement, and the severity band at the bottom is only a summary of them.

saying these in an interview costs you the question

  • Reads AV:N as the attacker being on the same LAN
  • Reads AC:L as low impact rather than low attack complexity
  • Thinks AC:H just means the attack is technically difficult
  • Says PR describes the victim's privileges, not the attacker's
  • Treats UI:N as meaning the product has no user interface
  • Claims a base vector already reflects exploit availability

context