Beim Linux-Kernel steigt die Zahl der gemeldeten und behobenen Schwachstellen auf ein Niveau, das die bisherige Arbeitsweise der Maintainer belastet. Nach den vorliegenden Angaben nähert sich die Zahl der behobenen CVEs pro Release der Marke von 2.000. In der Linux-6.x-Phase lag sie noch bei etwa 500. Mit Linux 7.0 wurde die Marke von 1.000 überschritten, mit Linux 7.2 die Marke von 1.500.
Der Befund ist leicht falsch zu lesen. Eine höhere CVE-Zahl bedeutet nicht automatisch, dass der Kernel plötzlich unsicherer geworden ist. Sie zeigt vor allem, dass mehr Code systematisch durchsucht wird. Der Linux-Kernel umfasst inzwischen mehr als 40 Millionen Zeilen. KI-gestützte Werkzeuge können diesen Bestand in einer Breite analysieren, die mit klassischer manueller Prüfung nicht erreichbar war. Dadurch werden Fehler sichtbar, die lange unentdeckt geblieben sind.
Für die industrielle Nutzung von Linux ist die zentrale Folge allerdings nicht die Rekordzahl. Entscheidend ist der neue Engpass: Aus dem Finden von Schwachstellen wird ein Problem der Prüfung, Priorisierung und Einordnung. Genau dort sitzt die knappe Ressource.
Die CVE-Zahl misst jetzt auch Suchkapazität
Im Februar 2024 wurde das Kernel-Team eine eigene CVE Numbering Authority. Seitdem kann das Projekt Schwachstellenkennungen selbst vergeben. Im Jahr 2024 wurden dem Linux-Kernel 3.529 CVEs zugewiesen, ein zehnfacher Anstieg. Diese organisatorische Änderung erklärt einen Teil des Sprungs. Der zweite Teil kommt aus der technischen Detektion.
Vom KI-Fund zum Kernel-Patch
Die Grafik zeigt, wo bei KI-gestützter Schwachstellensuche im Linux-Kernel der operative Engpass entsteht: nicht beim Finden, sondern bei Prüfung und Weitergabe.
Linux-Stable-Maintainer Greg Kroah-Hartman zeigte den Trend in einer Folie für Kernel Recipes 2026. Die Zahlen steigen nicht nur, weil mehr Sicherheitsprobleme existieren, sondern weil mehr potenzielle Probleme gefunden, markiert und in den stabilen Entwicklungsprozess eingespeist werden. Das verändert den Wert der CVE-Zahl. Sie ist weiterhin relevant, aber sie misst nicht nur Schwere und Risiko. Sie misst auch Suchintensität, Meldeverhalten und Vergabepraxis.
Für Unternehmen, die Linux in Servern, Appliances, Containern, Cloud-Umgebungen oder eingebetteten Systemen einsetzen, ist das wichtig. Ein Anstieg der CVEs kann interne Risikoprozesse auslösen, ohne dass jeder einzelne Eintrag denselben operativen Druck erzeugt. Sicherheitsabteilungen müssen daher stärker trennen: Welche Schwachstelle betrifft die eigene Kernel-Version? Ist der betroffene Code überhaupt aktiviert? Liegt der Fehler in einem Treiber, der im eigenen Betrieb nicht genutzt wird? Gibt es bereits einen stabilen Fix?
Der Engpass liegt in der Prüfung
Die neue Lage trifft auf ein altes Strukturproblem von Open Source: Viele Systeme hängen am Linux-Kernel, aber nur ein begrenzter Kreis von Personen trägt die Verantwortung für Aufnahme, Prüfung und Stabilisierung von Änderungen. KI verschiebt hier nicht nur die Menge, sondern auch die Qualität der Eingaben. Viele Funde sind nach den vorliegenden Berichten niedrig priorisiert, doppelt gemeldet, mit fragwürdigen Patches verbunden oder schlicht falsch.
Linus Torvalds bezeichnete die private Sicherheits-Mailingliste des Linux-Kernels als „fast völlig unüberschaubar“. Der Grund sei eine Flut doppelter Schwachstellenberichte, die von Forschern erzeugt wurden, die ähnliche KI-Werkzeuge gegen denselben Code laufen ließen. Auch die Einschätzung von Jakub Kicinski zeigt den Umfang: Zwischen einem Drittel und der Hälfte der 648 Patches im net-next-Pull-Request für Linux 7.3 seien KI-getrieben gewesen.
Das ist operativ relevant. Ein Report spart nur dann Zeit, wenn er reproduzierbar ist, den betroffenen Code sauber beschreibt und einen Patch liefert, der keine Folgeschäden erzeugt. Ein schlechter Report erzeugt zusätzliche Arbeit. Maintainer müssen prüfen, ob der Fehler real ist, ob er bereits bekannt ist, ob die vorgeschlagene Korrektur sinnvoll ist und ob sie stabile Kernel-Zweige nicht beschädigt. Bei vielen ähnlichen Eingaben entsteht kein Sicherheitsgewinn, sondern ein Wartestau.
Alte Codebereiche werden sichtbar
KI-gestützte Analyse hat dennoch einen klaren Nutzen. Sie findet Fehler in Bereichen, die menschliche Prüfer selten priorisieren. Genannt werden unter anderem eine 23 Jahre alte Heap-Buffer-Overflow-Schwachstelle im NFSv4-Treiber und die fast 15 Jahre alte Local-Privilege-Escalation-Schwachstelle GhostLock, CVE-2026-43499. Solche Funde zeigen, dass langjähriger Code nicht automatisch geprüfter Code ist.
Für die Kernel-Wartung entsteht daraus ein sachlicher Zielkonflikt. Einerseits ist der Linux-Kernel breit, weil er sehr viele Hardware-, Protokoll- und Einsatzvarianten abdeckt. Andererseits erzeugt jede alte oder selten genutzte Komponente Prüfaufwand, sobald Analysewerkzeuge sie systematisch durchsuchen. Obskurer Treibercode war früher oft ein Randthema. Wenn er massenhaft Meldungen erzeugt, wird er zum Arbeitsprogramm.
Das kann die Diskussion über das Entfernen oder Einschränken alter Codepfade verstärken. Nicht jeder selten genutzte Teil des Kernels ist verzichtbar. In Industrie, Telekommunikation, Medizintechnik oder älteren Embedded-Installationen laufen lange Lebenszyklen. Trotzdem steigt der Druck, unklare Wartungszustände zu bereinigen. Ein Codebereich, den kaum jemand nutzt und kaum jemand pflegt, kann durch KI-Prüfung zu einem dauerhaften Kostenfaktor werden.
Für Betreiber zählt Priorisierung mehr als Alarm
Die direkte Folge für Betreiber ist kein einfacher Befehl zu schnelleren Updates. In produktiven Umgebungen sind Kernel-Updates riskant, weil sie Treiber, Storage, Netzwerkpfade und Laufzeitumgebungen berühren können. Wer zu schnell patcht, kann Stabilität verlieren. Wer zu langsam patcht, vergrößert das Angriffsfenster. KI-gestützte Schwachstellensuche verschärft diese Abwägung, weil öffentlich bekannte Fehler schneller in großer Zahl beschrieben werden.
Für Cloud-Anbieter, Rechenzentrumsbetreiber und Hersteller von Linux-basierten Produkten wird deshalb die Zuordnung wichtiger. Sie müssen wissen, welche Kernel-Zweige betroffen sind, welche Konfigurationen den verwundbaren Code enthalten und welche Patches bereits in Distributionen oder eigenen Builds angekommen sind. Pauschale CVE-Zählung reicht dafür nicht. Sie produziert hohe Fallzahlen, aber keine belastbare Reihenfolge.
Besonders betroffen sind Organisationen mit langen Freigabeprozessen. Wenn ein Kernel-Fix erst mehrere interne Prüfstationen durchläuft, kann die Zeit zwischen öffentlicher Korrektur und produktiver Absicherung zu lang werden. Das gilt vor allem dort, wo Linux nicht als Standarddistribution läuft, sondern als angepasster Kernel in Geräten, Appliances oder spezialisierten Plattformen. Dort ist jeder Patch ein Integrationsprojekt.
Open Source braucht bessere Eingangsfilter
Die naheliegende technische Antwort ist nicht, KI-Berichte grundsätzlich abzuweisen. Dafür liefern die Werkzeuge zu viele reale Funde. Sinnvoller ist eine strengere Eingangskontrolle. Berichte müssen Duplikate vermeiden, reproduzierbare Testfälle enthalten und klar markieren, ob ein Patch von Menschen geprüft wurde. Auch die Einordnung der betroffenen Konfigurationen wird wichtiger. Ein Fehler in einem selten genutzten Treiber ist nicht wertlos, aber er darf nicht dieselbe Dringlichkeit beanspruchen wie ein breit aktivierter Netzwerk- oder Speicherpfad.
Für Sicherheitsfirmen und Forscher ändert sich damit ebenfalls der Maßstab. Die bloße Fähigkeit, große Codemengen nach Mustern zu durchsuchen, ist kein ausreichender Beitrag. Wert entsteht erst, wenn ein Fund in eine Form gebracht wird, die Maintainer verarbeiten können. Das schließt saubere Reproduktion, Abgleich mit bekannten Meldungen und realistische Patch-Vorschläge ein.
Der Linux-Kernel wird durch KI-gestützte Analyse transparenter. Gleichzeitig wird die Wartung weniger planbar. Die praktische Sicherheitsfrage verschiebt sich daher vom Entdecken zum Verarbeiten. Wer Linux betreibt oder darauf Produkte baut, muss nicht jede neue CVE gleich behandeln. Er muss aber seine Fähigkeit verbessern, aus einer wachsenden Menge an Meldungen schnell die relevanten Fälle herauszufiltern. Genau dort entscheidet sich, ob mehr gefundene Schwachstellen am Ende zu mehr Sicherheit führen oder nur zu mehr Rückstau.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
