Die Frage, die du dir als Betreiber eines Linux-Systems eigentlich stellen willst, ist klein und konkret: Läuft meine Maschine auf einer Kernel-Version, die noch Sicherheitsfixes bekommt, und wie finde ich das heraus? Ende Oktober 2026 zeigt eine Grafik aus dem öffentlichen Repository des Kernel-Maintainers Greg Kroah-Hartman, wie viele CVEs pro Kernel-Version behoben wurden. Die Kurve springt in den jüngsten Releases deutlich nach oben. Dieser Artikel sortiert, was diese Zahlen tatsächlich aussagen, warum du sie nicht eins zu eins als „mehr Gefahr" lesen solltest, und führt dich Schritt für Schritt durch die Prüfung deines eigenen Systems.
Kurzantwort#
Warum die Zahl behobener CVEs pro Kernel-Version steigt – und wie du in wenigen Minuten prüfst, ob dein Kernel noch Sicherheitsupdates bekommt.
Was die Grafik zeigt: die nackten Zahlen#
Die Daten stammen aus dem Repository „kernel-development", das Greg Kroah-Hartman, der Betreuer der stabilen Kernel-Serien, öffentlich pflegt. Dort liegt im Ordner graphs/patches_per_release die Grafik cves_fixed_per_release.png samt der Ruby-Datei, die die Werte pro Release setzt. Erfasst ist für jede Kernel-Version die Zahl der behobenen Fixes, denen eine CVE-Nummer zugeordnet wurde 1
.
In der 6.x-Serie bewegen sich die Werte über viele Versionen hinweg in einem engen Band: zwischen 425 (6.14) und 620 (6.12), im Schnitt gut 500 pro Version. Die Zahlen der einzelnen Releases lauten 538 (6.9), 525 (6.10), 484 (6.11), 620 (6.12), 549 (6.13), 425 (6.14), 506 (6.15), 475 (6.16), 484 (6.17), 490 (6.18) und 545 (6.19) 1 .
Ab der 7.0-Serie ändert sich das Bild sprunghaft: 1.247 CVEs in 7.0, 1.306 in 7.1, 2.299 in 7.2 und 2.755 in 7.3 1 . 7.3 ist am 18. Oktober 2026 als Mainline-Release erschienen; die Grafik wurde zuletzt am 26. Oktober 2026 aktualisiert, weitere CVE-Zuweisungen für bereits enthaltene Fixes können die Zahl also noch leicht erhöhen 1 , 3 . Gegenüber dem 6.x-Schnitt von rund 513 entspricht das etwa dem 2,4-Fachen (7.0), 2,5-Fachen (7.1), 4,5-Fachen (7.2) und 5,4-Fachen (7.3).
Das ist ein realer, überprüfbarer Anstieg in den Daten. Was er bedeutet, ist eine andere Frage – und genau hier lohnt es sich, einen Schritt zurückzutreten.
Mainline, Stable, Longterm: warum es mehrere Versionen gleichzeitig gibt#
Bevor du die Zahlen einordnest, hilft ein Blick auf die Pflegewege des Kernels, denn sie erklären, warum dieselbe Lücke in vielen verschiedenen Versionsnummern auftauchen kann. Die Release-Seite von kernel.org unterscheidet drei Kategorien 3 .
Prepatch (RC). Vor jedem fertigen Release erscheinen mehrere Release Candidates, die vor allem an Entwickler gerichtet sind. Sie müssen aus dem Quellcode gebaut werden und enthalten neue Funktionen, die getestet werden sollen, bevor sie in ein Stable-Release übernommen werden 3 .
Mainline. Der Baum von Linus Torvalds, in den alle neuen Funktionen fließen. Ein neues Mainline-Release erscheint ungefähr alle neun bis zehn Wochen 3 .
Stable. Nach jedem Mainline-Release gilt die Version als „stable". Fehlerkorrekturen werden aus Mainline zurückportiert und von einem fest zugeordneten Maintainer eingespielt. Es folgen meist nur wenige Bugfix-Releases, bis die nächste Mainline erscheint – es sei denn, die Serie wird zum Longterm-Kernel erklärt. Stable-Updates kommen nach Bedarf, üblicherweise einmal pro Woche 3 .
Longterm. Mehrere ältere Serien werden über Jahre gepflegt, indem nur noch wichtige Fehlerkorrekturen zurückportiert werden 3 . Zum Zeitpunkt dieser Recherche sind das 6.18, 6.12, 6.6, 6.1, 5.15 und 5.10 3 .
Diese Parallelität ist für dein Sicherheitsverständnis zentral: Ein Sicherheitsfix, der für eine neue Serie geschrieben wurde, wird auf alle noch gepflegten älteren Serien zurückportiert 4 . Derselbe Fix taucht deshalb in den Statistiken mehrfach auf – einmal pro Serie, in der er landet. Und weil die „Projected EOL"-Daten nicht in Stein gemeißelt sind, sondern bei genügend Industrieinteresse verlängert werden können, verschiebt sich auch das Ende einer Serie 3 .
Was ein „behobener CVE" im Kernel überhaupt ist#
Um die Zahlen einzuordnen, musst du verstehen, wie im Linux-Kernel CVEs vergeben werden. CVE steht für „Common Vulnerabilities and Exposures" und ist ein eindeutiges Kürzel für eine öffentlich dokumentierte Sicherheitslücke. Die Vorgeschichte ist dabei ebenso wichtig wie die aktuelle Regel: Über die Jahre nahm der Nutzen von CVE-Nummern aus Sicht des Kernel-Projekts ab, weil sie häufig unpassend oder aus unpassenden Gründen vergeben wurden; die Kernel-Gemeinschaft neigte deshalb lange dazu, sie zu meiden. Der anhaltende Druck, CVEs zu vergeben, und Missbrauch durch Akteure außerhalb der Kernel-Gemeinschaft führten schließlich dazu, dass das Kernel-Team die Vergabe selbst übernimmt – unabhängig vom normalen Meldeweg für Sicherheitslücken 2 .
Dabei gilt eine bewusst defensive Regel: Als Teil des regulären Stable-Prozesses werden Kernel-Änderungen, die potenziell ein Sicherheitsproblem sind, von den dafür zuständigen Entwicklern identifiziert und bekommen automatisch eine CVE-Nummer zugewiesen 2 . Die Kernel-Dokumentation formuliert es ausdrücklich: Da beim Kernel fast jeder Bug potenziell ausnutzbar sein kann, sei das CVE-Team „overly cautious" – übervorsichtig – und vergebe CVEs für praktisch jeden Fix, den es als sicherheitsrelevant einstuft. Genau das, so die Dokumentation, erkläre die scheinbar große Zahl vergebener CVEs 2 .
Zwei weitere Regeln sind wichtig, um die Zahlen richtig zu lesen. Erstens wird eine CVE erst dann automatisch vergeben, wenn ein Fix bereits vorliegt und in einen Stable-Tree aufgenommen wurde; die Zuordnung erfolgt über die Commit-ID des ursprünglichen Fixes 2 . Zweitens werden für ungepatchte Schwachstellen und für Kernel-Versionen, die nicht mehr aktiv gepflegt werden, keine CVEs vergeben 2 . Eine CVE im Linux-Kernel dokumentiert also nicht „eine offene Wunde", sondern meistens „einen bereits geschlossenen Fix mit nachträglich vergebener Nummer".
Für den Leser heißt das konkret: Die Zahl der CVEs pro Version ist in erheblichem Maß eine Zahl der Buchhaltung. Sie misst, wie gründlich die Kernel-Gemeinschaft ihre eigenen Fixes katalogisiert – nicht unmittelbar, wie gefährlich der Kernel geworden ist.
Wie ein Sicherheitsfix durch die Serien wandert#
Der Weg einer Korrektur macht den Unterschied zwischen „gefixt" und „bei dir angekommen" sichtbar. Grundregel: Ein Fix darf nur dann in einen Stable-Tree aufgenommen werden, wenn er – oder ein gleichwertiger Fix – bereits in Mainline existiert 4 . Es wird also nichts Eigenes für die alte Serie erfunden, sondern eine bereits erprobte Änderung zurückgetragen.
Für Sicherheitslücken gibt es einen eigenen Kanal: Sicherheits-Patches sollen laut Stable-Regeln nicht allein über den regulären -stable-Review laufen, sondern dem Prozess für Sicherheitslücken folgen, den die Datei Documentation/process/security-bugs.rst beschreibt 4
. Für unveröffentlichte Schwachstellen, die unter Embargo laufen, gibt es dort einen separaten, nicht öffentlichen Meldeweg 4
. Sobald ein Fix in Mainline gelandet ist, wird er anschließend auf die gepflegten Stable- und Longterm-Serien angewendet 4
.
Für deine Praxis folgt daraus zweierlei. Erstens: Der Zeitpunkt, an dem eine CVE öffentlich vergeben wird, liegt hinter dem Zeitpunkt, an dem der Fix geschrieben wurde – die CVE-Nummer folgt dem Fix, nicht umgekehrt 2 . Zweitens: Ob der Fix bei dir wirkt, hängt davon ab, ob deine Distribution den Stable-Fix in ihren eigenen Kernel übernommen und du das Update eingespielt und neu gestartet hast. Zwischen „CVE vergeben" und „dein System geschützt" liegen also mehrere Schritte, die nicht automatisch passieren.
Warum die Kurve springt – und was sie nicht heißt#
Aus der Grafik allein lässt sich keine Ursache für den Anstieg ableiten. Das ist ein wichtiger Punkt, weil die naheliegende Lesart – „der Kernel ist plötzlich viel unsicherer" – nicht belegt ist.
Mindestens drei Faktoren können gleichzeitig in die Zahl einfließen. Erstens die Anzahl der tatsächlich eingespielten Fixes: Wenn in einer Versionssprungphase mehr Änderungen landen, steigt auch die Zahl der darunter als sicherheitsrelevant eingestuften Commits. Zweitens die Vergabepraxis: Die Kernel-Dokumentation erklärt selbst, dass die großzügige, übervorsichtige CVE-Vergabe die absoluten Zahlen in die Höhe treibt 2 . Drittens die Rückportierung: Ein Fix, der in eine neuere Serie aufgenommen wurde, wird auf alle noch gepflegten älteren Stable-Serien zurückportiert 4 . Wo viele Serien parallel gepflegt werden, taucht derselbe Fix mehrfach auf – einmal pro Serie, in der er landet.
Ob und wie stark automatisierte Analysewerkzeuge dabei eine Rolle spielen, lässt sich aus der einzelnen Grafik nicht belegen. Was sich belegen lässt, ist die Richtung der Kurve und die dokumentierte Vergabepraxis. Deshalb ist die seriöse Schlussfolgerung enger, als manche Diskussion nahelegt: Ein höherer CVE-Wert pro Version ist kein Beleg dafür, dass dein System exponierter ist als im Vorjahr. Er ist vor allem ein Hinweis darauf, dass mehr Fixes gezählt und nummeriert werden.
Praktisch bedeutet das für dich: Orientiere dich nicht an der absoluten Zahl der CVEs, sondern an einer einzigen, klaren Frage – ist deine Kernel-Version noch in einer gepflegten Serie und auf einem aktuellen Patchlevel?
So prüfst du deinen eigenen Kernel#
Die Prüfung dauert wenige Minuten und braucht nur die Befehlszeile.
Schritt 1: Laufende Version anzeigen.
uname -rDie Ausgabe sieht zum Beispiel so aus: 6.8.0-52-generic oder 6.6.160-1-pve. Der Teil vor dem ersten Bindestrich ist die Upstream-Basisversion, der Rest kennzeichnet den Distributions-Build. Falls du mehr Kontext willst, zeigt uname -a das vollständige System, und cat /proc/version liefert dieselbe Information unabhängig von uname.
Schritt 2: Prüfen, ob die Serie noch gepflegt wird.
Auf der Release-Seite von kernel.org findest du die aktuell gepflegten Serien samt geplantem Supportende 3 . Zum Zeitpunkt dieser Recherche sind das die Longterm-Serien 6.18, 6.12, 6.6, 6.1, 5.15 und 5.10, dazu die jüngere Stable-Serie 7.2 und die Mainline 7.3 3 . Liegt deine Basisversion in dieser Liste und ist das „Projected EOL" nicht überschritten, wird die Serie upstream noch gepflegt.
Wichtig ist die Einschränkung direkt dahinter: Was bei dir ankommt, entscheidet deine Distribution, nicht kernel.org. Viele Distributionen betreiben eigene Longterm-Kernel, die von den kernel.org-Serien abweichen können 3 . Ein Distributions-Kernel mit scheinbar älterer Versionsnummer kann trotzdem aktuell gepatcht sein, weil die Distribution Sicherheitsfixes in ihren eigenen Baum zurückportiert 3 . Maßgeblich ist deshalb immer der Sicherheitsstatus deiner Distribution, nicht der Versionsvergleich mit kernel.org.
Schritt 3: Patchlevel und verfügbare Updates prüfen.
Kernel-Updates sind bei den meisten Distributionen ganz normale Pakete. Unter Debian und Ubuntu:
sudo apt update
apt list --upgradableUnter Fedora und RHEL-Verwandten:
sudo dnf check-updateSteht ein Kernel-Paket in der Liste, ist dein System nicht auf dem aktuellen Patchlevel.
Schritt 4: Betroffene CVEs für deine Version ermitteln.
Die vollständige Liste aller für den Linux-Kernel vergebenen CVEs wird über die Mailingliste linux-cve-announce veröffentlicht; dort kannst du sie einsehen oder abonnieren 5
. Für den Alltag ist der Weg über die Distribution meist bequemer: Ubuntu veröffentlicht Security Notices (USN), Debian Advisories (DSA), Red Hat und SUSE eigene Trackers. Diese listen pro Update, welche CVEs damit geschlossen werden. Auch im lokalen Changelog eines Kernel-Pakets lässt sich nachsehen, welche CVEs ein Update behebt – unter Debian und Ubuntu zum Beispiel mit:
apt changelog linux-image-$(uname -r)Wer den Kernel-Git-Baum lokal hat, kann zusätzlich gezielt nach CVE-Verweisen in einem Versionsbereich suchen:
git log --oneline --grep="CVE-" v6.6..v6.6.160Das zeigt die behobenen CVEs zwischen zwei Tags der Serie 6.6.
So hältst du das System aktuell#
Die eigentliche Arbeit liegt nicht in der Prüfung, sondern darin, Updates regelmäßig einzuspielen – und zu verstehen, wann sie wirken.
Manuell aktualisieren. Unter Debian und Ubuntu ziehst du mit sudo apt upgrade alle verfügbaren Pakete einschließlich des Kernels nach. Unter Fedora erledigt das sudo dnf upgrade. Ein Kernel-Update wird dabei installiert, aber erst nach einem Neustart tatsächlich geladen.
Automatisch aktualisieren. Für Systeme, die du nicht täglich ansiehst, sind automatische Sicherheitsupdates sinnvoll. Unter Debian und Ubuntu aktivierst du das Paket unattended-upgrades und lässt es über die Sicherheits-Quelle laufen; unter Fedora gibt es dnf-automatic. So landen Kernel-Sicherheitsfixes auch auf Maschinen, die du selten anfasst.
Neu starten oder nicht? Ein eingespielter Kernel-Fix schützt erst nach dem Neustart. Das Werkzeug needrestart (Debian/Ubuntu) zeigt dir nach einem Update, welche laufenden Dienste noch mit alten Bibliotheken oder einem alten Kernel laufen. Für Server, die nicht einfach neu starten dürfen, gibt es Live-Patching – Ubuntu Livepatch, SUSE kernel livepatch, kpatch bei Red Hat –, das Sicherheitsfixes ohne Neustart anwendet. Live-Patching ist aber eine Überbrückung für die Zeit bis zum nächsten regulären Neustart, kein Ersatz dafür.
Ein Sonderfall für den Homelab-Kontext: Geräte mit OpenWrt oder anderen eingebetteten Linux-Systemen (Router, Firewalls, Mini-PCs) aktualisierst du über deren eigene Update-Mechanismen. Auch dort gilt dieselbe Logik: Die verbaute Kernel-Serie muss noch gepflegt sein, sonst hilft dir kein einzelner Fix.
Wann du sofort handeln solltest – und wann nicht#
Eine einfache Entscheidungsregel, ohne Panik und ohne Apathie:
- Das System ist aus dem Internet erreichbar oder verarbeitet unvertraute Eingaben (Webserver, Mail, Datei-Uploads, Container mit Fremdcode): Updates sofort einspielen und den Neustart zeitnah einplanen.
- Das System ist rein intern, ein Nutzer, keine unvertrauten Eingaben: regulärer Update-Rhythmus genügt, aber nicht aussetzen.
- Die Kernel-Serie ist ausgelaufen, das „Projected EOL" ist überschritten 3 : Dann ist die Priorität nicht das Patchen, sondern die Migration auf eine gepflegte Serie. Für eine nicht mehr unterstützte Version werden ohnehin keine CVEs mehr vergeben 2 , das System bleibt also unsichtbar in der Statistik – aber eben auch ungeschützt.
Der entscheidende Punkt ist die Regelmäßigkeit, nicht die einzelne Zahl. Ein System, das auf einer gepflegten Serie läuft und wöchentlich aktualisiert wird, ist durch die dokumentierte Fix-Praxis des Kernels besser abgesichert als eines, das auf der neuesten Serie steht, aber seit Monaten kein Update gesehen hat.
Missverständnisse, die du vermeiden solltest#
Drei Lesarten dieser Zahlen führen regelmäßig in die Irre, und alle drei lassen sich mit den Quellen korrigieren.
„Mehr CVEs heißt unsicherer." Die Kernel-Dokumentation erklärt die hohen absoluten Zahlen selbst mit der übervorsichtigen Vergabepraxis, die praktisch jeden sicherheitsrelevanten Fix mit einer Nummer versieht 2 . Ein Anstieg der gezählten CVEs ist deshalb nicht automatisch ein Anstieg des Risikos für dein System.
„Update eingespielt, also geschützt." Ein Kernel-Fix wird erst mit dem nächsten Neustart wirksam. Installierte, aber nicht aktivierte Updates schützen nicht; deshalb gehört der Neustart zum Update dazu, sofern kein Live-Patching im Einsatz ist.
„Alte Versionsnummer, also ungepatcht." Weil Distributionen Sicherheitsfixes in ihren eigenen Kernel zurückportieren 4 und eigene Longterm-Serien pflegen können 3 , sagt die Nummer allein nichts über den Sicherheitszustand. Maßgeblich ist der Sicherheitsstatus deiner Distribution, nicht der Versionsabstand zu kernel.org.
Entscheidungshilfe: Wann ist das sinnvoll?#
Eher sinnvoll, wenn du Linux-Sicherheitslücken pro Kernel-Version: Was die CVE-Zahlen wirklich aussagen nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?
Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.
Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.
Fazit#
Die Grafik aus Greg Kroah-Hartmans Repository dokumentiert einen messbaren Anstieg der pro Kernel-Version behobenen CVEs – von gut 500 in der 6.x-Serie auf zuletzt über 2.700 in 7.3 1
. Sie belegt aber nicht, dass der Kernel entsprechend unsicherer geworden ist: Die Kernel-Dokumentation erklärt die hohen absoluten Zahlen selbst mit einer übervorsichtigen Vergabepraxis 2
. Was du daraus mitnehmen kannst, ist eine Arbeitsregel, keine Angstzahl: Prüfe mit uname -r, ob deine Serie noch gepflegt ist, halte den Patchlevel über deine Distribution aktuell und starte nach Kernel-Updates auch neu. Die offene Grenze ist die Ursachenfrage hinter dem Anstieg – sie lässt sich aus einer einzelnen Kurve nicht beantworten.
Weiterführende Artikel#
- KI-Agenten in der Container-Security: Erfahrungen aus der Praxis
- Von VMware zu Proxmox wechseln: Lohnt sich der Umstieg für Profis?
- Synology 20TB HDD tickt und klickt dauerhaft — normal oder defekt?
- Self-hosted Dienste für die Familie absichern
- Solaranlage Eigenheim Kosten 2026: Der umfassende Guide für Eigenheimbesitzer
Passende Produktrecherchen#
Wenn du die praktische Seite vertiefen möchtest: Diese konkreten Produkte passen zum Thema dieses Artikels. Es ist keine Rangliste und keine Kaufpflicht, sondern eine kurze Auswahl mit Begründung, für wen sie interessant sein kann:
- GL.iNet GL-MT3000 Beryl AX WLAN-6-Reiserouter (OpenWrt) – Einsteiger, die ein günstiges, aktuell gepflegtes Linux-Netzwerkgerät betreiben wollen. – Linux-basierter OpenWrt-Router, der über regelmäßige Firmware-/Kernel-Updates gepflegt wird; eignet sich, um das Thema gepatchter Kernel im Homelab praktisch umzusetzen.
- GL.iNet GL-MT6000 Flint 2 WLAN-6-Router (OpenWrt) – Homelab-Betreiber, die einen leistungsfähigeren, dauerhaft gepatchten Router als Netzwerkgrundlage suchen. – Höherwertige OpenWrt-Option mit 2,5-Gbit-Ports für ein Heimnetz, das als Linux-System kontinuierlich Sicherheitsupdates erhält.
- Yubico YubiKey 5 NFC (2er-Pack) – Server-Betreiber, die SSH-Zugänge mit einem physischen zweiten Faktor absichern wollen. – Hardware-Sicherheitsschlüssel für FIDO2/SSH-Zwei-Faktor-Authentifizierung; schützt den Zugang zu Linux-Servern unabhängig vom Kernel-Patchlevel.
- Raspberry Pi 5 (8 GB RAM) – Einsteiger und Homelab-Nutzer, die ein kompaktes, stromsparendes Linux-System aufsetzen wollen. – Günstige Linux-Plattform, um einen eigenen, selbst gepatchten Kernel zu betreiben und den Update-/Prüfablauf aus dem Artikel direkt zu üben.
- Beelink S12 Pro Mini-PC (Intel N100, 16 GB RAM) – Nutzer, die statt eines Einplatinenrechners einen leistungsfähigeren Mini-Server für mehrere Linux-Dienste betreiben wollen. – Höherwertige Rechenbasis für einen Linux-/Proxmox-Server im Homelab, der dauerhaft gepflegt und per Kernel-Update abgesichert wird.
- Starlink-Verfügbarkeit und Konditionen prüfen
Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.
Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.
Grenzen der Einordnung#
Die Quellen beschreiben den Stand zum Zeitpunkt der Recherche. Sie ersetzen keine Prüfung im konkreten Einsatz; Konfiguration, Voraussetzungen und lokale Rahmenbedingungen können Ergebnisse verändern. Vor wichtigen Entscheidungen sollten Leserinnen und Leser die genannten Primärquellen erneut prüfen.
Transparenzhinweis#
Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.
Quellen#
[1] Greg Kroah-Hartman, „kernel-development" – Ordner graphs/patches_per_release mit cves_fixed_per_release.png und cves_per_release.rb
[2] The Linux Kernel documentation: CVEs
[3] The Linux Kernel Archives: Active kernel releases
[4] The Linux Kernel documentation: Everything you ever wanted to know about Linux -stable releases