Der Availability-Vektor im CVSS
Verfügbarkeit ist im CVSS ein eigenständiges Schutzziel. Wie der Availability-Vektor funktioniert und warum eine Lücke ganz ohne Datenabfluss CVSS 7.5 erreicht.
Die übersehene dritte Dimension
Wer einen CVSS-Vektor liest, achtet fast reflexhaft auf Vertraulichkeit und Integrität. Wurden Daten abgegriffen, wurden sie verändert? Die dritte Auswirkungs-Metrik, die Verfügbarkeit, gilt im Alltag vieler Teams als die unspektakuläre. Dabei kann eine Schwachstelle, die weder ein einziges Datum ausliest noch verändert, durchaus eine hohe Wertung tragen. Eine Lücke mit dem Vektor C:N/I:N/A:H erreicht im CVSS eine glatte 7.5 und landet damit im hohen Schweregradbereich, obwohl ihr einziger Effekt darin besteht, einen Dienst lahmzulegen. Dieser Beitrag zeigt, wie der Availability-Vektor aufgebaut ist, worin sich seine zwei Schadensstufen unterscheiden und warum reine Verfügbarkeitslücken in der Praxis konsequent unterschätzt werden.
Verfügbarkeit als eigenständiges Schutzziel
Die Auswirkungs-Metriken des CVSS bilden die klassische Schutzziel-Trias ab: Confidentiality, Integrity und Availability. Im Vektor stehen sie als die letzten drei Komponenten, etwa C:N/I:N/A:H. Jede dieser drei Metriken wird unabhängig bewertet, und genau das ist der entscheidende Punkt. Eine Schwachstelle muss nicht auf alle drei Schutzziele wirken, um schwer zu wiegen. Sie kann ihren gesamten Schaden auf eine einzige Dimension konzentrieren.
Die Availability-Metrik misst dabei die Auswirkung auf die Erreichbarkeit und Funktionsfähigkeit der betroffenen Komponente, nicht auf die Daten darin. Es geht nicht darum, ob jemand Informationen einsehen oder manipulieren kann, sondern darum, ob legitime Nutzer den Dienst noch erreichen. Ein abgestürzter Webserver, eine erschöpfte Datenbankverbindung, eine in eine Endlosschleife getriebene Verarbeitungsroutine: All das sind reine Verfügbarkeitsverluste, die im CVSS sauber über die A-Metrik abgebildet werden, während C und I auf None stehen bleiben.
Die drei Stufen: None, Low und High
Der Availability-Vektor kennt drei Ausprägungen, deren Wortlaut die offizielle CVSS-3.1-Spezifikation von FIRST.org festlegt.
| Wert | Bedeutung |
|---|---|
| None (N) | Keine Auswirkung auf die Verfügbarkeit. |
| Low (L) | Die Leistung ist spürbar reduziert oder es kommt zu Unterbrechungen. Der Dienst lässt sich aber nicht vollständig verweigern, selbst bei wiederholter Ausnutzung. |
| High (H) | Vollständiger Verlust der Verfügbarkeit. Der Angreifer kann den Zugriff auf die betroffene Ressource komplett verweigern, anhaltend oder dauerhaft. |
Die Grenze zwischen Low und High verläuft also entlang der Frage, ob ein Angreifer den Dienst nur stört oder ihn vollständig unbenutzbar macht. Eine API, die unter einer gezielten Anfrage merklich langsamer antwortet, rechtfertigt ein A:L. Ein Server, der nach einer einzigen Anfrage gar nicht mehr antwortet, ist ein klares A:H.
Sustained gegen persistent: warum die Dauer zählt
Innerhalb der Stufe High trifft die Spezifikation eine Unterscheidung, die in der Praxis oft untergeht, für die Bewertung aber zentral ist. Ein vollständiger Verfügbarkeitsverlust kann sustained sein, also nur so lange anhalten, wie der Angreifer den Angriff aktiv aufrechterhält. Oder er ist persistent und besteht fort, auch nachdem der Angriff längst beendet ist.
Der klassische DDoS-Angriff ist der Lehrbuchfall für die erste Variante. Solange das Botnetz das Ziel mit Anfragen flutet, ist der Dienst nicht erreichbar. Hört der Beschuss auf, erholt sich das System von selbst. Der Schaden ist real, aber an die Anwesenheit des Angreifers gekoppelt.
Die zweite Variante ist tückischer. Hier genügt ein einziger Auslöser, und der Zustand bleibt bestehen, ohne dass der Angreifer noch irgendetwas tun müsste. Solche persistenten Verfügbarkeitslücken sind aus Verteidigersicht deutlich unangenehmer, weil das simple Abklingen der Angriffslast nicht zur Erholung führt. Der Dienst bleibt unten, bis jemand manuell eingreift. Genau diese Eigenschaft macht den folgenden Fall zu einem so klaren Beispiel.
Der Mastodon-Fall: CVSS 7.5 ganz ohne Datenverlust
Im Rahmen unseres Research-Projekts zu Open Source Software ist unser Team in der Inhaltsverarbeitung von Mastodon, dem weit verbreiteten Server für das föderierte soziale Netzwerk, auf eine Schwachstelle gestoßen, die genau dieses Profil trägt. Sie wurde verantwortungsvoll gemeldet und ist als CVE-2026-50129 in den Versionen 4.5.11, 4.4.18 und 4.3.24 behoben. Die vollständige technische Analyse steht in unserem Advisory TP-2026-006.
Der Kern in einem Satz: Eine einzige präparierte ActivityPub-Nachricht von irgendeinem anderen Server im Verbund bringt einen unbehandelten Fehler im HTML-Sanitizer zum Auslösen, woraufhin die Instanz jeden Aufruf der öffentlichen Timeline mit einem Serverfehler beantwortet. Weil die Nachricht gespeichert bleibt, wiederholt sich der Absturz bei jedem weiteren Render-Aufruf. Selbst die Moderationsoberfläche kommt an den Beitrag nicht mehr heran, da sie denselben fehlerhaften Pfad nutzt. Eine Bereinigung erfordert direkten Zugriff auf Datenbank oder Konsole.
Der zugehörige Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H und ergibt eine 7.5. Es lohnt sich, ihn Metrik für Metrik zu lesen, weil er zeigt, wie ein Score zustande kommt, der ausschließlich aus Verfügbarkeit gespeist wird.
| Metrik | Wert | Begründung |
|---|---|---|
| Attack Vector | Network (N) | Auslösung über die Föderation, kein lokaler Zugang. |
| Attack Complexity | Low (L) | Eine einzelne wohlgeformte Nachricht genügt. |
| Privileges Required | None (N) | Kein Account auf dem Ziel nötig. |
| User Interaction | None (N) | Kein Zutun eines Opfers erforderlich. |
| Scope | Unchanged (U) | Der Schaden bleibt in der betroffenen Instanz. |
| Confidentiality | None (N) | Keine Daten werden ausgelesen. |
| Integrity | None (N) | Keine Daten werden verändert. |
| Availability | High (H) | Timeline und Moderation sind dauerhaft nicht erreichbar. |
Die Ausnutzbarkeits-Metriken stehen alle auf ihrem ungünstigsten Wert: aus der Ferne, ohne Hürde, ohne Anmeldung, ohne Mithilfe. Das treibt den Score nach oben. Gleichzeitig sind Vertraulichkeit und Integrität auf None, weil hier wirklich nichts ausgelesen oder verändert wird. Übrig bleibt eine reine Verfügbarkeitslücke, deren 7.5 sich vollständig aus dem A:H in Kombination mit der trivialen Ausnutzbarkeit speist. Wer die Wertung selbst nachvollziehen will, kann den Vektor im CVSS-Rechner Schritt für Schritt zusammensetzen.
Bemerkenswert ist auch, was den Score hier deckelt. Weil der Schaden die betroffene Instanz nicht verlässt, bleibt der Scope auf Unchanged. Und weil nur die Verfügbarkeit betroffen ist, fehlen die beiden anderen Impact-Dimensionen, die eine kritische 9er- oder 10er-Wertung ausmachen würden. Eine reine, persistente Verfügbarkeitslücke landet damit zuverlässig im hohen, aber nicht im kritischen Bereich.
Was sich mit CVSS 4.0 ändert
Mit CVSS 4.0 wurde die Verfügbarkeit feiner aufgelöst. Statt einer einzigen A-Metrik gibt es nun getrennte Werte für das verwundbare System (VA) und für nachgelagerte Systeme (SA). Die alte Scope-Metrik, die in 3.1 den Sprung über die Komponentengrenze markierte, ist dafür entfallen. Ein föderierter DoS wie im Mastodon-Fall würde in 4.0 über VA:H abgebildet, während ein Angriff, der von der verwundbaren Komponente auf dahinterliegende Systeme durchschlägt, zusätzlich SA:H trüge. Die CVSS-4.0-Spezifikation trennt damit sauberer, wessen Verfügbarkeit eigentlich leidet, behält aber die grundsätzliche Logik bei: Verfügbarkeit ist und bleibt ein eigenständiges Schutzziel mit eigenem Gewicht.
Warum reine Verfügbarkeitslücken unterschätzt werden
In Triage-Runden geraten Verfügbarkeitslücken oft ins Hintertreffen, weil kein Datenabfluss droht und der reflexhafte Gedanke lautet, man könne den Dienst ja einfach neu starten. Genau hier liegt der Denkfehler. Eine persistente Lücke übersteht den Neustart, weil der schädliche Zustand gespeichert ist. Und für Dienste, deren Wert in ihrer Erreichbarkeit liegt, ist ein dauerhafter Ausfall geschäftskritisch, egal ob dabei ein Byte abgeflossen ist. Eine Buchungsplattform, ein Behördenportal oder eine föderierte Kommunikationsinfrastruktur verlieren ihren Zweck in dem Moment, in dem niemand sie mehr erreicht.
Hinzu kommt die regulatorische Seite. Regelwerke wie die NIS-2-Richtlinie behandeln die Verfügbarkeit kritischer Dienste als ausdrückliches Schutzziel und verlangen Maßnahmen zur Aufrechterhaltung des Betriebs. Eine Verfügbarkeitslücke ist damit nicht nur ein technisches, sondern potenziell ein Compliance-Problem. Der CVSS-Vektor liefert dafür die präzise Sprache: Ein A:H ohne jedes C oder I sagt unmissverständlich, dass hier die Erreichbarkeit das Ziel ist und nichts anderes.
Fazit
Der Availability-Vektor ist kein Anhängsel der beiden prominenteren Schutzziele, sondern eine eigenständige Achse, auf der eine Schwachstelle ihren gesamten Schaden konzentrieren kann. Entscheidend für die Einordnung ist die Unterscheidung zwischen einem sustained Ausfall, der mit dem Angriff endet, und einem persistenten, der bestehen bleibt. Der Mastodon-Fall zeigt mustergültig, wie eine Lücke ganz ohne Datenverlust eine 7.5 erreicht: triviale, anonyme Auslösung über das Netz, kombiniert mit einem vollständigen und dauerhaften Verfügbarkeitsverlust. Wer Scores richtig lesen will, sollte deshalb den dritten Buchstaben im Impact-Teil des Vektors nie überlesen. Manchmal steckt dort die ganze Geschichte.