Security 02.05.2026 Aktualisiert: 04.05.2026

Linux Copy Fail (CVE-2026-31431): betroffene Systeme prüfen und patchen

Copy Fail ist eine lokale Kernel-Lücke. Was betroffen ist, wie du Systeme prüfst und welche Maßnahmen jetzt sinnvoll sind.

Stand: 04.05.2026, 02:13 Uhr CEST. Der Stand kann sich noch ändern, weil Distributionen Kernel-Fixes und Zwischenlösungen nachziehen. Entscheidend ist nicht nur, ob ein Paket installiert wurde. Entscheidend ist, ob der laufende Kernel wirklich gefixt ist oder die betroffene Schnittstelle wirksam blockiert wird.

Kurzfassung

Worum es geht: Copy Fail, CVE-2026-31431, ist eine lokale Lücke zur Rechteausweitung im Linux-Kernel. Ein unprivilegierter lokaler Benutzer kann unter passenden Bedingungen Root-Rechte bekommen.
Remote allein ausnutzbar: Nein. Der Angreifer braucht bereits lokale Code-Ausführung, zum Beispiel Shell-Zugriff, eine kompromittierte Webanwendung, einen CI-Job oder Code in einem Container.
Warum das trotzdem kritisch ist: Auf Multi-User-Systemen, Hosting-Servern, CI-Runnern, Container-Nodes und Plesk-/Agenturservern wird aus einem begrenzten Einstieg schnell ein Root-Problem.
Betroffen: Viele Linux-Kernel mit der verwundbaren algif_aead-Logik, die seit 2017 in vielen Kernel-Linien steckt. Der konkrete Status hängt vom Vendor-Kernel und von Backports ab.
Nicht betroffen: Kernel ohne CONFIG_CRYPTO_USER_API_AEAD, Systeme ohne nutzbare AF_ALG-AEAD-Schnittstelle, wirksam mitigierte Hosts und Kernel mit eingespieltem Fix. Bei Containern zählt der Host-Kernel, nicht die Distribution im Image.
Sofortmaßnahme: Vendor-Updates einspielen, danach den Host in einen gefixten Kernel booten. Wenn noch kein Kernel-Fix verfügbar oder ein Reboot nicht sofort möglich ist, algif_aead bzw. AF_ALG nach Vendor-Empfehlung blockieren.
Nicht machen: Den öffentlichen Proof of Concept nicht auf Produktivsystemen laufen lassen. Er verändert zwar nur den Page Cache, öffnet aber real eine Root-Shell.

Was ist Copy Fail?

Der Bug sitzt in algif_aead, also in der AEAD-Socket-Schnittstelle der Kernel Crypto API über AF_ALG. Auslöser ist eine In-Place-Optimierung, die 2017 in den Kernel kam. Über die Kombination aus AF_ALG und splice() kann ein lokaler Prozess kontrolliert vier Bytes in den Page Cache schreiben.

Das ist unangenehm, weil der Page Cache die Kopien von Dateien im Arbeitsspeicher hält. Manipuliert ein Angreifer dort die Speicher-Kopie eines setuid-root-Binaries wie /usr/bin/su und wird dieses Binary danach ausgeführt, kann daraus Root-Zugriff entstehen. Die Datei auf der Platte muss dabei nicht angefasst werden. Klassische Integritätsprüfungen, die nur Dateihashes auf dem Datenträger vergleichen, sehen deshalb nicht zwingend etwas.

Die Lücke ist als CVE-2026-31431 geführt und hat einen CVSS-3.1-Score von 7.8. NVD führt sie außerdem im Kontext des CISA Known Exploited Vulnerabilities Catalogs mit Datum 01.05.2026.

Wichtig für die Einordnung: Das ist keine Remote-Code-Execution von außen. Copy Fail ist aber ein sehr brauchbarer zweiter Schritt nach einem ersten Einstieg. Gefährdet sind deshalb vor allem Systeme, auf denen fremder oder weniger vertrauenswürdiger Code laufen darf.

