Schwere Linux-Kernel-Lücke: Ist dein PrestaShop-Shop betroffen?

Wenn du von einer schweren Sicherheitslücke im Linux-Kernel gelesen hast und einen PrestaShop-Shop betreibst, betrifft es dich wahrscheinlich: Fast alle Shops laufen auf Linux. Über diese Lücke kommt niemand direkt aus dem Internet in deinen Shop, aber wer bereits etwas auf deinem Server ausführen konnte, kann die ganze Maschine übernehmen. Was du heute tun musst, hängt davon ab, wo dein Shop liegt: Beim Shared Hosting fragst du deinen Anbieter, auf einem eigenen Server aktualisierst du und startest neu.

Die Warnung, die das Thema zurückgebracht hat, kam am 28. Oktober: Die US-Behörde für Cybersicherheit CISA nahm die Lücke Fragnesia in ihre Liste der bereits in echten Angriffen genutzten Schwachstellen auf.

Was ist mit dem Linux-Kernel passiert?

Der Kernel ist das Herzstück von Linux: der Teil, der über alles andere auf dem Server bestimmt. Dieses Jahr kamen mehrere schwere Lücken kurz hintereinander, deshalb siehst du so viele Schlagzeilen: Copy Fail, Dirty Frag, Fragnesia, GhostLock, Vghost. Seit Mai hat die CISA acht Kernel-Lücken in diese Liste aufgenommen.

Die Namen musst du dir nicht merken. Diese fünf haben gemeinsam, was für dich wirklich zählt: Es sind lokale Lücken.

Kann jemand über diese Lücke in meinen PrestaShop-Shop eindringen?

Allein über sie nicht. Microsoft erklärt das am Beispiel Copy Fail: Der Angreifer muss schon einen Fuß auf der Maschine haben. Und Red Hat sagt dasselbe über Fragnesia: Es braucht lokalen Zugriff auf das System.

Stell dir deinen Server als Bürogebäude vor. Diese Lücken öffnen nicht die Haustür. Aber wer schon drinnen ist, und sei es in einer Abstellkammer, bekommt die Schlüssel zum ganzen Gebäude.

Und wie kommt man in diese Kammer? Auf ziemlich gewöhnlichen Wegen:

• Ein Modul mit einer Sicherheitslücke, über das sich Code auf deinem Server ausführen lässt.
• Eine andere Website in deinem eigenen Konto, etwa das alte WordPress, das niemand aktualisiert.
• Die Website eines anderen Kunden, wenn du auf Shared Hosting bist. CloudLinux, dessen System viele Hoster nutzen, warnt, dass ein böswilliger Kunde andere Konten auf derselben Maschine erreichen könnte.
• Eine Lücke in PHP, wie PHP2Shell.

Das Letzte ist keine Theorie. In ihrem Eintrag zu Fragnesia warnt die CISA, dass sich diese Lücke mit PHP2Shell verketten lässt, um eine Hintertür einzubauen und Befehle mit voller Kontrolle über den Server auszuführen. Die CISA hat keine Details zu diesen Angriffen genannt, und was wir gelesen haben, erwähnt keine Onlineshops: kein Grund zur Panik, aber jeder Grund, beides zu schließen.

Warum reicht es nicht, den Server zu aktualisieren?

Weil ein neuer Kernel nichts bewirkt, bis der Server mit ihm startet. Daran erinnern Ubuntu, AlmaLinux und das kanadische Zentrum für Cybersicherheit: aktualisieren und neu starten. Ein Server kann den Fix seit Wochen installiert haben und trotzdem noch mit dem alten Kernel laufen.

Der andere Weg ist das Live-Patching: Werkzeuge wie KernelCare, die den Fix auf den laufenden Kernel anwenden, ohne Neustart. Beim Shared Hosting legt jeder Neustart alle Kunden lahm, also ist „wir haben nicht neu gestartet“ kein schlechtes Zeichen, wenn man dir sagt, dass Live-Patching aktiv ist.

Was muss ich tun, je nachdem, wo mein Shop liegt?

