432 CVEs an einem Tag: Was die Linux-Kernel-CVE-Flut wirklich bedeutet

TL;DR

TL;DR: Die 432 Linux-Kernel-CVEs vom 20. Juli 2026 sind ein Bulk-Publish aus dem automatisierten CNA-Prozess des Kernels, kein Einzelvorfall. Seit Februar 2024 vergibt der Kernel selbst CVE-IDs für praktisch jeden Stable-Tree-Fix mit theoretischem Sicherheitsbezug, bewusst „überkautiös“ und ohne Standard-Severity-Score. Linux führt dadurch 2026 die CVE-Charts mit über 2.300 CVEs im ersten Halbjahr an — Greg Kroah-Hartman nennt das ein Transparenz-Feature, kein Sicherheitsproblem, weil geschlossene Anbieter nur „High“-Funde melden. Praktisch relevant wird das über die EU Cyber Resilience Act: Ab September 2026 müssen aktiv ausgenutzte Schwachstellen binnen 24 Stunden gemeldet werden, ab Dezember 2027 gilt die volle Vulnerability-Handling-Pflicht für jede im Produkt verbaute Kernel-Version. Die empfohlene Strategie: nicht jede CVE einzeln bewerten, sondern gegen die eigene Kernel-Branch/Version/Konfiguration filtern und gepflegte LTS-Punktreleases statt Einzel-Patches fahren.

Was am 20. Juli passiert ist

Die Zahl 432 stammt aus einer Diskussion auf LowEndTalk, die kurz nach der Veröffentlichung Fahrt aufnahm und auf mehreren Fediverse-Instanzen gespiegelt wurde. Ein Moderator ordnete die Charge dort so ein: „die meisten davon sind DoS-Vektoren, setzen Rechte voraus oder betreffen obskure Treiber“ — als Beispiel wird ein NULL-Pointer-Dereference im ALSA-PCM-Code auf RISC-V genannt. Nichts davon ist eine unauthentifizierte Remote-Code-Execution-Lücke in einem weit verbreiteten Subsystem.

Auffällig ist eher die schiere Menge auf einen Schlag als ihr Inhalt. Genau diese Wucht ist Teil dessen, was Kritiker am aktuellen Kernel-CVE-Prozess bemängeln: Wo Linus Torvalds früher die Haltung vertrat, „Sicherheitslücken sind einfach Bugs und brauchen keine Sonderbehandlung“, behandelt der Kernel inzwischen praktisch jeden Bugfix als potenzielle CVE. Das ist eine bewusste Kurskorrektur, keine Panne.

Warum der Kernel so viele CVEs produziert

Seit Februar 2024 ist der Linux-Kernel seine eigene CVE Numbering Authority — er muss nicht mehr auf Distributionen oder Dritte warten, die eine CVE-ID beantragen. Die offizielle Prozessdokumentation (docs.kernel.org/process/cve.html) beschreibt die Praxis unverblümt: Das CVE-Assignment-Team ist „überkautiös“ (overly cautious) und vergibt eine CVE-Nummer für jeden Bugfix, den es als potenziell sicherheitsrelevant identifiziert. Wichtige Einschränkungen aus derselben Dokumentation:

• Nur für bereits gefixte Probleme: Es werden keine CVEs für unbehobene Sicherheitslücken vergeben — automatisiert passiert das erst, nachdem ein Fix existiert und in einen Stable-Kernel-Baum gelandet ist.
• Nur für aktiv gepflegte Versionen: Für Kernel-Versionen, die das Stable/LTS-Team nicht mehr aktiv unterstützt, werden keine neuen CVEs vergeben.
• Relevanzprüfung liegt beim Nutzer: Wörtlich: „Wir wissen nicht, welche Teile des Kernels Sie verwenden, daher können wir nicht bestimmen, ob eine bestimmte CVE für Sie relevant ist.“ Große Teile der vergebenen CVEs betreffen laut Dokumentation Subsysteme, die die meisten Systeme gar nicht nutzen.
• Keine Standard-Severity-Scores: Nach Berichten zum aktuellen Prozess vergibt der Kernel bewusst keine CVSS-Bewertung zu den meisten seiner rund 50 CVEs pro Woche — die Einordnung bleibt bewusst den Konsumenten überlassen.

Die Kernel-Dokumentation empfiehlt entsprechend, nicht einzelne CVE-Patches zu jagen, sondern komplette Stable/LTS-Releases zu übernehmen: „Die Lösung liegt nicht in einer einzelnen Änderung, sondern in der Summe vieler Fixes übereinander.“

Das große Bild: Linux an der CVE-Spitze 2026

Die 432er-Charge ist keine Ausnahme, sondern Teil eines Trends. Nach der Mid-Year-2026-Auswertung von Jerry Gamblin wurden im ersten Halbjahr 2026 insgesamt 35.364 CVEs über alle Hersteller und Produkte hinweg veröffentlicht — ein Plus von 49,5% gegenüber dem Vorjahreszeitraum (23.656), im Schnitt etwa eine neue CVE alle 7,4 Minuten. Linux führt die Hersteller-Wertung mit rund 2.300 bis 2.564 CVEs an (die genaue Zahl variiert leicht je nach Quelle und Stichtag), noch vor Google (~1.752) und Microsoft (~843); als Einzelprodukt liegt der Linux-Kernel mit rund 1.956 CVEs vorn.