Für selbst gebaute Kernel, Gentoo-Systeme oder ungewöhnliche Distributionen ist der Upstream-Kontext wichtig: Die verwundbare Optimierung kam über Commit 72548b093ee3 in die Kernel-Linien. Der Hauptfix wird in den Kernel-Referenzen unter anderem mit a664bf3d603d und stabilen Backports geführt. NVD nennt als nicht mehr verwundbare Upstream-Stable-Grenzen unter anderem 5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.22 und 6.19.12. Für Distributionskernel ersetzt diese Liste trotzdem nicht den Vendor-Tracker, weil Backports nicht sauber an der Ausgabe von uname -r erkennbar sind.

Wer ist betroffen?

Eine einfache Regel wie “Kernel neuer als X ist betroffen” reicht hier nicht. Distributionen backporten Kernel-Fixes stark. Maßgeblich ist der Status deines Vendor-Kernels.

Umgebung	Einschätzung	Worauf prüfen
Debian	Debian listet für Bullseye, Bookworm, Trixie, Forky und Sid inzwischen fixe Versionen im Security Tracker.	Installierte und laufende Kernel-Version gegen den Debian Security Tracker prüfen.
Ubuntu	Ubuntu bewertet die Schwachstelle als High und verteilt eine `kmod`-Mitigation, die `algif_aead` blockiert. Viele Kernel-Varianten waren im Ubuntu-Tracker zuletzt noch als vulnerable gelistet; Ubuntu 26.04 wird dort als nicht betroffen geführt.	Ubuntu-CVE-Seite und installierte Kernel-/`kmod`-Version prüfen.
SUSE / openSUSE	SUSE hat am 03.05.2026 Updates für maintained SUSE Linux Enterprise und openSUSE Leap gemeldet. Ältere und nicht gepflegte Varianten müssen gesondert geprüft werden.	SUSE-CVE-Seite und Paketstände prüfen.
RHEL, Rocky, Alma, CloudLinux	Plesk verweist auf OS-Vendor-Fixes. AlmaLinux und CloudLinux nennen konkrete Kernel-Fixes, für Red Hat/Rocky muss der aktuelle Vendor-Status geprüft werden.	`dnf update 'kernel*'`, Vendor-Advisory, anschließend Reboot und `uname -r`.
Plesk-Server	Plesk selbst ist nicht der Kern des Problems. Entscheidend ist das darunterliegende Betriebssystem und dessen Kernel.	OS-Vendor-Updates einspielen, Wartungsfenster für Reboot einplanen.
Proxmox VE Hosts	Wie bei anderen Linux-Hosts zählt der laufende Host-Kernel. LXC-Container teilen sich den Host-Kernel; KVM-VMs haben eigene Guest-Kernel und müssen separat gepatcht werden.	PVE-Kernel-Updates prüfen, Host rebooten, LXC-Workloads besonders priorisieren.
Kubernetes, Docker, CI-Runner	Besonders relevant, wenn nicht vertrauenswürdige Workloads laufen. Container teilen sich den Host-Kernel.	Kernel patchen und zusätzlich `AF_ALG` per seccomp blockieren, wo möglich.
Single-User-Server ohne fremde Shells	Niedrigeres Risiko, aber nicht irrelevant. Ein Web-RCE, gestohlene Zugangsdaten oder ein kompromittierter Dienst können die Lücke lokal nutzen.	Patchen, aber mit normalem Wartungsfenster statt Panikaktion.

Was ist nicht betroffen?

Nicht jedes Linux-System mit einem neuen Datum im Kernel-Paket ist automatisch betroffen. Nicht betroffen oder praktisch entschärft sind vor allem diese Fälle:

Kernel, in denen CONFIG_CRYPTO_USER_API_AEAD nicht aktiviert ist.
Kernel, in denen AF_ALG oder speziell algif_aead nicht nutzbar ist.
Systeme mit einem Kernel, der den Upstream-Fix oder einen Vendor-Backport enthält.
Ubuntu 26.04 nach aktuellem Ubuntu-Tracker-Stand.
Hosts, auf denen algif_aead wirksam blockiert und das Modul nicht geladen ist, bis ein Kernel-Fix eingespielt wurde.
Container-Workloads, bei denen socket(AF_ALG, ...) zuverlässig per seccomp oder vergleichbarer Policy blockiert ist.

