CVE-2026-31431 «Copy Fail»: Linux-Kernel-Schwachstelle

Zusammenfassung

Eine Schwachstelle mit hoher Auswirkung zur lokalen Privilegieneskalation im Linux-Kernel, CVE-2026-31431, auch bekannt als «Copy Fail», wurde öffentlich bekannt gemacht.

Die Schwachstelle betrifft die kryptografische Schnittstelle des Linux-Kernels, konkret den Pfad algif_aead / AF_ALG. Unter betroffenen Kernel-Versionen kann ein lokaler, nicht privilegierter Benutzer seine Rechte auf root ausweiten. Die ursprünglichen Forscher beschreiben das Problem als relevant für gängige Linux-Distributionen mit Kerneln, die seit 2017 gebaut wurden, mit besonderem Risiko für Mehrbenutzer-Server, Container-Plattformen, CI/CD-Runner und mandantenfähige Umgebungen.

Das Problem wird als CVE-2026-31431 geführt. Ubuntu bewertet es als High mit CVSS 7.8, Red Hat stuft die Auswirkung als Important ein.

EuroVPS empfiehlt dringend, alle betroffenen Linux-Server zu prüfen und zu patchen, sobald vom Hersteller gepatchte Kernel oder Gegenmaßnahmen verfügbar sind.

---

Was ist CVE-2026-31431?

CVE-2026-31431 ist eine Schwachstelle des Linux-Kernels im Crypto-Subsystem. Der Fehler hängt mit einer fehlerhaften In-Place-Operation in algif_aead zusammen, bei der sich Quell- und Ziel-Mappings unterscheiden. Die Upstream-Korrektur des Kernels ist mit dem Mainline-Commit a664bf3d603d verbunden, der die problematische Optimierung von 2017 zurücknimmt.

Die Schwachstelle ist für sich genommen keine aus der Ferne ausnutzbare Netzwerkschwachstelle. Hat ein Angreifer jedoch bereits lokalen Shell-Zugang, Zugriff über eine kompromittierte Webanwendung, Codeausführung in einem Container oder einen anderen Einstiegspunkt, kann die Schwachstelle eine Ausweitung auf volle Root-Rechte ermöglichen.

---

Betroffene Betriebssysteme und Korrekturen / Patches der Hersteller

Die Schwachstelle kann viele Linux-Distributionen mit Kerneln betreffen, die seit 2017 gebaut wurden. Der Stand unterscheidet sich je nach Distribution und Kernel-Stream, deshalb ist der richtige Weg, dem offiziellen Hersteller-Advisory für Ihr Betriebssystem zu folgen.

1. AlmaLinux

AlmaLinux hat gepatchte Kernel für die unterstützten Versionen veröffentlicht. Die bestätigten gepatchten Versionen sind:

Betriebssystem	Gepatchte Kernel-Version
AlmaLinux 8	kernel-4.18.0-553.121.1.el8_10 oder neuer
AlmaLinux 9	kernel-5.14.0-611.49.2.el9_7 oder neuer
AlmaLinux 10	kernel-6.12.0-124.52.2.el10_1 oder neuer
AlmaLinux Kitten 10	kernel-6.12.0-225.el10 oder neuer

Empfohlenes Update:

sudo dnf clean all
sudo dnf upgrade 'kernel*'
sudo reboot

Prüfung nach dem Neustart:

uname -r
rpm -q kernel

2. Oracle Linux

Oracle Linux ist ebenfalls betroffen, wenn verwundbare Builds des Linux-Kernels laufen. Oracle hat Sicherheitsupdates für den Unbreakable Enterprise Kernel (UEK) zu CVE-2026-31431 über offizielle Oracle-Linux-Errata veröffentlicht.

Oracle-Linux-Version / Kernel-Stream	Korrigierter Kernel / Patch-Stand
Oracle Linux 7 / 8, UEK R6	kernel-uek-5.4.17-2136.354.4.2.el7uek / el8uek oder neuer
Oracle Linux 8 / 9, UEK R7	kernel-uek-5.15.0-319.201.4.4.el8uek / el9uek oder neuer
Oracle Linux 9 / 10, UEK R8	kernel-uek-6.12.0-201.74.2.2.el9uek / el10uek oder neuer

Oracle führt die UEK-Updates als SECURITY, IMPORTANT, veröffentlicht am 2026-05-01, und nennt CVE-2026-31431 unter den Crypto-Korrekturen des Kernels.

Empfohlenes Update:

sudo dnf clean all
sudo dnf update 'kernel*'
sudo reboot

Für ältere Oracle-Linux-Systeme mit yum:

yum clean all
yum update 'kernel*'
reboot

