Was ist eigentlich eine 10 von 10? Der perfekte CVSS-Score
Eine glatte 10.0 im CVSS ist selten und folgt einer exakten Metrik-Kombination. Was den perfekten Score ausmacht und woran die meisten Lücken bei 9.8 scheitern.
Die Zahl am Ende jedes Berichts
Jeder seriöse Pentest-Bericht und jede CVE-Meldung endet mit einer Zahl zwischen 0.0 und 10.0. Ab 9.0 spricht das CVSS von kritisch, und in diesem Bereich landen die meisten gefährlichen Lücken. Eine glatte 10.0 sieht man trotzdem selten. Sie ist kein Rundungsergebnis und auch kein Bauchgefühl des Analysten, sondern die Folge einer ganz bestimmten Kombination von Metriken, die alle gleichzeitig im ungünstigsten Zustand stehen müssen. Dieser Beitrag zeigt, welche Metriken das sind, warum die meisten schweren Befunde bei 9.8 hängen bleiben und was der Unterschied in der Praxis tatsächlich bedeutet.
Welche Metriken eine 10.0 erzwingen
In CVSS 3.1 setzt sich der Base Score aus acht Basismetriken zusammen. Für die Höchstwertung müssen alle acht ihren jeweils schlimmsten Wert annehmen. Der zugehörige Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.
| Metrik | Wert | Bedeutung |
|---|---|---|
| Attack Vector | Network (N) | über das Netz erreichbar, kein lokaler Zugang nötig |
| Attack Complexity | Low (L) | keine besonderen Vorbedingungen oder Race Conditions |
| Privileges Required | None (N) | keinerlei Authentifizierung erforderlich |
| User Interaction | None (N) | kein Zutun eines Opfers nötig |
| Scope | Changed (C) | die Wirkung reicht über die verwundbare Komponente hinaus |
| Confidentiality | High (H) | vollständiger Verlust der Vertraulichkeit |
| Integrity | High (H) | vollständiger Verlust der Integrität |
| Availability | High (H) | vollständiger Verlust der Verfügbarkeit |
Übersetzt in einen Satz heißt das: Eine unauthentifizierte Angreiferin erreicht das Ziel über das Netz, braucht weder einen Trick noch die Mithilfe eines Anwenders, und sie übernimmt am Ende nicht nur die betroffene Anwendung, sondern auch alles, was dahinter liegt. Das ist das Profil einer klassischen unauthentifizierten Remote Code Execution. Wer den Score selbst nachvollziehen möchte, kann den Vektor im offiziellen CVSS-Rechner von FIRST.org Schritt für Schritt zusammensetzen.
Der feine Unterschied zwischen 9.8 und 10.0
An dieser Stelle sitzt der häufigste Irrtum. Sehr viele als kritisch eingestufte RCE-Lücken tragen eine 9.8, nicht eine 10.0, obwohl sie in jeder Hinsicht verheerend sind. Der einzige Unterschied liegt in einer einzigen Metrik, nämlich dem Scope.
Bei S:U (Scope Unchanged) bleibt der Schaden in derselben Sicherheitsdomäne wie die verwundbare Komponente. Eine Anwendung wird vollständig kompromittiert, aber der Schaden endet an ihrer eigenen Grenze. Genau dieser Fall ergibt mit ansonsten maximalen Werten eine 9.8. Bei S:C (Scope Changed) springt die Wirkung über die Grenze der verwundbaren Komponente hinaus, etwa wenn ein gekaperter Dienst das gesamte Host-System, den Hypervisor oder benachbarte Container übernimmt. Erst dieser Übergriff hebt die ansonsten identische Lücke von 9.8 auf 10.0.
Wer in einem Bericht also eine echte 10.0 liest, weiß ohne weiteren Kontext bereits eine Sache sicher: Die Lücke bricht aus ihrem eigenen Zuständigkeitsbereich aus und reißt andere Systeme mit.
Log4Shell als Lehrbuchbeispiel
Die bekannteste echte 10.0 der jüngeren Geschichte ist Log4Shell (CVE-2021-44228). Das NVD vergab exakt den oben gezeigten Vektor. Eine scheinbar harmlose Logging-Bibliothek führte über einen JNDI-Lookup beliebigen Code aus, sobald sie einen vom Angreifer kontrollierten String protokollierte. Betroffen war nicht nur die Log-Komponente selbst, sondern der gesamte Java-Prozess und über ihn die dahinterliegende Infrastruktur. Genau dieser Übergriff auf fremde Komponenten begründet das S:C und damit die volle Höchstwertung. Die Kombination aus trivialer Auslösung über eine einzige Zeichenkette, fehlender Authentifizierung und vollständiger Systemübernahme machte Log4Shell zum Paradebeispiel dafür, wie eine 10.0 zustande kommt.
Gegenprobe: warum unsere Argo-CD-Lücke nur eine 7.3 war
Greifbar wird der Score erst im direkten Vergleich. Die von unserem Analysten gefundene Stored XSS in Argo CD (CVE-2026-45738) trägt den Vektor CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N und damit eine 7.3. Stellt man die beiden Vektoren nebeneinander, sieht man Metrik für Metrik, was zu einer 10.0 fehlt.
| Metrik | Argo CD (7.3) | Perfekte 10.0 |
|---|---|---|
| Attack Vector | Network | Network |
| Attack Complexity | Low | Low |
| Privileges Required | Low (Schreibrechte auf eine Application) | None |
| User Interaction | Required (Admin muss den Link klicken) | None |
| Scope | Unchanged (bleibt in der Anwendung) | Changed |
| Confidentiality | High | High |
| Integrity | High | High |
| Availability | None (Verfügbarkeit unberührt) | High |
Vier Metriken trennen die beiden Befunde. Die XSS braucht einen niedrig privilegierten Account mit Schreibrechten, sie braucht einen Klick des Opfers, sie bleibt im Vertrauenskontext der Anwendung und sie kostet keine Verfügbarkeit. Jede einzelne dieser vier Eigenschaften drückt den Score nach unten. Eine 10.0 verlangt, dass keine davon zutrifft. Das macht zugleich deutlich, warum die 7.3 hier konservativ ist: Im GitOps-Kontext eskaliert ein Application-Owner über den Admin-Klick faktisch zu vollem Cluster-Zugriff, was der Base Score allein nicht abbildet. Genau dafür gibt es die zeitlichen und umgebungsbezogenen Metriken.
Wie CVSS 4.0 die perfekte 10 neu zeichnet
Mit CVSS 4.0 hat FIRST das Scoring umgebaut, und die vertraute Scope-Metrik ist dabei verschwunden. An ihre Stelle treten getrennte Impact-Metriken für das verwundbare System (VC, VI, VA) und für nachgelagerte Systeme (SC, SI, SA). Eine 10.0 verlangt in 4.0 den Vektor CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, also alle Angriffsmetriken auf dem leichtesten Wert und sämtliche sechs Impact-Dimensionen auf High.
Der Grundgedanke bleibt erhalten: Eine perfekte 10 kompromittiert sowohl das direkt verwundbare System als auch alles, was dahinter liegt. Neu hinzugekommen ist die Attack-Requirements-Metrik (AT), die für die Höchstwertung auf None stehen muss, und die feinere Trennung der Auswirkungen. Die Logik des Scope-Sprungs steckt jetzt also in den Subsequent-System-Metriken. Auch hier hilft der CVSS-4.0-Rechner von FIRST.org, die Wertung selbst nachzuvollziehen.
Warum eine 10.0 nicht das Ende der Bewertung ist
So eindeutig die Zahl wirkt, sie misst den Schweregrad einer Schwachstelle und nicht das konkrete Risiko in Ihrer Umgebung. Eine 10.0 ohne öffentlich verfügbaren Exploit in einem streng segmentierten internen Netz kann betrieblich weniger dringend sein als eine 8.1 an der Internetkante, für die längst ein fertiges Exploit-Kit kursiert. Der CVSS-3.1-Standard hält ausdrücklich fest, dass der Base Score durch zeitliche und umgebungsbezogene Metriken ergänzt werden sollte, bevor daraus eine Priorisierung wird. Die 10.0 ist damit ein wichtiges Signal, aber der Anfang einer Risikobetrachtung und nicht ihr Ergebnis.
Fazit
Eine 10.0 ist kein Superlativ für besonders schlimm, sondern ein exakt definierter Zustand: aus der Ferne erreichbar, ohne Hürde, ohne Mithilfe eines Opfers und mit totalem Schaden, der über die eigene Komponente hinausgreift. Der schmale Grat zwischen 9.8 und 10.0 entscheidet sich in CVSS 3.1 allein am Scope, in CVSS 4.0 an den Auswirkungen auf nachgelagerte Systeme. Unsere eigene Argo-CD-Lücke zeigt im Umkehrschluss, wie schnell vier kleine Einschränkungen einen Befund von der Höchstwertung wegführen. Wer Scores im eigenen Bericht richtig lesen will, achtet deshalb nicht auf die nackte Zahl, sondern auf den Vektor dahinter. Dort steht, was die Lücke wirklich kann.