Bei Containern ist die Formulierung wichtig: Ein Alpine-, Debian- oder Ubuntu-Container bringt keinen eigenen Kernel mit. Ein schlankes Alpine/musl-Image hat eventuell weniger setuid-root-Binaries und kann einen konkreten PoC erschweren. Einen verwundbaren Host-Kernel macht es aber nicht automatisch sicher. LXC-, Docker- und Kubernetes-Workloads müssen deshalb über den Host und die Runtime-Policy bewertet werden.

Schnelle Prüfung

Zuerst brauchst du den laufenden Kernel. Ein installiertes Paket reicht nicht, wenn der Host noch mit einem alten Kernel läuft.

uname -r
uname -a

Für selbst gebaute Kernel, Gentoo-Systeme oder unveränderte stable.org-Kernel kannst du gegen diese Mindestversionen prüfen. Bei Debian, Ubuntu, RHEL, SUSE, Proxmox und ähnlichen Vendor-Kerneln ist die Tabelle nur Orientierung, weil Fixes zurückportiert werden. Ein Debian-Kernel wie 6.1.0-... ist zum Beispiel nicht automatisch mit einem ungepatchten Upstream-6.1.x gleichzusetzen.

Laufende Kernel-Linie	Nach NVD verwundbarer Bereich	Upstream gefixt ab
4.14 bis 5.9	`>= 4.14` und `< 5.10.254`	kein eigener Fix in diesen alten Linien; auf `5.10.254` oder Vendor-Backport prüfen
5.10 LTS	`< 5.10.254`	`5.10.254`
5.11 bis 5.14	`>= 5.11` und `< 5.15.204`	kein eigener Fix in diesen Zwischenlinien; auf `5.15.204` oder Vendor-Backport prüfen
5.15 LTS	`< 5.15.204`	`5.15.204`
5.16 bis 6.0	`>= 5.16` und `< 6.1.170`	kein eigener Fix in diesen Zwischenlinien; auf `6.1.170` oder Vendor-Backport prüfen
6.1 LTS	`< 6.1.170`	`6.1.170`
6.2 bis 6.5	`>= 6.2` und `< 6.6.137`	kein eigener Fix in diesen Zwischenlinien; auf `6.6.137` oder Vendor-Backport prüfen
6.6 LTS	`< 6.6.137`	`6.6.137`
6.7 bis 6.11	`>= 6.7` und `< 6.12.85`	kein eigener Fix in diesen Zwischenlinien; auf `6.12.85` oder Vendor-Backport prüfen
6.12 LTS	`< 6.12.85`	`6.12.85`
6.13 bis 6.17	`>= 6.13` und `< 6.18.22`	kein eigener Fix in diesen Zwischenlinien; auf `6.18.22` oder Vendor-Backport prüfen
6.18	`< 6.18.22`	`6.18.22`
6.19	`< 6.19.12`	`6.19.12`
7.0 Release Candidates	`7.0-rc1` bis `7.0-rc6`	`7.0` final oder neuer

Auf Debian und Ubuntu:

dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'
dpkg -l kmod | awk '/^ii/ {print $2, $3}'

Falls die Kernel-Konfiguration verfügbar ist, prüfe die AEAD-Schnittstelle für den Userspace:

grep CONFIG_CRYPTO_USER_API_AEAD "/boot/config-$(uname -r)" 2>/dev/null || true
zgrep CONFIG_CRYPTO_USER_API_AEAD /proc/config.gz 2>/dev/null || true

Auf RHEL-kompatiblen Systemen:

rpm -q kernel kernel-core 2>/dev/null
uname -r

Prüfen, ob das Modul aktuell geladen ist:

grep -qE '^algif_aead ' /proc/modules \
  && echo "algif_aead ist geladen" \
  || echo "algif_aead ist nicht geladen"

Prüfen, was modprobe für das Modul tun würde:

modprobe -n -v algif_aead

Wenn du wissen musst, ob Anwendungen AF_ALG aktiv verwenden, kannst du je nach System mit lsof oder ss suchen. Das ist nur ein Hinweis. Die Vendor-Prüfung ersetzt es nicht.

sudo lsof 2>/dev/null | grep AF_ALG || true
ss -xa | grep -i alg || true

Updates und Mitigation

Die saubere Lösung ist ein Kernel-Update aus den Repositories deiner Distribution. Danach muss der Host mit dem gefixten Kernel booten.

Debian und Ubuntu:

sudo apt update
sudo apt upgrade
sudo reboot
uname -r