Prüfung unter Oracle Linux

cat /etc/oracle-release
uname -r
rpm -q kernel-uek
rpm -q kernel kernel-core

Stellen Sie sicher, dass der laufende Kernel, wie ihn uname -r anzeigt, der gepatchte Kernel ist und nicht nur installiert wurde.

3. CloudLinux

CloudLinux bestätigt, dass CL7 nicht betroffen ist, während CL7h, CL8, CL9 und CL10 betroffen sind. CL7h und CL8 werden über CloudLinux-Kernel gepatcht, CL9 und CL10 nutzen die Kernel-Updates von AlmaLinux.

Die bestätigten Zielversionen von CloudLinux umfassen:

Betriebssystem	Gepatchte Kernel-Version
CloudLinux 7	Nicht betroffen
CloudLinux 7 Hybrid / CL7h	kernel-4.18.0-553.121.1.lve.el7h.x86_64 oder neuer
CloudLinux 8	kernel-4.18.0-553.121.1.lve.el8.x86_64 oder neuer
CloudLinux 9	kernel-5.14.0-611.49.2.el9_7 oder neuer
CloudLinux 10	kernel-6.12.0-124.52.2.el10_1 oder neuer

Empfohlenes Update für CloudLinux 8 / 9 / 10:

sudo dnf clean metadata
sudo dnf upgrade 'kernel*'
sudo reboot

Für ältere CloudLinux-Systeme mit yum:

yum update 'kernel*'
reboot

Prüfung:

uname -r
rpm -q kernel

Für Systeme mit KernelCare:

kcarectl --update
kcarectl --info | grep CVE-2026-31431

CloudLinux gibt an, dass KernelCare-Live-Patches für viele betroffene Distributionen, darunter die Streams AlmaLinux, CloudLinux, Red Hat, Rocky, Oracle Linux, Ubuntu und Debian, seit dem 2. Mai 2026 im Haupt-Feed veröffentlicht sind.

---

4. Ubuntu

Ubuntu hat sowohl einen Eintrag im CVE-Tracker als auch einen eigenen Blogbeitrag zu diesem Thema veröffentlicht. Ubuntu gibt an, dass die Gegenmaßnahme über das Paket kmod verteilt wird und die eigentliche Korrektur der Schwachstelle über die Linux-Kernel-Image-Pakete ausgeliefert wird.

Empfohlenes Update:

sudo apt update
sudo apt upgrade
sudo reboot

Um nur das Paket mit der Gegenmaßnahme einzuspielen, wo anwendbar:

sudo apt update
sudo apt install --only-upgrade kmod
sudo reboot

Prüfung:

uname -r
dpkg -l 'linux-image*' | grep ^ii
dpkg -l kmod

Um zu prüfen, ob das betroffene Modul derzeit geladen ist:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Ubuntu dokumentiert außerdem eine manuelle Gegenmaßnahme über eine modprobe.d-Regel und das Entladen von algif_aead; dieser Ansatz eignet sich jedoch nicht für alle Distributionen, insbesondere nicht für Systeme der RHEL-Familie, bei denen die Funktion fest in den Kernel eingebaut sein kann.

---

5. Debian

Der Security-Tracker von Debian nennt korrigierte Versionen für mehrere Debian-Releases:

Debian-Release	Korrigierte Version
Bullseye security	5.10.251-3
Bookworm security	6.1.170-1
Trixie security	6.12.85-1
Forky	6.19.14-1
Sid	7.0.3-1

Empfohlenes Update:

sudo apt update
sudo apt upgrade
sudo reboot

Prüfung:

uname -r
dpkg -l 'linux-image*' | grep ^ii

---

6. Red Hat Enterprise Linux

Red Hat hat ein Security Bulletin und eine CVE-Seite zu CVE-2026-31431 veröffentlicht. Red Hat beschreibt es als Problem der kryptografischen Schnittstelle des Linux-Kernels, bei dem ein lokaler Benutzer Root-Rechte erlangen kann. Red Hat stuft das Problem als Important ein und gibt an, dass die Korrekturen über die entsprechenden Red-Hat-Kanäle ausgeliefert werden.

Empfohlene Maßnahme:

sudo dnf update 'kernel*'
sudo reboot

Prüfung:

uname -r
rpm -q kernel
rpm -q kernel-core

Für Systeme mit Red-Hat-Subscription prüfen Sie zusätzlich die offizielle CVE-Seite und die Advisories von Red Hat für das exakte korrigierte Paket Ihrer RHEL-Version und Ihres Kernel-Streams.

---

7. SUSE

