Nachdem letzte Woche die copy.fail Sicherheitslücke (CVE-2026-31431 https://copy.fail) für Aufregung sorgte, wurde gestern abend schon wieder eine vergleichbar gefährliche Local Privilege Escalation mit dem Spitznamen „Dirty Frag“ (noch ohne CVE) veröffentlicht. Leider gibt es im Moment (Stand 08.05.2026 08:30 Uhr) noch sehr wenige Patches für populäre Linux Distributionen. u.a. Alma Linux hat bereits neue Pakete veröffentlicht: https://almalinux.org/blog/2026-05-07-dirty-frag/

In der Beschreibung der Sicherheitslücke https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md wird empfohlen, bis zu einem Patch die betroffenen Kernel-Module zu deaktivieren. Inwieweit das möglich ist, müssen Admins für ihre Systeme im Einzelfall entscheiden.

Für beide Schwachstellen gelten ähnliche Empfehlungen:

Potentiell betroffen sind alle Linux Systeme der letzten 9 Jahre auf denen normale Benutzerkonten Code ausführen können. Besonders betroffen sind daher Terminal-/MultiUser-Server, Container-Umgebungen (die Nutzer können auf diesem Weg ggf. auch aus dem Container ausbrechen), Build Pipelines und Webhosting Server (z.B. mit exec() Zugriff oder aktiviertem PHP FFI).

Was nun zu tun ist:

1. Patches installieren wenn verfügbar
   Für die Copy.Fail Schwachstelle haben bereits viele Linux-Distributionen Patches bereitgestellt. Für die Dirty Frag Schwachstelle, wird dies in den nächsten Tagen erwartet.
   Reboot nicht vergessen!
2. Mitigations ausführen – betroffene Kernelmodule deaktivieren
   Sofern die betroffenen Funktionen im Kernel per Modul nachgeladen werden und für den Betrieb des konkreten Systems nicht unbedingt benötigt sind, kann dies bis zur Installation des Patches unterbunden werden:

   Copy.fail:
   > echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
   > rmmod algif_aead

   Dirty Frag:
   > sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
   >rmmod esp4 esp6 rxrpc"
   

   Eventuell können die betroffenen Module auch vollständig gelöscht/deinstalliert werden. Auch dies ist aber eine Einzelfalentscheidung der Admins.

3.  

   Zugriff sperren
   Wenn Patches für Ihr Linux-System (noch) nicht zur Verfügung stehen und die Deaktivierung der betroffenen Kernelmodule keine Option ist, empfehlen wir dringend, den Systemzugriff bzw. das Ausführen von eigenem Code für alle unprivilegierten Nutzerkonten zu unterbinden – auch wenn dies mit vorübergehenden Betriebseinschränkungen verbunden ist.

Gemeinsam mit dem Infosec-Team beobachten wir die Situation weiter und aktualisieren ggf. diese Meldung.