RHEL, Rocky, AlmaLinux und CloudLinux:

sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo reboot
uname -r

Bei älteren EL-Systemen kann statt dnf noch yum relevant sein.

Geht das ohne Reboot?

Manchmal, aber nicht pauschal. Kernel-Livepatching über Canonical Livepatch, Ksplice, kpatch oder ein vergleichbares Vendor-Angebot kann eine sinnvolle Brücke sein, wenn es für exakt deinen laufenden Kernel einen Livepatch für CVE-2026-31431 gibt. Das muss das Livepatch-Tool bestätigen. uname -r bleibt bei Livepatching normalerweise gleich und beweist deshalb nicht, dass der Fix aktiv ist.

canonical-livepatch status --verbose 2>/dev/null || true
kpatch list 2>/dev/null || true
uptrack-show --available 2>/dev/null || true

Für Hosting-Systeme ist Livepatching praktisch, ersetzt aber nicht automatisch das nächste Wartungsfenster. Spätestens danach sollte der Host in einen regulär gefixten Kernel booten. Dann passen Kernel-Paket, laufender Kernel, Modulstatus und Dokumentation wieder zusammen.

Wenn noch kein Kernel-Fix verfügbar ist oder ein Reboot nicht sofort geht, ist die übliche Zwischenlösung: algif_aead blockieren. Das entspricht auch den Empfehlungen aus mehreren Advisories. Vorher solltest du prüfen, ob in deiner Umgebung Anwendungen explizit AF_ALG verwenden.

printf '%s\n' 'install algif_aead /bin/false' | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo rmmod algif_aead 2>/dev/null || true
modprobe -n -v algif_aead

Falls das Modul bereits verwendet wird, kann rmmod fehlschlagen. Dann bleibt meist nur ein Reboot oder eine Vendor-spezifische Kernel-Boot-Option. Plesk nennt für Red-Hat-nahe Systeme zum Beispiel initcall_blacklist=algif_aead_init per grubby. Solche Maßnahmen solltest du aber nur übernehmen, wenn sie zur jeweiligen Distribution passen.

Für Container- und CI-Umgebungen reicht die Modulfrage allein nicht immer. CERT-EU empfiehlt, die Erzeugung von AF_ALG-Sockets zusätzlich über seccomp-Policies für containerisierte Workloads und Pipelines zu blockieren. Das ist vor allem dort sinnvoll, wo Build-Jobs, Kundencontainer, Plugin-Code oder andere nicht vertrauenswürdige Workloads laufen.

Ein Docker-/Podman-seccomp-Profil ist normalerweise eine vollständige Allowlist. Der folgende Block ist deshalb nur ein Fragment für ein vorhandenes Profil. AF_ALG hat unter Linux den Socket-Family-Wert 38; die Regel blockiert socket(AF_ALG, ...).

{
  "names": ["socket"],
  "action": "SCMP_ACT_ERRNO",
  "args": [
    {
      "index": 0,
      "value": 38,
      "op": "SCMP_CMP_EQ"
    }
  ]
}

Ein Container kann dann mit einem angepassten Profil gestartet werden:

docker run --security-opt seccomp=/path/to/seccomp-no-afalg.json ...
podman run --security-opt seccomp=/path/to/seccomp-no-afalg.json ...

In Kubernetes muss das Profil auf den Nodes liegen und über securityContext.seccompProfile referenziert werden. Für bestehende Cluster ist das ein Policy-Thema, nicht nur ein einzelner kubectl-Befehl.

Einordnung für produktive Systeme

Für produktive Systeme ist Copy Fail vor allem eine Frage der Mandantentrennung.

Auf einem Single-Tenant-Server ohne fremde Shells ist das Risiko geringer als auf einem Kubernetes-Node oder Shared-Hosting-System. Relevant bleibt die Lücke trotzdem. Viele echte Angriffe starten mit einem begrenzten Einstieg: Webshell über eine verwundbare Anwendung, kompromittierter SSH-Key, unsicherer CI-Runner, Plugin-Code oder ein schlecht isolierter Container. Copy Fail kann daraus Root auf dem Host machen.

Bei Plesk- und Agenturservern ist die entscheidende Frage, ob Kunden, Websites, Cronjobs oder Deployment-Prozesse Code unter getrennten Benutzern ausführen. Wenn ja, gehört die Lücke höher priorisiert als auf einem vollständig abgeschotteten Einzelserver.

