SiteGround hat in 48 Stunden 5 kritische Sicherheitslücken im Linux-Kernel behoben – ohne jegliche Ausfallzeiten

Die letzten Wochen waren für alle, die beruflich Linux-Server betreiben, äußerst turbulent. Zwischen Ende April und Mitte Mai haben Sicherheitsforscher fünf schwerwiegende Sicherheitslücken im Kernel bekannt gegeben, von denen jede einem beliebigen angemeldeten Benutzer die Möglichkeit bot, vollständigen Root-Zugriff auf den Rechner zu erlangen. Für mehrere davon wurde bereits am ersten Tag funktionierender Exploit-Code veröffentlicht.

SiteGround hat alle diese Probleme auf unserer Hosting-Infrastruktur behoben – ohne einen einzigen Server neu zu starten und ohne den Dienst eines einzigen Kunden zu unterbrechen.

Was das für Ihre Websites bedeutet hätte

Einfach ausgedrückt: Wäre auch nur eine dieser Sicherheitslücken auf einem Server vor dem Schließen der Lücke ausgenutzt worden, hätte ein Angreifer, der bereits den kleinsten Einstiegspunkt hatte – ein kompromittiertes WordPress-Plugin, ein durchgesickertes FTP-Passwort, ein anfälliges Skript – seine Rechte von einem einzelnen Benutzerkonto mit niedrigen Berechtigungen innerhalb einer Website auf die vollständige Kontrolle über den zugrunde liegenden Host ausweiten können. Danach folgt das übliche Vorgehen: Dateien anderer Mandanten lesen, dauerhafte Hintertüren einbauen, Anmeldedaten stehlen und sich tiefer ins Netzwerk bewegen.

Das sind keine theoretischen Risiken. Für jede einzelne dieser Sicherheitslücken existierte öffentlich verfügbarer Exploit-Code. Besonders „Copy Fail“ wurde bereits wenige Tage nach der Bekanntgabe aktiv in der Praxis ausgenutzt.

Was tatsächlich passiert ist

In grober zeitlicher Reihenfolge traf Folgendes die Linux-Welt:

29. April, Copy Fail (CVE-2026-31431) bekannt gegeben – Ein einziges 732 Byte großes Python-Skript konnte praktisch jeden normalen Benutzer auf nahezu jeder seit 2017 ausgelieferten Linux-Distribution zu Root machen. Keine zeitlichen Tricks, kein Rätselraten – nur ein Logikfehler im Kryptografie-Subsystem des Kernels. CISA nahm die Sicherheitslücke innerhalb weniger Tage in ihre Liste aktiv ausgenutzter Schwachstellen auf.

7. Mai, Dirty Frag – xfrm/ESP-Sicherheitslücke (CVE-2026-43284) bekannt gegeben – Eine Sicherheitslücke im IPsec-ESP-Netzwerkcode des Kernels, die es einem Angreifer ermöglicht, beliebige Daten in die Speicherkopie schreibgeschützter Systemdateien zu schreiben. Wird oft als „Copy Fail 2“ bezeichnet.

7. Mai, Dirty Frag – RxRPC-Sicherheitslücke (zweite Hälfte der Kette) – Ein damit verbundener Fehler im RxRPC-Netzwerkmodul des Kernels. In Kombination mit der oben genannten xfrm/ESP-Sicherheitslücke verschafft er einem normalen Benutzer vollständige Root-Rechte.

13. Mai, Fragnesia / Copy Fail 3.0 (CVE-2026-46300) bekannt gegeben – Der dritte Fehler innerhalb von drei Wochen, aus derselben Familie wie „Dirty Frag“, ebenfalls im IPsec-Subsystem des Kernels. Ein funktionierender Proof-of-Concept wurde noch am selben Tag veröffentlicht.

14. Mai: ssh-keysign / chage pidfd-Sicherheitslücke – Bekannt gegeben und behoben von Linus Torvalds – Eine andere Art von Fehler – keine Rechteausweitung auf Root, aber er ermöglichte jedem nicht privilegierten Benutzer das Lesen von Dateien im Root-Verzeichnis wie /etc/shadow (die Passwort-Hashes) und SSH-Host-Schlüsseln.

Wie wir das ohne Ausfallzeiten behoben haben

Vier Entscheidungen darüber, wie SiteGround arbeitet, haben das möglich gemacht. Und angesichts dessen, was auf uns zukommt, werden alle vier künftig noch wichtiger werden. 

Wir beobachten die Bedrohungslage kontinuierlich. Unser Sicherheitsteam überwacht rund um die Uhr Kernel-Mailinglisten, CVE-Feeds und Informationskanäle. Wir wussten am Tag der Veröffentlichung von Copy Fail Bescheid, am selben Tag über Dirty Frag und innerhalb weniger Stunden nach Veröffentlichung des Proof-of-Concepts über Fragnesia. Es gibt keinen Ersatz dafür, diese Entwicklungen in Echtzeit zu verfolgen – bis solche Meldungen in den allgemeinen Tech-Nachrichten erscheinen, ist der Exploit-Code meist bereits seit Tagen verfügbar. Da KI-gestützte Schwachstellenforschung die Geschwindigkeit von Veröffentlichungen erhöht, wird diese Art permanenter Überwachung eher unverzichtbar als optional.

