CVE steht für Common Vulnerabilities and Exposures und ist der weltweite Referenzkatalog für öffentlich bekannte Sicherheitslücken. Das Programm wird seit 1999 von der MITRE Corporation betrieben und von der US-Cybersicherheitsbehörde CISA finanziert. Jede Schwachstelle erhält eine eindeutige Kennung im Format CVE-JAHR-NUMMER, etwa CVE-2021-44228 für Log4Shell, damit Hersteller, Scanner, Forscher und Nachrichtenartikel alle dieselbe Lücke meinen. Vergeben werden die IDs von mehreren hundert CVE Numbering Authorities (CNAs) weltweit. Der Schweregrad eines CVE wird mit dem Common Vulnerability Scoring System (CVSS) bewertet, einer von FIRST gepflegten Skala von 0,0 bis 10,0: Ab 9,0 lautet die Einstufung Critical, 7,0 bis 8,9 ist High, 4,0 bis 6,9 Medium und darunter Low. Die Größenordnung des Systems ist dramatisch gewachsen: Allein 2024 wurden mehr als 40.000 neue CVEs veröffentlicht, und im WordPress-Ökosystem wurden 2024 knapp 8.000 Schwachstellen offengelegt, davon rund 96 Prozent in Plugins.
Wofür steht CVE?
Bevor es CVE gab, beschrieb jeder Sicherheitsanbieter Schwachstellen in eigenen Worten, und niemand konnte sagen, ob der Buffer Overflow im einen Advisory derselbe Bug war wie der Remote-Exploit im anderen. Das Programm Common Vulnerabilities and Exposures, 1999 von MITRE gestartet, löste das mit etwas täuschend Einfachem: einem eindeutigen Namen pro Lücke. Ein CVE-Datensatz enthält diese ID, eine kurze Beschreibung, Verweise auf Advisories und Patches sowie die betroffenen Produkte.
Das ID-Format lautet CVE-JAHR-NUMMER, wobei das Jahr das Jahr der Vergabe ist, nicht zwingend das der Entdeckung, und die Nummer vier oder mehr Stellen hat. Die offizielle Datenbank liegt unter cve.org. Darauf setzt die National Vulnerability Database (NVD) des US-Normungsinstituts NIST auf, die CVE-Datensätze um Schweregrad-Bewertungen, betroffene Versionsbereiche und Schwachstellenklassifizierungen anreichert. Wenn Ihr Sicherheitsscanner Schweregrad-Daten zu einem CVE anzeigt, stammen sie in der Regel aus der NVD.
Wie bekommt eine Schwachstelle eine CVE-ID?
CVE-IDs werden von CVE Numbering Authorities vergeben, kurz CNAs. Das sind Softwarehersteller, Sicherheitsfirmen und Forschungsorganisationen, die autorisiert sind, IDs für ihre eigenen Produkte oder ihren Zuständigkeitsbereich zu vergeben. Das Netzwerk ist auf mehrere hundert CNAs in Dutzenden Ländern gewachsen. Deshalb meldet ein Forscher, der eine Lücke etwa in einem Cisco-Produkt findet, diese direkt an Cisco, und Cisco vergibt das CVE selbst.
Der typische Ablauf sieht so aus: Ein Forscher entdeckt eine Schwachstelle und meldet sie der zuständigen CNA, die CNA reserviert eine CVE-ID, während der Fix entwickelt wird, und sobald ein Patch erscheint, wird der Datensatz zusammen mit dem Advisory veröffentlicht. Diese Reservierungsphase erklärt, warum Sie gelegentlich eine CVE-ID öffentlich erwähnt sehen, zu der es noch keinerlei Details gibt.
Für WordPress-Nutzer ist ein Detail wissenswert: Wordfence, WPScan und Patchstack sind allesamt CNAs. Die große Mehrheit der CVEs zu WordPress-Plugins und -Themes wird von einer dieser drei vergeben, weshalb ihre Schwachstellendatenbanken auch die vollständigsten Quellen für das WordPress-Ökosystem sind.
Was ist der CVSS-Score?
Ein Name allein sagt Ihnen nicht, wie schlimm eine Lücke ist. Das ist die Aufgabe des Common Vulnerability Scoring System, eines offenen Standards, der von FIRST gepflegt wird, dem weltweiten Verbund der Incident-Response-Teams. CVSS verdichtet die technischen Merkmale einer Schwachstelle zu einem Wert zwischen 0,0 und 10,0. Version 2 erschien 2007, Version 3.0 im Jahr 2015, die Verfeinerung 3.1 im Jahr 2019 und Version 4.0 im November 2023. In der Praxis sprechen die meisten Datenbanken und Advisories nach wie vor CVSS 3.1, die Verbreitung von 4.0 wächst nur langsam.
CVSS-Schweregrade von None bis Critical
| Einstufung | CVSS-Score | Typische Bedeutung |
|---|---|---|
| None | 0,0 | Keine Auswirkung |
| Low | 0,1 bis 3,9 | Schwer auszunutzen oder sehr begrenzte Auswirkung |
| Medium | 4,0 bis 6,9 | Echte Auswirkung, aber mit Voraussetzungen wie Nutzerinteraktion oder vorhandenen Rechten |
| High | 7,0 bis 8,9 | Schwerwiegende Auswirkung, oft Datenabfluss oder Rechteausweitung |
| Critical | 9,0 bis 10,0 | Typischerweise unauthentifizierte Ausnutzung aus der Ferne mit vollständiger Kompromittierung |
Die berüchtigte 9,8, die Sie auf so vielen Advisories sehen, ist der Signaturwert einer unauthentifizierten Remote Code Execution: über das Netzwerk erreichbar, keine Rechte, keine Nutzerinteraktion nötig. Eine glatte 10,0 bricht zusätzlich aus der verwundbaren Komponente in andere Systeme aus, genau das gelang Log4Shell.
Wie wird ein CVSS-Score berechnet?
Der Base Score ergibt sich aus einer Handvoll Metriken, die beschreiben, wie eine Lücke erreichbar ist und was sie kaputt macht. Auf der Seite der Ausnutzbarkeit: Attack Vector (Netzwerk, benachbart, lokal, physisch), Attack Complexity, Privileges Required und User Interaction. Auf der Auswirkungsseite: der Effekt auf Confidentiality, Integrity und Availability, dazu in Version 3.1 die Metrik Scope, die erfasst, ob der Schaden auf andere Komponenten übergreift. Die einzelnen Einstufungen werden in einer kompakten Vektor-Zeichenkette festgehalten, die Sie auf jedem NVD-Eintrag finden:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:N über das Netzwerk erreichbar
AC:L geringe Angriffskomplexität
PR:N keine Rechte erforderlich
UI:N keine Nutzerinteraktion nötig
S:U Scope unverändert
C:H/I:H/A:H hohe Auswirkung auf Vertraulichkeit, Integrität, Verfügbarkeit
Ergebnis: Base Score 9,8, CriticalDas Schöne am Vektor ist, dass er Ihnen mehr verrät als die Zahl. Eine 7,5 mit PR:N und eine 7,5 mit PR:H sind für Ihr Bedrohungsmodell völlig verschiedene Tiere, und den Vektor zu lesen dauert zehn Sekunden, sobald Sie die Kürzel kennen.
Was ist neu in CVSS 4.0?
Version 4.0 greift die größten Kritikpunkte an 3.1 auf. Die verwirrende Metrik Scope ist verschwunden und wurde durch getrennte Auswirkungsbewertungen für das verwundbare System und für nachgelagerte Systeme ersetzt. User Interaction ist mit den Varianten passiv und aktiv feiner abgestuft, und eine neue Metrik Attack Requirements erfasst Bedingungen, die auf dem Ziel gegeben sein müssen. Die alten temporalen Metriken wurden zu Bedrohungsmetriken umgebaut, und der Standard benennt seine Score-Varianten nun ausdrücklich: CVSS-B für den reinen Base Score, CVSS-BT mit Bedrohungsdaten und CVSS-BE mit Umgebungskontext. Konzeptionell ist das durchweg eine Verbesserung. Praktisch bewegt sich das Ökosystem langsam, Sie werden also noch jahrelang 3.1-Vektoren lesen.
Warum ein hoher CVSS-Score nicht automatisch Ihr größtes Risiko ist
Die unbequeme Wahrheit über CVSS lautet: Es misst den Schweregrad, nicht die Wahrscheinlichkeit. Die überwältigende Mehrheit der veröffentlichten CVEs wird nie in freier Wildbahn ausgenutzt, während einzelne mittelschwer bewertete Lücken innerhalb von Stunden massiv angegriffen werden, weil ein Exploit öffentlich ist und das Ziel überall steht. Zwei Datenquellen schließen diese Lücke. Der EPSS-Score, ebenfalls von FIRST, schätzt anhand realer Telemetriedaten die Wahrscheinlichkeit, dass eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird. Und der CISA-KEV-Katalog listet Schwachstellen mit bestätigter Ausnutzung, das stärkste verfügbare Signal.
Eine praxistaugliche Priorisierungsregel für Website-Betreiber: Patchen Sie zuerst, was in KEV steht oder einen hohen EPSS-Score hat und in einer zum Internet hin offenen Komponente sitzt. Eine 9,8 in einem Plugin, das Sie letztes Jahr deaktiviert haben, wiegt weniger als eine 7,5 im Kontaktformular-Plugin, das jeder Besucher erreicht. Schweregrad ist Kontext, und Ihren Kontext kennen nur Sie.
CVEs im WordPress-Ökosystem
Der WordPress-Kern selbst ist inzwischen ein hartes Ziel und macht deutlich unter einem Prozent der offengelegten Schwachstellen aus. Die Musik spielt im Erweiterungs-Ökosystem: Laut Patchstack wurden 2024 knapp 8.000 neue Schwachstellen im WordPress-Ökosystem offengelegt, rund 96 Prozent davon in Plugins und der größte Teil des Rests in Themes. Die häufigsten Kategorien sind Cross-Site Scripting, Cross-Site Request Forgery und fehlerhafte Zugriffskontrolle. Nichts davon bedeutet, dass WordPress unsicher wäre. Es bedeutet, dass sich die Sicherheit Ihrer Website daran entscheidet, welche Plugins Sie installieren und wie schnell Sie aktualisieren. Ein Plugin mit 100.000 Installationen und einer bekannten, ungepatchten Lücke ist innerhalb von Tagen, manchmal Stunden, Ziel von Massenscans.
Berühmte CVE-Beispiele
- CVE-2014-0160, Heartbleed: Speicherabfluss in OpenSSL, über den Angreifer private Schlüssel von Servern auslesen konnten. Der Bug, der Schwachstellen Logos und Namen bescherte.
- CVE-2017-0144, EternalBlue: die SMB-Lücke hinter der WannaCry-Ransomware-Welle von 2017.
- CVE-2021-44228, Log4Shell: eine CVSS 10,0 in der Java-Logging-Bibliothek Log4j. Eine präparierte Zeichenkette in einem beliebigen protokollierten Feld führte zu Remote Code Execution, und das halbe Internet protokollierte Nutzereingaben.
- CVE-2023-4966, Citrix Bleed: Abfluss von Session-Tokens in Citrix NetScaler, von Ransomware-Gruppen gegen Tausende Appliances ausgenutzt.
Wie nutzt InspectWP CVE-Daten?
InspectWP erkennt die Plugins und Themes einer analysierten WordPress-Website und gleicht sie mit bekannten Schwachstellendaten ab. Ein Bericht kann Ihnen damit sagen, dass eine bestimmte installierte Komponente ein veröffentlichtes CVE hat, wie schwerwiegend es ist und dass ein Update bereitsteht. Das schließt die ärgerliche Lücke zwischen einem CVE, das irgendwo in einer Datenbank existiert, und Ihrer Erkenntnis, dass es eine Ihrer Websites betrifft. Zusammen mit geplanten automatischen Berichten bekommen Sie damit die praxistaugliche Variante von Schwachstellenmanagement für WordPress: wissen, was Sie betreiben, wissen, was kaputt ist, und zuerst das aktualisieren, worauf es ankommt.