Bei Proxmox ist die Trennung wichtig:

LXC-Container teilen den Host-Kernel. Ein verwundbarer Host-Kernel ist deshalb ein direkter Schwerpunkt.
KVM-VMs teilen den Host-Kernel nicht. Ein Angreifer in einer VM nutzt zunächst den Guest-Kernel der VM aus, nicht direkt den Proxmox-Host. Die Gäste müssen trotzdem separat gepatcht werden.
Shell-Zugriff auf dem Proxmox-Host, Backup-Scripte, Hooks und Automatisierung sollten als lokale Angriffsfläche betrachtet werden.

Ein Kernel-Update ohne Reboot ist hier nur die halbe Arbeit. Nach dem Update muss klar dokumentiert sein, welcher Kernel läuft, ob die Mitigation noch aktiv ist und ob Container- oder CI-Policies angepasst wurden.

Wie wir damit umgehen

Bei solchen Kernel-Themen prüfen wir nicht blind “apt upgrade und weiter”, sondern arbeiten die tatsächliche Betriebsfrage ab:

Welche Hosts und Gäste laufen mit betroffenen Kernel-Linien?
Gibt es Multi-User-, Hosting-, Container-, Plesk-, Proxmox- oder CI-Workloads?
Sind Vendor-Fixes bereits verfügbar oder ist eine temporäre Mitigation nötig?
Welche Systeme brauchen ein Wartungsfenster, weil ein Reboot unvermeidbar ist?
Ist nach dem Reboot wirklich der gefixte Kernel aktiv?
Müssen seccomp-, AppArmor-, SELinux- oder Container-Policies nachgezogen werden?
Gibt es Monitoring oder EDR-Hinweise, die nach einem Verdacht geprüft werden müssen?

Wenn du nicht sicher bist, ob deine Server betroffen sind, ist ein kurzer technischer Sicherheitscheck sinnvoller als ein hektischer Reboot ohne Fallback. Gerade bei Proxmox, Plesk, Datenbanken und produktiven Kundenprojekten sollte vorher klar sein, wie du zurückkommst, falls ein Kernel-Update Nebenwirkungen hat.

Update-Log

Dieses Log hält den bekannten Disclosure- und Vendor-Verlauf fest.

2026-03-23: Die Schwachstelle wurde an das Linux Kernel Security Team gemeldet.
2026-03-24: Das Kernel Security Team bestätigte den Eingang.
2026-03-25: Patches wurden vorgeschlagen und reviewed.
2026-04-01: Der Upstream-Fix wurde in Mainline committed. Der zentrale Fix nimmt die 2017 eingeführte algif_aead-In-Place-Optimierung zurück.
2026-04-22: CVE-2026-31431 wurde zugewiesen.
2026-04-29: Copy Fail wurde öffentlich disclosed, inklusive Proof of Concept. CERT-EU veröffentlichte die erste Advisory-Version.
2026-04-30: CERT-EU meldete, dass zu diesem Zeitpunkt noch keine Distribution fixe Kernel-Pakete ausgeliefert hatte, und empfahl die temporäre Mitigation. Ubuntu veröffentlichte am selben Tag Vendor-Hinweise und kmod-Mitigationen für betroffene Releases vor 26.04.
2026-05-01: CISA nahm CVE-2026-31431 in den Known Exploited Vulnerabilities Catalog auf. AlmaLinux veröffentlichte laut Plesk-Hinweis Kernel-Fixes für betroffene AlmaLinux-Zweige.
2026-05-02: Plesk aktualisierte die eigene Handlungsempfehlung und verweist auf OS-Vendor-Fixes, KernelCare-Prüfung, CloudLinux-, AlmaLinux-, Red-Hat-, Ubuntu- und Debian-Pfade.
2026-05-03: SUSE meldete Updates für alle gepflegten SUSE Linux Enterprise- und openSUSE-Leap-Distributionen.
2026-05-04: Debian listet im Security Tracker fixe Versionen für Bullseye Security, Bookworm Security, Trixie Security, Forky und Sid. Für produktive Systeme zählt trotzdem der laufende Kernel nach Reboot oder Livepatch-Prüfung.