SUSE bewertet CVE-2026-31431 als important und verfolgt den Stand je Produkt und Paket. Einige Pakete für SUSE 15 SP7 sind als veröffentlicht markiert, während mehrere Streams von SUSE 16 und SUSE Linux Micro zum Zeitpunkt der Prüfung auf der SUSE-CVE-Seite noch als betroffen oder in Arbeit geführt wurden.

Empfohlene Maßnahme:

sudo zypper refresh
sudo zypper update
sudo reboot

Prüfung:

uname -r
rpm -q kernel-default

Prüfen Sie die SUSE-CVE-Seite für den genauen Paketstand Ihres Produkts, Ihres Service Packs und Ihrer Kernel-Variante.

---

Vorübergehende Gegenmaßnahme, wenn Sie nicht sofort aktualisieren können

Für Systeme mit Oracle Linux / AlmaLinux / CloudLinux / RHEL-Familie

Für Systeme der RHEL-Familie ist die sicherere vorübergehende Gegenmaßnahme, den Initcall algif_aead_init über die Kernel-Kommandozeile zu sperren und neu zu starten:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Prüfung nach dem Neustart:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

oder:

sudo grubby --info=ALL | grep initcall_blacklist

CloudLinux warnt ausdrücklich, dass die übliche modprobe.d-Gegenmaßnahme auf CloudLinux, AlmaLinux oder anderen Systemen der RHEL-Familie möglicherweise nicht wirkt, weil algif_aead fest in den Kernel eingebaut sein kann. In diesem Fall können rmmod und modprobe.d-Regeln ein falsches Gefühl von Sicherheit vermitteln.

Nach der Installation eines gepatchten Kernels können Sie die vorübergehende Gegenmaßnahme wieder entfernen:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

---

Für Systeme mit Ubuntu / Debian

Ubuntu dokumentiert die folgende Gegenmaßnahme, wo anwendbar:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null

Prüfung:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Ein Neustart kann erforderlich sein, wenn sich das Modul nicht sicher entladen lässt.

---

Härtung (Hardening) für Container und Kubernetes

In Container-Umgebungen bleibt das Patchen des Host-Kernels die primäre Korrektur. Zusätzliche Eindämmung wird jedoch dringend empfohlen.

CERT-EU empfiehlt, das Erstellen von AF_ALG-Sockets über seccomp-Richtlinien für Container-Workloads und CI/CD-Pipelines zu blockieren. Docker dokumentiert seccomp als Funktion des Linux-Kernels, mit der die Aktionen von Containern eingeschränkt werden, und das Standard-seccomp-Profil von Docker arbeitet nach einem Allowlist-Modell.

seccomp-Prüfung unter Docker:

grep CONFIG_SECCOMP= /boot/config-$(uname -r)

Erwartet:

CONFIG_SECCOMP=y

Starten Sie Container mit dem Standard-seccomp-Profil, sofern es keinen konkreten Grund dagegen gibt:

docker run --security-opt seccomp=default.json ...

Unter Kubernetes verwenden Sie RuntimeDefault oder, wo angebracht, ein eigenes seccomp-Profil. Kubernetes unterstützt das Anwenden von seccomp-Profilen auf Pods und Container, und die Kubernetes-Dokumentation beschreibt das Laden und Anwenden von Profilen.

Beispiel für einen Security Context in Kubernetes:

securityContext:
  seccompProfile:
    type: RuntimeDefault

---

Zusätzlicher Schritt für Server mit LiteSpeed Enterprise

Für Server mit LiteSpeed Enterprise, insbesondere in Hosting-Umgebungen mit CloudLinux / CageFS, empfiehlt EuroVPS den folgenden zusätzlichen Hardening-Schritt für LiteSpeed.

Dies ist eine zusätzliche Härtung für Server mit dem lscgid-Binary von LiteSpeed. Das Kernel-Update oder die Gegenmaßnahme oben bleiben weiterhin erforderlich.

LiteSpeed 6.3.5 wird von LiteSpeed als Security-, Tuning- und Bugfix-Release geführt, einschließlich Änderungen rund um CloudLinux CageFS. Die Dokumentation von LiteSpeed zeigt zudem, dass lscgid im normalen LiteSpeed/PHP-Betrieb seit jeher das setuid-Recht verwendet.

Schritt 2: Härtung des Binarys lscgid

Prüfen Sie zunächst, ob LiteSpeed installiert ist:

/usr/local/lsws/bin/lshttpd -v

Wählen Sie dann eine der folgenden Optionen.

Option A: Upgrade auf LiteSpeed Enterprise 6.3.5 Build 5 oder neuer (empfohlen)

Dies ist die bevorzugte Option. Das LiteSpeed-Upgrade übernimmt die erforderliche Härtung der lscgid-Rechte automatisch:

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.5