Wenn du auf Shared Hosting bist

Du meldest dich in einem Panel an, etwa cPanel oder Plesk, und verwaltest den Server nicht. Der Kernel ist Sache deines Anbieters; deine ist es, nachzufragen. Kopiere das und schicke es ab:

Eine gute Antwort enthält Daten: eine Version, ein Datum, den Namen des Werkzeugs. Antwortet man dir nur „wir sind auf dem neuesten Stand“, frag noch einmal nach der Version. Wird es in ein paar Tagen nicht klarer, ist ein guter Moment, über einen Wechsel nachzudenken.

Wenn du einen VPS oder einen dedizierten Server hast

Hier bist du dran oder wer ihn für dich betreut: Sicherheitsupdates installieren und neu starten. Wähle eine verkaufsschwache Stunde, denn der Shop ist ein paar Minuten weg, und prüfe danach, ob man kaufen kann.

Vergleiche dann die laufende Version mit der im Hinweis deines Systems: Ubuntu, Debian, AlmaLinux oder Red Hat. Jedes System nummeriert auf seine Art: Schau immer bei deinem nach.

Wenn dein Shop in einem Container läuft

Docker und Ähnliches, aber auch manche günstigen VPS, die in Wirklichkeit Container sind. Sie teilen sich den Kernel der Maschine, auf der sie laufen, also ändert ein Update von innen nichts. Den Fix spielt ein, wer diese Maschine verwaltet: Wenn das dein Anbieter ist, schick ihm die Nachricht von oben.

Was heute zu tun ist, der Reihe nach

1. Finde heraus, welcher Fall bei dir vorliegt: Shared Hosting, eigener Server oder Container. Wenn du es nicht weißt, frag deinen Hoster.
2. Mach ein vollständiges Backup, Dateien und Datenbank, und bewahre es außerhalb des Servers auf.
3. Schick die Nachricht an deinen Hoster, oder aktualisiere und starte neu, wenn der Server dir gehört.
4. Schließe die Eingänge: PHP mit dem PHP2Shell-Fix, Module aktuell und weg mit dem, was du nicht mehr nutzt, ob Module oder alte Websites in deinem Konto. Welches PHP jede Version unterstützt, steht in welche PHP-Version PrestaShop braucht.
5. Achte auf Anzeichen, dass schon jemand drin ist, etwa ein seltsames Fenster beim Besuch deines Shops oder Dateien, die du nicht kennst.

Ein Update schließt die Tür, wirft aber niemanden hinaus, der schon drinnen ist. Microsoft warnt, dass Schutzmaßnahmen das, was ein Angreifer bereits getan hat, möglicherweise nicht rückgängig machen.

Kommt dir etwas komisch vor, fang an mit wie ein mit ClickFix gehackter Shop aussieht, und lösche nichts, bis es jemand geprüft hat: Diese Dateien verraten, wo sie hereingekommen sind.

Für dein technisches Team

Laufender Kernel: uname -r gegen den installierten (rpm -q kernel, dpkg -l 'linux-image*'). Fixes kommen per Backport ohne sichtbare Versionsänderung: Es zählt die Paketrevision, nicht die Nummer von kernel.org.

Revisionen mit dem Fragnesia-Fix (CVE-2026-46300): Ubuntu 26.04 7.0.0-22.22, 24.04 6.8.0-124.124, 22.04 5.15.0-181.191; AlmaLinux 8 4.18.0-553.124.3.el8_10, 9 5.14.0-611.54.5.el9_7, 10 6.12.0-124.56.3.el10_1. Jede CVE hat ihre eigene: Installiere die neueste deines Zweigs.

Noch nicht auf allen Zweigen geschlossen: Vghost (CVE-2026-74580). Stand 4. November führt Ubuntu sie als behoben auf 26.04 und 22.04 und in Arbeit auf 24.04. Red Hat verortet sie vor allem auf Virtualisierungshosts, und sie setzt Zugriff auf /dev/vhost-* voraus: Bis zum Fix gib das nicht an Container oder nicht vertrauenswürdige Benutzer weiter.