Manchmal ist der unangenehmste Sicherheitsbericht der, der gar keine neue Lücke enthält. Die US-Behörde CISA hat die Jahre 2024 und 2025 ausgewertet — und kommt zu einem Ergebnis, das man kaum schönreden kann: Der größte Teil der tatsächlich ausgenutzten Schwachstellen gehört zu Fehlerklassen, die seit Jahrzehnten bekannt sind.
DIE BEFUNDE
Ganz vorne liegen Einschleusungslücken: Cross-Site-Scripting (CWE-79), OS-Command-Injection (CWE-78) und SQL-Injection (CWE-89). Dazu kommt die mit Abstand häufigste Einzelschwäche über beide Listen hinweg — unzureichende Prüfung von Eingaben (CWE-20).
Die harte Zahl: Sieben der zehn häufigsten Fehlerklassen im Katalog der aktiv ausgenutzten Lücken (KEV) gehören zu dem, was MITRE 2023 als „stubborn weaknesses“ bezeichnet hat — hartnäckige Schwächen. Zusammen machen sie 41,5 Prozent aller Einträge dieser Liste aus. Bei den drei häufigsten KEV-Einträgen handelt es sich um unzureichende Eingabeprüfung, Pfad-Traversierung (CWE-22) und Command-Injection.
2025 sah es nicht besser aus: Sieben der zehn häufigsten Fehlerklassen fielen weiter in die Kategorie, die MITRE bereits 2007 als „unforgivable vulnerabilities“ beschrieben hat — unverzeihliche Lücken.
WAS „UNVERZEIHLICH“ HIER BEDEUTET
Der Begriff stammt aus einem MITRE-Papier von 2007 und ist erstaunlich präzise definiert. Unverzeihlich ist eine Lücke, wenn sie auf einem verbreiteten, gut dokumentierten Fehler beruht, der Angriffsweg offensichtlich ist, der Exploit einfach ausfällt und ein Angreifer die Stelle in Minuten findet.
Neunzehn Jahre später prägen genau diese Muster noch immer die Statistik.
DER SATZ, DER SITZT
CISAs eigene Einordnung verzichtet auf Diplomatie: „Threat actors continue to succeed, in part, because simple, preventable software weaknesses remain unaddressed.“ Angreifer haben also auch deshalb Erfolg, weil einfache, vermeidbare Schwächen ungelöst bleiben. Und weiter: „Resolving fundamental issues would eliminate a significant portion of today’s most common compromises.“
Besonders bemerkenswert ist die Ursachenzuweisung. Die Behörde schreibt: „Their persistence today illustrates that the problem is not technical complexity: it is organizational culture, developer workflows, and systemic gaps in Secure by Design adoption.“ Also nicht zu schwierig — sondern zu unbequem.
AUCH DIE PRAXISTESTS ZEIGEN DASSELBE
CISA führt kostenlose Penetrationstests bei echten Organisationen durch, die sogenannten Risk and Vulnerability Assessments. Auch dort waren Speichersicherheit und mangelhafte Eingabeprüfung die verlässlichsten Wege zur Kompromittierung — sie stehen 2025 hinter 16,7 Prozent der KEV-Einträge.
Interessant ist der Unterschied zwischen Papier und Praxis: Injection-Lücken tauchen zwar sehr häufig in gemeldeten CVEs auf, werden in der realen Welt aber seltener erfolgreich ausgenutzt — vor allem gegen Organisationen, die ihre Sicherheit im Griff haben.
WAS DAS FÜR DEINE ENTSCHEIDUNGEN HEISST
CISAs Forderung richtet sich zuerst an Hersteller: Software von vornherein sicher bauen, statt immer größere Patch-Pakete nachzuschieben. Nach dem Motto — es hilft niemandem, wenn ein Patchday im Monat 600 Lücken stopft, die es nie hätte geben müssen.
Für dich als Käufer und Betreiber sind zwei Punkte übertragbar:
- Anbieter auswählen, nicht nur Funktionen. Wie schnell reagiert das Projekt auf Meldungen? Gibt es überhaupt einen Sicherheitskontakt? Bei Self-Hosted-Software ist das leicht nachprüfbar — ein Blick in die Issue-Historie sagt oft mehr als jede Werbeseite.
- Wissen, was drinsteckt. CISA empfiehlt ausdrücklich Software-Stücklisten (SBOMs), um Lieferkettenrisiken nachverfolgen zu können. Im Homelab reicht oft schon eine ehrliche Liste: Welche Container laufen bei mir, in welcher Version, und wer pflegt sie eigentlich?
FAZIT
Kein Alarm, keine Frist, kein Patch. Dafür eine unbequeme Bestandsaufnahme: Der größte Teil dessen, was gerade erfolgreich ausgenutzt wird, ist altbekannt. „Organizations must shift from reacting to threat actors to fixing the fundamental flaws those actors are known to exploit“, schreibt CISA. Das gilt für Hersteller — und im Kleinen auch für jeden, der einen Server betreibt.