Wir haben rund um die Uhr Bereitschaftsingenieure. Kritische Kernel-Patches warten nicht auf die üblichen Geschäftszeiten – und wir auch nicht. Für jede dieser Sicherheitslücken haben wir innerhalb von 48 Stunden nach der öffentlichen Bekanntgabe Patches erstellt, getestet und auf unserer gesamten Infrastruktur bereitgestellt – meist lange bevor die meisten Distributionen überhaupt ihre offiziellen Pakete veröffentlicht hatten.

Wir nutzen Live-Kernel-Patching. Das ist der Punkt, der für Sie am wichtigsten ist. Herkömmliches Kernel-Patching erfordert einen Neustart, was Ausfallzeiten für alle auf dem Rechner laufenden Dienste bedeutet. Beim Live-Patching wird der Fix direkt auf den laufenden Kernel im Arbeitsspeicher angewendet, sodass die Sicherheitslücke geschlossen wird, ohne irgendetwas neu zu starten. Ihre Websites, Datenbanken, E-Mails und SSH-Sitzungen laufen während jedes einzelnen dieser Patch-Zyklen weiter. Wenn die Patch-Häufigkeit steigt, steigen auch die Kosten von „einfach den Server neu starten“ – Live-Patching sorgt dafür, dass diese Kosten für Sie bei null bleiben.

Wir halten unsere Kernel schlank. Ein wesentlicher Grund, warum diese Sicherheitslücken so gefährlich sind, besteht darin, dass der verwundbare Code auf den meisten Distributionen standardmäßig aktiviert ist. Copy Fail befand sich in der AF_ALG-Kernel-Kryptografie-Schnittstelle. Dirty Frag und Fragnesia befanden sich in den Modulen esp4, esp6 und rxrpc – also in IPsec- und AFS-Netzwerkcode, den die überwiegende Mehrheit aller Webserver niemals benötigen wird. Wir laden keine Kernel-Module, die wir nicht benötigen. Dadurch existierte ein Teil der Angriffsfläche für diese Exploits auf unseren Systemen von vornherein gar nicht, was uns zusätzlichen Spielraum verschaffte, um die eigentlichen Fixes sauber einzuspielen.

Der KI-Faktor – und warum das erst der Anfang ist

Ein Detail der Bekanntgabe von Copy Fail verdient besondere Aufmerksamkeit. Der Fehler wurde nicht von einem menschlichen Forscher entdeckt, der wochenlang Code analysierte. Stattdessen wurde er von einem KI-gestützten Code-Prüftool (Xint Code) in ungefähr einer Stunde Scan-Zeit innerhalb des Kryptografie-Subsystems des Linux-Kernels gefunden. Derselbe Scan brachte außerdem „weitere schwerwiegende Fehler, die sich noch in koordinierter Offenlegung befinden“ ans Licht – was bedeutet, dass bereits weitere Bekanntgaben bevorstehen.

Das ist ein grundlegender Wandel darin, wie Sicherheitslücken entdeckt werden. Über Jahre hinweg bestand der Engpass bei der Entdeckung kritischer Kernel-Fehler in der begrenzten Anzahl hochqualifizierter Experten, die bereit waren, monatelang Kernel-Quellcode zu lesen. Dieser Engpass existiert nicht mehr. KI-Prüftools können inzwischen komplette Subsysteme mit Maschinengeschwindigkeit analysieren und finden Fehler, die seit fast einem Jahrzehnt in stabilen Kernel-Versionen verborgen waren.

Was das in der Praxis bedeutet: Die Zahl schwerwiegender Sicherheitslücken wird weiter steigen. Drei universell ausnutzbare Local-Root-Exploits innerhalb von drei Wochen sind kein Zufall – sie sind ein Vorgeschmack. Reaktive Patching-Zyklen, die funktionierten, als alle sechs Monate ein kritischer Kernel-Fehler auftauchte, werden nicht mehr ausreichen, wenn alle zwei Wochen einer erscheint. Die Fähigkeit, Sicherheitslücken innerhalb von Stunden statt Tagen zu erkennen, darauf zu reagieren und sie zu beheben, ist nicht mehr ein nettes Extra – sie ist die Grundvoraussetzung für Sicherheit.

Das Fazit

Linux erlebt derzeit eine ungewöhnlich schwierige Phase in Bezug auf Kernel-Sicherheit – drei universelle Local-Root-Exploits innerhalb von drei Wochen sind nicht normal, und die Entwicklung verlangsamt sich nicht. Da KI-gestützte Prüftools den Kernel inzwischen mit einer Geschwindigkeit analysieren, die kein menschliches Team erreichen könnte, erwarten wir, dass die Entdeckungsrate schwerwiegender Sicherheitslücken weiter zunimmt. Die Fehler, die jahrelang unentdeckt in stabilen Kernel-Versionen verborgen waren, werden jetzt gefunden – ein Subsystem nach dem anderen.

Was wir versprechen können: So, wie wir diese Vorfälle behandelt haben, behandeln wir jede schwerwiegende Sicherheitslücke – frühzeitig überwachen, schnell reagieren, live beheben und die Angriffsfläche von Anfang an so klein wie möglich halten. Ihre Websites bleiben online. Die Sicherheitslücken nicht. Und je schneller sich diese Entwicklung beschleunigt, desto wichtiger wird genau das werden.