Safeguard
Security Guides•

My scanner says Attack Vector Network, but the service is internal

AV:N in a CVSS vector means a flaw is exploitable over a network, not that your service faces the internet. How to read it for internal hosts.

Safeguard Security Team
4 min read

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.

ValueVector textMeaning in the specification
NetworkAV:NNetwork-bound, attackers can come from anywhere up to the internet
AdjacentAV:ANetwork-bound, but limited to a logically adjacent topology such as the same segment or a restricted administrative domain
LocalAV:LNot network-bound, attacker uses local access or tricks a user into acting
PhysicalAV:PAttacker 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

  1. List who can open a connection to the port. Include other services, build agents, contractors on VPN and any proxy that forwards traffic.
  2. 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.
  3. Ask what an attacker needs to get onto that network. A phishing foothold on one laptop may be enough in a flat network.
  4. 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.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.