Was ist ein CVE? Sicherheitslücken einfach erklärt für Nicht-Techniker
CVE, Patch, Exploit: Diese Begriffe tauchen auf, wenn Sicherheitsmeldungen erscheinen. Was ist ein CVE genau, was bedeutet ein Patch und was ist ein Exploit? Viele Entscheider ohne technischen Hintergrund wissen es nicht genau. Das ist kein Vorwurf, sondern ein verbreitetes Muster. Diese Begriffe kommen aus der Welt der Entwickler und Sicherheitsforscher.
Das Problem: Die Konzepte dahinter sind auch für ältere PHP- und Java-Anwendungen hochrelevant. Gerade für Systeme, die seit Jahren laufen, ohne dass jemand gezielt hinschaut.
Dieser Artikel erklärt, was ein CVE ist, wie Patches und Exploits damit zusammenhängen und warum das für Ihr Unternehmen konkret bedeutsam ist.
CVE, Patch, Exploit: Was hinter den Begriffen steckt
Fangen wir mit den Grundbegriffen an. Jeder der drei Begriffe beschreibt einen anderen Teil desselben Vorgangs: eine Sicherheitslücke wird entdeckt, dokumentiert, behoben oder ausgenutzt.
CVE: Eine Adresse für jede bekannte Sicherheitslücke
CVE steht für "Common Vulnerabilities and Exposures". Das ist eine öffentliche Datenbank, in der bekannte Sicherheitslücken in Software erfasst werden. Betrieben wird sie von der US-amerikanischen Non-Profit-Organisation MITRE, gefördert von der amerikanischen Behörde CISA.
Jede erfasste Lücke bekommt eine eindeutige Nummer, zum Beispiel CVE-2023-44487. Diese Nummer ist die Adresse der Lücke. Mit ihr kann jeder nachschlagen: Was ist das Problem? Welche Softwareversionen sind betroffen? Wie schwerwiegend ist die Lücke?
Schweregrade werden nach dem CVSS-System bewertet (Common Vulnerability Scoring System). Ein Score von 9 oder 10 bedeutet: kritisch. Ein Score unter 4 bedeutet: geringes Risiko. Viele bekannte Lücken in alten PHP-Versionen liegen im hohen Bereich.
Die Datenbank ist für alle zugänglich. Das hat einen guten Grund: Transparenz hilft der Sicherheits-Community, schnell zu reagieren und Patches bereitzustellen. Aber es bedeutet auch: Angreifer können dieselbe Datenbank nutzen.
Security Patch: Die Antwort der Softwareentwickler
Ein Security Patch ist ein Update, das eine bekannte Sicherheitslücke schließt. Wenn eine CVE veröffentlicht wird, stellen die Entwickler der betroffenen Software in der Regel zeitnah einen Patch bereit. Wer seine Software aktuell hält, erhält diesen Patch. Die Lücke ist dann für ihn geschlossen.
Das Problem entsteht, wenn eine Software keinen Support mehr hat. PHP 7 ist seit Ende 2022 End of Life. Das bedeutet: Keine Patches mehr. Neue CVEs für PHP 7 werden weiterhin in der Datenbank erfasst, aber niemand schließt die Lücken. Sie bleiben offen, so lange das System läuft.
Dasselbe gilt für andere veraltete Komponenten: MySQL 5.7, alte jQuery-Versionen, Joomla 3, veraltete Java-Bibliotheken. Jede Komponente ohne aktiven Support akkumuliert ungepatchte CVEs.
Exploit: Das Werkzeug der Angreifer
Ein Exploit ist ein Programm oder eine Technik, die eine bekannte Schwachstelle gezielt ausnutzt. Wenn eine CVE veröffentlicht wird, dauert es oft nur wenige Tage oder Wochen, bis fertige Exploits im Internet verfügbar sind.
Angreifer müssen diese Werkzeuge nicht selbst entwickeln. Sie laden sie herunter und setzen sie automatisiert ein. Scanner durchsuchen das Internet systematisch nach Systemen, auf denen verwundbare Softwareversionen laufen.
Das bedeutet konkret: Wer Software betreibt, für die keine Patches mehr erscheinen, sitzt auf einer wachsenden Sammlung offener CVEs. Und für viele davon existieren bereits fertige Exploits.
Warum CVEs für alte Software besonders problematisch sind
Viele Unternehmen denken: "Unser System ist zu klein, um interessant zu sein." Das ist ein verbreiteter Irrtum. Angreifer suchen selten gezielt nach einem bestimmten Unternehmen. Sie scannen automatisiert das gesamte Internet nach bekannten Schwachstellen.
Eine offene CVE in einer alten PHP-Version ist ein bekanntes und gut dokumentiertes Angriffsziel. Nicht weil jemand Ihr Unternehmen kennt, sondern weil Ihr System auf einer Lücke sitzt, für die ein fertiger Exploit existiert.
Hinzu kommt: Die Anzahl offener CVEs wächst mit jedem Jahr ohne Sicherheits-Updates. Für PHP 5 und PHP 7 akkumulieren sich diese Einträge seit Jahren. Für aktuelle PHP-Versionen werden Lücken geschlossen. Für veraltete Versionen nicht. Das Sicherheitsgefälle zwischen gepflegter und ungepflegter Software wird mit der Zeit größer, nicht kleiner.
Dasselbe gilt für Legacy Software generell: Java-EE-Anwendungen aus den 2000er Jahren haben oft Abhängigkeiten mit langen CVE-Listen. Ungepflegte WordPress-Installationen sammeln Schwachstellen durch veraltete Plugins. Jede Software ohne regelmäßige Updates sammelt Risiken an.
Ein realistisches Szenario
Stellen Sie sich vor: Ihre Webanwendung läuft auf PHP 7.4. Ein Sicherheitsforscher entdeckt eine kritische Lücke in einer Bibliothek, die Ihre Anwendung verwendet. Er meldet die Lücke verantwortungsvoll. Wenige Tage später erscheint der CVE-Eintrag in der Datenbank, Schweregrad: 9.1 von 10.
Für PHP 8 wird ein Patch veröffentlicht. Für PHP 7 nicht.
Drei Wochen später ist ein Exploit für diese Lücke öffentlich verfügbar. Automatisierte Scanner durchsuchen das Web nach verwundbaren Systemen. Ihr System taucht auf.
Das ist kein konstruiertes Horrorszenario. Es ist ein beschriebener und gut dokumentierter Ablauf, der sich täglich ereignet. Die meisten Angriffe auf Webanwendungen sind keine gezielten Attacken, sondern opportunistisches Ausnutzen bekannter Lücken.
Was Sie konkret tun können
Die gute Nachricht: Sie müssen kein Entwickler sein, um die richtigen Schritte einzuleiten. Drei Maßnahmen sind grundlegend.
Softwareversionen kennen. Welche PHP-Version läuft Ihre Anwendung? Auf welchen Versionen basieren die eingesetzten Bibliotheken und Plugins? Wenn Sie das nicht wissen, ist das der erste Schritt: herausfinden. Ein Entwickler oder Hostinganbieter kann das in wenigen Minuten klären.
CVE-Exposition einschätzen lassen. Ein erfahrener Dienstleister kann prüfen, wie viele offene CVEs für Ihre Softwareversionen bekannt sind. Das gibt Ihnen ein reales Bild des Risikos, nicht eine vage Warnung. Dieser Schritt kostet wenig und gibt Ihnen Klarheit.
Upgrade planen, wenn nötig. Wenn Ihre Anwendung auf veralteten Versionen ohne aktiven Support läuft, ist ein Upgrade die einzige dauerhafte Lösung. Das kostet etwas. Nichts zu tun kostet erfahrungsgemäß mehr, nur zu einem unkontrollierteren Zeitpunkt.
Ein Security-Audit für Ihre Software-Wartung hilft Ihnen, den genauen Stand zu verstehen. Ohne zu wissen, womit man es zu tun hat, ist jede Maßnahme ein Schuss ins Blaue.
Was CVEs mit der DSGVO zu tun haben
Dieser Zusammenhang wird oft übersehen. Die Datenschutz-Grundverordnung verpflichtet Unternehmen dazu, personenbezogene Daten technisch angemessen zu schützen. "Angemessen" bedeutet: Stand der Technik.
Software mit bekannten, ungepatchten CVEs ist nicht Stand der Technik. Eine Datenschutzbehörde, die nach einem Vorfall prüft, wird fragen, warum das System auf einer Softwareversion ohne Sicherheits-Updates lief. Eine überzeugende Antwort gibt es darauf nicht.
Das ist kein theoretisches Risiko. Mehrere Bußgeldverfahren in Deutschland und Europa haben genau diesen Sachverhalt als Grundlage gehabt: veraltete Softwarekomponenten, bekannte Lücken, kein Patch.
Fazit: CVEs sind kein abstraktes Konzept
Was ist ein CVE in der Praxis? Eine öffentliche Dokumentation bekannter Schwachstellen in Software. Das Gefährliche daran ist nicht die Dokumentation selbst, sondern die Kombination: bekannte Lücke, kein Patch, fertiger Exploit.
Alte Software sammelt CVEs an. Gepflegte Software bekommt Patches. Der Unterschied zwischen beiden ist der Unterschied zwischen geschlossenen und offenen Lücken. Dieser Unterschied wächst mit jedem Monat ohne Update.
Wer seinen Software-Stand kennt, kann gezielt handeln. Wer nicht weiß, auf welchen Versionen seine Anwendung läuft, hat bereits ein Problem, auch wenn es noch nicht sichtbar ist.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihren Stand an und sagen Ihnen ehrlich, womit Sie es zu tun haben.