Starten Sie LiteSpeed nach dem Upgrade bei Bedarf neu:

/usr/local/lsws/bin/lswsctrl restart

Option B: Schnelle Abhilfe, wenn Sie noch nicht upgraden können

Wenn Sie LiteSpeed nicht sofort aktualisieren können, entfernen Sie das setuid-Recht jetzt manuell vom lscgid-Binary:

chmod u-s /usr/local/lsws/bin/lscgid.*

Starten Sie LiteSpeed anschließend neu:

/usr/local/lsws/bin/lswsctrl restart

Prüfliste zur Verifizierung

Führen Sie die folgenden Prüfungen aus, nachdem Sie Updates oder Gegenmaßnahmen angewendet haben.

1. Betriebssystem und Kernel ermitteln

cat /etc/os-release
uname -r

2. Installierte Kernel-Pakete prüfen

RPM-basierte Systeme:

rpm -q kernel
rpm -q kernel-core

Debian/Ubuntu-Systeme:

dpkg -l 'linux-image*' | grep ^ii

3. Bestätigen, dass der laufende Kernel der gepatchte Kernel ist

Nach dem Neustart:

uname -r

Vergleichen Sie die Version des laufenden Kernels mit der offiziellen, vom Hersteller gepatchten Version für Ihr Betriebssystem.

4. Bestätigen, dass die Gegenmaßnahme aktiv ist, falls verwendet

Für Systeme der RHEL-Familie mit grubby-Gegenmaßnahme:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

Für die Modul-Gegenmaßnahme unter Ubuntu/Debian:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

5. KernelCare-Prüfung

kcarectl --update
kcarectl --info | grep CVE-2026-31431

Die CVE sollte in der KernelCare-Ausgabe als gepatcht erscheinen, wo ein Live-Patch verfügbar ist.

---

Wichtige betriebliche Hinweise

Führen Sie keinen öffentlichen Proof-of-Concept-Exploit-Code auf Produktionsservern aus.

---

Empfohlener Maßnahmenplan von EuroVPS

EuroVPS empfiehlt den folgenden Maßnahmenplan:

1. Über Patch und Neustart hinaus: Wenden Sie seccomp-Richtlinien auf Container-Workloads an, nehmen Sie Betriebssysteme am Ende ihres Lebenszyklus außer Betrieb, und führen Sie auf LiteSpeed Enterprise ein Upgrade auf 6.3.5 Build 5 durch oder entfernen Sie das setuid-Bit von lscgid.

Brauchen Sie Unterstützung?

Wenn unsere Ingenieure Ihren Server prüfen, patchen, absichern und verifizieren sollen, eröffnen Sie ein Support-Ticket im Kundenbereich mit Hostname oder IP. Geben Sie Root-Zugang ausschließlich über das sichere Zugangsdatenfeld des Tickets weiter, niemals im Ticket-Text.

Offizielle Hersteller-Links und Referenzen:

[1] Offizielle Offenlegung zu Copy Fail: https://copy.fail/ [2] Ubuntu CVE-Tracker, CVE-2026-31431: https://ubuntu.com/security/CVE-2026-31431 [3] Ubuntu-Blog, Korrekturen für die Copy-Fail-Schwachstelle verfügbar: https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available [4] AlmaLinux-Advisory, CVE-2026-31431 Copy Fail: https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ [5] CloudLinux-Blog, Kernel-Update zu CVE-2026-31431 Copy Fail: https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update [6] CloudLinux Incident-/Statusseite: https://cloudlinux.statuspage.io/incidents/642sgcmntkkk [7] Red Hat CVE-Seite, CVE-2026-31431: https://access.redhat.com/security/cve/CVE-2026-31431 [8] Red Hat Security Bulletin: https://access.redhat.com/security/vulnerabilities/RHSB-2026-02 [9] SUSE CVE-Seite, CVE-2026-31431: https://www.suse.com/security/cve/CVE-2026-31431 [10] Debian Security-Tracker, CVE-2026-31431: https://security-tracker.debian.org/tracker/CVE-2026-31431 [11] Docker-Dokumentation zu seccomp: https://docs.docker.com/engine/security/seccomp/ [12] Kubernetes-Dokumentation zu seccomp: https://kubernetes.io/docs/tutorials/security/seccomp/ [13] Oracle Linux 7 / 8, UEK R6: https://linux.oracle.com/errata/ELSA-2026-50255.html [14] Oracle Linux 8 / 9, UEK R7: https://linux.oracle.com/errata/ELSA-2026-50253.html [15] Oracle Linux 9 / 10, UEK R8: https://linux.oracle.com/errata/ELSA-2026-50254.html