Greg Kroah-Hartman, der die Kernel-Stable-Releases pflegt, kommentiert die Spitzenposition explizit positiv: Geschlossene Anbieter wie Apple oder Microsoft melden traditionell nur „High“-Severity-Funde an CVE-Datenbanken, während offene Projekte wie der Kernel konsequent alles melden — unabhängig vom Einsatzkontext, der von Servern über Smartphones bis zu Industriesteuerungen reicht. Die hohe Zahl ist nach dieser Lesart ein Transparenz-Indikator, kein Nachweis schlechterer Sicherheit.

Wichtig zur Einordnung der schieren Menge: Von den 35.364 CVEs aus dem ersten Halbjahr 2026 tauchten zum Zeitpunkt der Auswertung nur 85 (0,24%) im CISA-KEV-Katalog auf, also nachweislich aktiv ausgenutzte Lücken. Rohes CVE-Volumen ist ein Priorisierungsproblem, keine direkte Handlungsanweisung.

Was das für Betreiber bedeutet: die CRA-Perspektive

Für Unternehmen, die Produkte mit Linux-Kernel ausliefern, ist das kein rein akademisches Thema — die EU Cyber Resilience Act (CRA) macht daraus eine Compliance-Frage. Ab September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden nach Kenntnisnahme melden. Ab Dezember 2027 gelten die vollen Pflichten: Security by Design, keine bekannten ausnutzbaren Schwachstellen bei Auslieferung, ein dokumentierter Vulnerability-Handling-Prozess und Sicherheitsupdates über den Support-Zeitraum des Produkts. Diese Pflichten erstrecken sich laut Berichten zur CRA-Kernel-Schnittstelle ausdrücklich auf jede Softwarekomponente im Produkt — also auch auf den Kernel und jede Kernel-CVE, die die ausgelieferte Version betrifft.

Bei rund 50 Kernel-CVEs pro Woche, bewusst ohne Severity-Score, wird daraus schnell ein Vollzeitproblem: Rund 200 CVEs im Monat einzeln gegen die eigene Kernel-Version und -Konfiguration zu mappen, einzeln zurückzuportieren und jede Entscheidung zu dokumentieren, übersteigt laut Einschätzung der einschlägigen Berichterstattung den Aufwand, einfach die Stable-Updates zu übernehmen. Die empfohlene Strategie: Kernel-CVEs automatisiert gegen die tatsächlich ausgelieferte Branch, Version und Konfiguration filtern, sodass Menschen nur die kurze Restliste prüfen statt des vollen Stroms — dazu ein gepflegtes SBOM und dokumentierte Entscheidungen als Prüfnachweis für Regulierer. Der wirtschaftlichste Weg bleibt, einer gepflegten LTS-Linie zu folgen und deren Punktreleases zu übernehmen, statt einzelne Fixes herauszupicken.

Praktische Einordnung

Drei Punkte, die sich aus der Kernel-eigenen Dokumentation und der CRA-Perspektive für den Alltag ableiten lassen:

1. Eine CVE-ID allein sagt nichts über Relevanz. Das bestätigt die Kernel-Dokumentation selbst — die Einschätzung, ob ein betroffenes Subsystem überhaupt in Ihrer Konfiguration aktiv ist, liegt bei Ihnen, nicht beim Assignment-Team.
2. Priorisieren Sie nach Ausnutzbarkeit, nicht nach Volumen. CISA-KEV-Aufnahme und EPSS-Score sind belastbarere Signale als die reine CVE-Zahl — bei einer Ausnutzungsquote von 0,24% im ersten Halbjahr 2026 ist rohes Volumen ein Triage-Problem, keine Handlungsanweisung für sich genommen.
3. Automatisieren Sie das Filtern, nicht das Ignorieren. Ein Kernel-CVE-Feed gegen die eigene Branch/Version/Konfiguration gematcht, plus ein gepflegtes SBOM, verwandelt einen unlesbaren Strom in eine kurze, tatsächlich prüfbare Liste — und liefert nebenbei die Dokumentation, die CRA-Audits verlangen.

Fazit

432 CVEs an einem Tag klingen nach einer Krise, sind aber vor allem ein Beleg dafür, wie konsequent der Linux-Kernel seine eigene CVE-Numbering-Authority-Rolle ausfüllt: lieber zu viel melden als zu wenig, ohne Severity-Vorfilterung, mit der ausdrücklichen Ansage, dass die Relevanzprüfung bei den Nutzern liegt. Das macht rohes CVE-Volumen zu einem schlechten Kompass — und die Kombination aus automatisiertem Filtern gegen die eigene Konfiguration, Priorisierung nach Ausnutzbarkeit und dem Festhalten an gepflegten LTS-Linien zur eigentlich tragfähigen Strategie, gerade mit Blick auf die CRA-Fristen ab September 2026.

Quellen

• LowEndTalk — 432 Linux CVEs published in the last 24 hours
• Linuxiac — Linux Tops 2026 CVE Charts, Greg KH Says That's a Good Thing
• Jerry Gamblin — CVE Mid-Year 2026 Check-In
• Linux Kernel Documentation — CVEs
• TechVeda — Kernel CVEs and the EU Cyber Resilience Act
• OpenSSF — Linux Kernel Achieves CVE Numbering Authority Status