The Availability Vector in CVSS

The Overlooked Third Dimension

When people read a CVSS vector, they almost reflexively look at confidentiality and integrity. Was data exfiltrated, was it tampered with? The third impact metric, availability, tends to be treated as the unspectacular one. Yet a vulnerability that neither reads a single piece of data nor modifies one can still carry a high score. A flaw with the vector C:N/I:N/A:H reaches a clean 7.5 in CVSS and lands squarely in the high severity range, even though its only effect is to take a service down. This article shows how the availability vector is structured, how its two damage levels differ, and why pure availability flaws are consistently underestimated in practice.

Availability as a Standalone Security Objective

The CVSS impact metrics map the classic security triad: confidentiality, integrity and availability. In the vector they appear as the final three components, for example C:N/I:N/A:H. Each of these three metrics is scored independently, and that is the decisive point. A vulnerability does not have to affect all three objectives to weigh heavily. It can concentrate its entire damage on a single dimension.

The availability metric measures the impact on the reachability and operability of the affected component, not on the data inside it. The question is not whether someone can view or manipulate information, but whether legitimate users can still reach the service. A crashed web server, an exhausted pool of database connections, a processing routine driven into an infinite loop: these are all pure availability losses, cleanly represented in CVSS through the A metric, while C and I remain at None.

The Three Levels: None, Low and High

The availability vector has three values, whose wording is set by the official CVSS 3.1 specification from FIRST.org.

Value	Meaning
None (N)	No impact on availability.
Low (L)	Performance is noticeably reduced or there are interruptions. The service cannot be fully denied, even under repeated exploitation.
High (H)	Total loss of availability. The attacker can fully deny access to the affected resource, either sustained or persistent.

The line between Low and High therefore runs along the question of whether an attacker merely disrupts a service or makes it completely unusable. An API that responds noticeably slower under a targeted request justifies an A:L. A server that stops responding entirely after a single request is a clear A:H.

Sustained Versus Persistent: Why Duration Matters

Within the High level, the specification draws a distinction that often goes unnoticed in practice but is central to scoring. A total loss of availability can be sustained, meaning it only lasts as long as the attacker actively maintains the attack. Or it can be persistent, continuing even after the attack has long ended.

The classic DDoS attack is the textbook case for the first variant. As long as the botnet floods the target with requests, the service is unreachable. Once the barrage stops, the system recovers on its own. The damage is real, but tied to the attacker's presence.

The second variant is more insidious. Here a single trigger is enough, and the condition persists without the attacker having to do anything further. Such persistent availability flaws are far more unpleasant from a defender's point of view, because simply letting the attack load subside does not lead to recovery. The service stays down until someone intervenes manually. It is precisely this property that makes the following case such a clear example.

The Mastodon Case: CVSS 7.5 With No Data Loss at All

As part of our research project into open source software, our team found a vulnerability in the content processing of Mastodon, the widely used server for the federated social network, that carries exactly this profile. It was disclosed responsibly and is fixed as CVE-2026-50129 in versions 4.5.11, 4.4.18 and 4.3.24. The full technical analysis is available in our advisory TP-2026-006.

The core in one sentence: a single crafted ActivityPub message from any other server in the federation triggers an unhandled error in the HTML sanitizer, after which the instance responds to every request for the public timeline with a server error. Because the message remains stored, the crash repeats on every subsequent render. Even the moderation interface can no longer reach the post, since it uses the same faulty path. Cleanup requires direct access to the database or console.

The corresponding vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H and yields a 7.5. It is worth reading it metric by metric, because it shows how a score that draws solely on availability comes about.

Metric	Value	Rationale
Attack Vector	Network (N)	Triggered over the federation, no local access.
Attack Complexity	Low (L)	A single well-formed message is enough.
Privileges Required	None (N)	No account on the target needed.
User Interaction	None (N)	No action by a victim required.
Scope	Unchanged (U)	The damage stays within the affected instance.
Confidentiality	None (N)	No data is read.
Integrity	None (N)	No data is altered.
Availability	High (H)	Timeline and moderation are permanently unreachable.

The exploitability metrics all sit at their worst value: remote, no hurdle, no login, no assistance. That drives the score up. At the same time, confidentiality and integrity are at None, because nothing here is actually read or modified. What remains is a pure availability flaw whose 7.5 is fed entirely by the A:H combined with the trivial exploitability. Anyone who wants to retrace the score can assemble the vector step by step in the CVSS calculator.

What caps the score here is just as instructive. Because the damage does not leave the affected instance, the scope stays at Unchanged. And because only availability is affected, the two other impact dimensions that would make for a critical 9 or 10 are missing. A pure, persistent availability flaw therefore reliably lands in the high but not the critical range.

What Changes With CVSS 4.0

With CVSS 4.0, availability was resolved more finely. Instead of a single A metric, there are now separate values for the vulnerable system (VA) and for subsequent systems (SA). The old scope metric, which marked the jump across the component boundary in 3.1, has been dropped in return. A federated DoS like the Mastodon case would be represented in 4.0 through VA:H, while an attack that propagates from the vulnerable component to downstream systems would additionally carry SA:H. The CVSS 4.0 specification thus separates more cleanly whose availability actually suffers, but keeps the underlying logic: availability is and remains a standalone security objective with its own weight.

Why Pure Availability Flaws Are Underestimated

In triage sessions, availability flaws often fall behind, because no data exposure looms and the reflexive thought is that you can simply restart the service. This is exactly where the fallacy lies. A persistent flaw survives the restart, because the harmful state is stored. And for services whose value lies in their reachability, a permanent outage is business-critical, regardless of whether a single byte was exposed. A booking platform, a government portal or a federated communication infrastructure lose their purpose the moment no one can reach them anymore.

There is also the regulatory side. Frameworks such as the NIS 2 Directive treat the availability of critical services as an explicit security objective and require measures to maintain operations. An availability flaw is therefore not only a technical problem but potentially a compliance one. The CVSS vector provides precise language for this: an A:H without any C or I says unambiguously that reachability is the target here, and nothing else.

Conclusion

The availability vector is not an appendage to the two more prominent security objectives but a standalone axis on which a vulnerability can concentrate all of its damage. What matters for classification is the distinction between a sustained outage that ends with the attack and a persistent one that lingers. The Mastodon case shows exemplarily how a flaw with no data loss reaches a 7.5: trivial, anonymous triggering over the network, combined with a total and permanent loss of availability. Anyone who wants to read scores correctly should therefore never skim over the third letter in the impact part of the vector. Sometimes the whole story sits right there.