A finding with C:N, I:N and A:H means an attacker can degrade or stop the component but cannot read or change data. Triage it by asking what goes down, who can trigger it, and what your platform does next. It may rank below a data exposure, or above one, depending on the service.
What the vector says
In CVSS 3.1, Availability impact High means total loss of availability, such as the attacker fully denying access to resources in the impacted component. The None values for confidentiality and integrity mean no loss of those within the component.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Read it as: an attacker over the network, with no account, no special conditions and no user action can take the component fully offline. The base score reflects the worst case across deployments, so the label may be High even though no data is at risk.
Five questions for the finding
- What is the component? A marketing site, a payment path and an internal batch job have different costs of downtime.
- Who can trigger it? Read AV and PR. PR:N with AV:N means anyone who can reach the service.
- Does it take one request or sustained effort? The advisory text will say. A single crafted request that crashes a process is different from a flaw that needs a flood of traffic.
- What happens after the failure? If the platform restarts the process in seconds, the effect is a blip. If the crash leaves corrupted state or needs manual recovery, it is more serious.
- Is there a safeguard in front? Rate limits, request size limits or an upstream filter may block the trigger. Note which, and confirm they apply to the vulnerable path.
Where it ranks
| Situation | Reasonable stance |
|---|---|
| Revenue path, no redundancy, anyone can trigger | Treat as urgent |
| Redundant service, automatic restart, anyone can trigger | Schedule soon, watch for exploitation |
| Internal job, authenticated trigger only | Normal cycle, record reasoning |
These are judgement calls, not rules. The specification itself says other factors outside CVSS, such as customer counts or monetary losses, may inform the remediation decision.
Link it to your resilience story
Availability findings are where your reliability work meets your security work. If you have health checks, autoscaling and circuit breakers, a denial of service might cost little. If you do not, it exposes that gap whether or not a patch exists. Use the finding as a prompt to check both.
Do not forget the combined effect
A denial of service in one component can open a door in another. If a security control, such as an authentication service or a logging pipeline, goes down and a dependent system fails open, an availability flaw can turn into an access problem. Ask what depends on the vulnerable component and what it does when the component is gone. This is a design question for your own system, not a property of the score.
Recording the decision
Write down: the component, who can trigger it, your mitigation, and the date you will recheck. If you defer, say what would change your mind, such as a public exploit or an incident.
Safeguard's asset discovery and reachability analysis help you see which services run the affected component and whether your code calls the flawed path. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Compare how impact and context shape a finding's priority.
Quick check
Is an A:H only finding low priority?
Not automatically. It depends on what the component does, who can trigger the failure and how your platform recovers.
Does availability impact mean data is at risk?
Not by itself. With C:N and I:N, the vector says no loss of confidentiality or integrity within the component.
Sources
Last reviewed: 19 October 2026.
