AV:N means the vulnerable component is bound to the network stack and can be attacked remotely at the protocol level. It does not mean your instance is reachable from the internet. For an internal service, AV:N tells you the flaw is not local-only, and your own network exposure decides the rest.
What the metric actually says
CVSS 3.1 defines four Attack Vector values.
| Value | Vector text | Meaning in the specification |
|---|---|---|
| Network | AV:N | Network-bound, attackers can come from anywhere up to the internet |
| Adjacent | AV:A | Network-bound, but limited to a logically adjacent topology such as the same segment or a restricted administrative domain |
| Local | AV:L | Not network-bound, attacker uses local access or tricks a user into acting |
| Physical | AV:P | Attacker must touch or manipulate the component |
The specification calls Network "remotely exploitable". That is a property of the vulnerability class, scored for a reasonable worst case. It is not a measurement of your firewall.
Why a score cannot know your topology
A scanner reads an advisory. The advisory was scored by someone describing the flaw in general. Whether your copy sits behind a gateway, a VPN, a service mesh or nothing at all is outside the record. The base score assumes the worst reasonable deployment, and the specification itself recommends adding environmental information, such as the controls in place around the component.
One more detail. For the choice between Network and Adjacent, the specification says that if an attack can come over a wide area network or from outside the adjacent domain, you use Network, even if the attacker must be on the intranet. That is why plenty of flaws in internal-only tools still carry AV:N.
A four-step check for an internal service
- List who can open a connection to the port. Include other services, build agents, contractors on VPN and any proxy that forwards traffic.
- Check whether the vulnerable code path handles data from those callers. A parser that only reads your own config files is a different case from one that reads request bodies.
- Ask what an attacker needs to get onto that network. A phishing foothold on one laptop may be enough in a flat network.
- Write the result down as an environmental note. For example: reachable from the corporate network only, no internet path, authenticated callers only.
If steps 1 and 2 give a narrow answer, the practical urgency drops. It does not drop to zero, because anyone who gets a foothold on that network can usually reach the service too.
What to avoid
- Dismissing AV:N findings because the host has no public address. Check the callers instead.
- Raising every AV:N finding to the top. Many network-facing libraries carry AV:N, so the metric alone separates little.
- Changing the scanner's score by hand with no record. If you adjust severity for your environment, keep the reasoning attached.
CVSS also has an environmental group designed for exactly this adjustment. If your tooling supports modified metrics, use those rather than editing the label.
Pair it with reachability
The question "can an attacker reach the service" has a sibling: "can an attacker reach the vulnerable code inside it". A dependency may be present in a network-facing service and still never be called. Looking at both gives a far better ranking than the vector alone.
Safeguard's reachability analysis shows whether your code calls the vulnerable function in a dependency, which complements your own view of network exposure. Try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look for which findings stay after the unreachable ones are set aside.
Quick check
Does AV:N mean the flaw is exploitable from the internet?
It means the component is network-bound and remotely exploitable at the protocol level. Whether your deployment is exposed depends on your own network and controls.
Should I lower severity for internal-only services?
You can record an environmental adjustment, but keep your reasoning with it. Internal services remain reachable by anyone who gets a foothold on that network.
Sources
Last reviewed: 19 October 2026.