Four metrics in the CVSS base score decide whether a finding is a “patch this weekend” problem or a “patch this quarter” problem: Attack Vector, Attack Complexity (split into Attack Complexity and Attack Requirements in CVSS 4.0), Privileges Required and User Interaction. Analysts who can read these correctly in the first ten seconds of triage stop wasting escalation budget on findings that look scary in a scanner report but are not actually reachable, and stop under-reacting to the ones that are.
Attack Vector values in plain terms
Attack Vector (AV) describes how close an attacker has to be to the vulnerable component, not how dangerous the bug is. There are four values, and each has a well known real world example that makes the boundary obvious.
| Value | Meaning | Example |
|---|---|---|
| Network (AV:N) | Exploitable from a remote network, no local segment access needed | Log4Shell, CVE-2021-44228, exploitable by sending a crafted string over any protocol the vulnerable app logged, from anywhere on the internet |
| Adjacent (AV:A) | Requires being on the same broadcast domain, Bluetooth range, or Wi-Fi segment | CVE-2017-1000251, the Linux kernel Bluetooth stack overflow disclosed as part of BlueBorne, only reachable from within radio range |
| Local (AV:L) | Requires local access or execution on the target already, such as a shell or a malicious local file | Dirty COW, CVE-2016-5195, a local privilege escalation race condition that assumes the attacker can already run code as a low privileged user |
| Physical (AV:P) | Requires physically touching or being physically near the device | Firmware and DMA based attacks against unattended hardware, where the attacker needs a few minutes alone with the machine, such as cold boot memory extraction or Thunderbolt controller tampering |
Notice the pattern: AV answers “where does the attacker need to stand,” not “how bad is the impact.” A Local vulnerability can still carry a Critical severity once you factor in Confidentiality, Integrity and Availability impact, so do not let AV:L talk you into deprioritizing something that is trivially chainable with an initial foothold bug.
The most common scoring error: calling something Network when it needs a foothold first
The single most frequent mistake in vendor advisories and scanner output is inheriting AV:N for a vulnerability that is only reachable after a separate access step. CVSS scoring guidance is explicit that you score the vulnerability being rated, using the most direct path an attacker would take to exploit it, not the theoretical worst case chain that starts from the open internet.
A concrete pattern: an internal admin panel has a deserialization bug. The panel itself binds to a private RFC 1918 range and is not internet facing. A scanner that fingerprints the software version pulls the NVD entry, which lists AV:N because the vendor scored the bug in isolation, assuming direct network access to the panel is possible in some deployments. If your scanner or ticketing pipeline copies that score verbatim, every internal instance of that panel gets flagged as internet exploitable, and your SOC spends the week chasing a finding that actually requires an attacker to already be inside the network segment, which makes it AV:A or AV:L in your environment, not AV:N.
Platforms that ingest scanner output at scale, such as SITEY, address this by re-deriving the effective Attack Vector from the network path the finding was actually reached on during the scan, rather than trusting the CVSS vector shipped in the plugin metadata. If the scanning agent reached the service only through an internal-only subnet with no route from an untrusted zone, the effective vector gets recorded separately from the nominal NVD vector, and the two are shown side by side so a human can see the gap. Build the same habit manually if you are not running that kind of pipeline: every time you see AV:N on an internal asset, ask “can I reach this from outside without already having a session inside,” and if the answer is no, downgrade it in your own tracking before it hits an SLA clock.
Attack Complexity vs the new Attack Requirements metric
CVSS 3.1 attack complexity (AC:Low or AC:High) conflated two different ideas into one value: how much attacker skill and tooling is needed, and how many external conditions have to line up that the attacker does not control. CVSS 4.0 split this cleanly.
- Attack Complexity (AC) in 4.0 now covers only conditions the attacker has to actively evade or defeat through their own effort, for example bypassing ASLR, winning a narrow race condition window, or reverse engineering an undocumented protocol.
- Attack Requirements (AT) is the new metric covering deployment and configuration prerequisites that exist independent of attacker skill, for example the target must be running a non-default plugin, the attacker must already occupy a man in the middle position, or the victim must have a specific feature flag enabled.
Why this split matters for triage: a High Attack Complexity in the old model told you nothing about whether the blocker was “the attacker needs to be exceptionally skilled” versus “the target needs to be misconfigured in a specific way that most deployments do not have.” Those two situations call for different responses. The first means assume a capable adversary can eventually clear the bar. The second means check your own configuration against the precondition before you spend remediation effort at all, because if the precondition does not apply to you, the finding is not exploitable in your environment regardless of attacker skill.
Privileges Required and User Interaction: the two metrics that decide whether a bug is wormable
Privileges Required (PR: None, Low, High) and User Interaction (UI: None, Passive, Active in 4.0, or None, Required in 3.1) together answer the question that matters most for outbreak potential: can this vulnerability spread without a human doing anything and without the attacker holding a credential.
EternalBlue, CVE-2017-0144, scores PR:N and UI:N: no credentials, no click, no attachment opened. That combination is exactly why WannaCry and NotPetya could self-propagate machine to machine across a network without any social engineering step. Compare that to a browser RCE that requires the victim to visit a crafted page, UI:A (active interaction) in 4.0 terms, or a bug that needs a valid low privileged account, PR:L. Both can still be Critical severity, but neither spreads on its own the way a PR:N/UI:N bug does, because each hop needs a fresh human action or a fresh credential.
The practical triage rule: treat any finding scoring PR:N combined with UI:N (or UI:P, passive interaction such as simply having a device on the network) as a worm candidate and route it for immediate patching regardless of what the raw base score says, because the base score does not weight propagation speed on its own. This is the kind of pattern automated triage stages are built to catch consistently across thousands of findings, flagging the PR:N and UI:N combination for expedited handling before a human ever opens the ticket, which is the kind of check worth automating in an AI triage stage precisely because analysts under time pressure tend to anchor on the numeric score and skip the underlying combination.
Reading a vector string left to right in ten seconds during triage
Take a real string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Read it as a sequence of five questions, in order, before you ever look at the final numeric score.
- AV:N, where does the attacker stand: anywhere on the network, no proximity or local access needed.
- AC:L, how hard is it to pull off: no special conditions to defeat, works reliably on the first try.
- PR:N, what does the attacker need to already hold: nothing, zero credentials.
- UI:N, does a victim need to do anything: no, fully unattended.
- C:H/I:H/A:H, what happens if it lands: full compromise of confidentiality, integrity and availability.
Five yeses in the worst direction on the first four tokens plus high impact is the profile of an internet worm waiting to happen, independent of whatever numeric base score the tool displays. Train yourself to read those first four letters before the number, because two findings can carry the same 9.8 base score for very different reasons, and only one of them is actually exploitable against your specific deployment once you check AV and AT against your real topology.
How these four metrics map onto your segmentation reality
CVSS base scores assume a generic deployment. Your network is not generic, so the effective risk of an AV:A or AV:N finding depends on facts the base score cannot see.
- A flat network with no VLAN separation between workstations and servers turns every AV:A finding into an effective AV:N finding, because any compromised laptop is already “adjacent” to everything.
- A host reachable only through a bastion or jump box with no direct inbound route from an untrusted zone can turn a nominal AV:N finding into an effective AV:A or even AV:L finding in practice, because the attacker needs to land on the jump box first.
- A management interface exposed only on an out of band network with strict ACLs should never inherit the vendor’s AV:N score wholesale, even if the software itself would accept connections from anywhere.
This is where an accurate asset inventory that records real network zones, paired with active network reachability testing rather than assumed topology, changes the outcome of a triage decision. SITEY’s discovery phase maps which hosts can actually route to which other hosts before scoring is finalized, so a finding on an internal-only database server does not carry the same urgency as the identical CVE on a host with a public IP, even though both start from the same NVD base vector. Feed that same discipline into your own process manually: before you accept a vendor or scanner AV value, walk the actual firewall rules and VLAN ACLs between “the internet” and the affected host, and record the effective vector alongside the nominal one in whatever system tracks the finding through its lifecycle, so the person who eventually verifies the fix knows which vector assumption the priority was based on.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.