Security 02.05.2026 Aktualisiert: 18.05.2026

Copy Fail CVE-2026-31431: Linux, Proxmox, Plesk & SUSE prüfen

Copy Fail betrifft Linux-Kernel und ist für Proxmox-, Plesk- und Hosting-Server relevant. Prüfe Kernel, Distributionen, Mitigation und Reboot-Status.

Stand: 18.05.2026, 15:52 Uhr CEST. Für die meisten großen Distributionen gibt es inzwischen Kernel-Fixes, Mitigationspakete oder Livepatch-Pfade. Entscheidend ist trotzdem 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.

Copy Fail ist nicht der einzige Bug dieser Klasse aus dem Jahr 2026. Im Mai folgten Dirty Frag (CVE-2026-43284 und CVE-2026-43500) und Fragnesia (CVE-2026-46300) als verwandte Page-Cache-Write-Lücken im XFRM-/ESP-Bereich des Kernels. Alle drei Lücken nutzen denselben Grundmechanismus, aber unterschiedliche Kernel-Pfade und brauchen getrennte Fixes. Die Copy-Fail-Mitigation – algif_aead blockieren – schützt nicht gegen Dirty Frag oder Fragnesia. Mit ssh-keysign-pwn (CVE-2026-46333) kam Mitte Mai eine vierte Lücke dazu: kein Page-Cache-Write, aber ein ptrace-Pfad, über den ein lokaler Prozess root-eigene Dateien wie SSH-Host-Keys und /etc/shadow lesen kann.

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 Security, Bookworm, Trixie, Forky und Sid 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. 26.04 ist laut Canonical nicht betroffen; ältere LTS- und Cloud-Flavours müssen gegen die Ubuntu-CVE-Seite geprüft werden.	Ubuntu-CVE-Seite, installierte Kernelpakete und `kmod`-Version prüfen.
SUSE / openSUSE	SUSE führt CVE-2026-31431 als resolved/important und hat zahlreiche SUSE-SU-Updates für gepflegte Produkte veröffentlicht.	SUSE-CVE-Seite und produktgenaue Paketstände prüfen.
RHEL / OpenShift	Red Hat führt Copy Fail in RHSB-2026-002 inzwischen als resolved; Fixes sind laut Bulletin verfügbar.	Red-Hat-CVE-Seite, Errata, laufenden Kernel und OpenShift-Node-Updates prüfen.
Rocky, Alma, CloudLinux	Rocky, AlmaLinux und CloudLinux nennen konkrete Mindestkernel. Auf EL-Systemen ist `algif_aead` häufig fest einkompiliert; die `modprobe.d`-Mitigation ist dort nicht ausreichend.	`dnf update 'kernel*'`, Vendor-Advisory, anschließend Reboot und `uname -r`.
Amazon Linux / Bottlerocket	AWS nennt Copy Fail in seinem Sammelbulletin als gepatcht für Amazon Linux; Bottlerocket-, ECS- und EKS-Pfade hängen vom jeweiligen Service-Image ab.	AWS Security Bulletin 2026-030, ALAS-Track, AMI-/Node-Image-Version prüfen.
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	Proxmox führt Copy Fail in PSA-2026-00018-1. LXC-Container teilen sich den Host-Kernel; KVM-VMs haben eigene Guest-Kernel und müssen separat gepatcht werden.	PVE-Fixstände und `pve-container` 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.

Patchstände nach Distribution

Die folgende Tabelle ist eine Momentaufnahme. Bei Enterprise-Kerneln zählt immer der Vendor-Backport, nicht die optische Upstream-Version aus uname -r.

Distribution / Plattform	Stand 18.05.2026
Debian	Fix laut Tracker: Bullseye Security ab `5.10.251-5`, `linux-6.1` für Bullseye ab `6.1.172-1~deb11u1`, Bookworm ab `6.1.170-3`, Bookworm Security ab `6.1.172-1`, Trixie ab `6.12.86-1`, Trixie Security ab `6.12.88-1`, Forky/Sid ab `7.0.7-1`.
Ubuntu	Canonical-Blog: 14.04/16.04 nur bestimmte neuere Kernel-Linien betroffen, 18.04 bis 25.10 betroffen, 26.04 nicht betroffen. Mitigation über `kmod`; Kernel-Fix pro Flavour über die Ubuntu-CVE-Seite prüfen.
RHEL 8/9/10 und OpenShift	Red Hat RHSB-2026-002: resolved, Important, Fixes verfügbar. Für die Mitigation nennt Red Hat `initcall_blacklist=algif_aead_init` oder als härtere Variante `initcall_blacklist=af_alg_init`.
AlmaLinux 8/9/10	Production-Fixes: AL8 ab `kernel-4.18.0-553.121.1.el8_10`, AL9 ab `kernel-5.14.0-611.49.2.el9_7`, AL10 ab `kernel-6.12.0-124.52.2.el10_1`, Kitten 10 ab `kernel-6.12.0-225.el10`.
Rocky Linux 8/9/10	Rocky meldet Patches für 8.10 ab `kernel-4.18.0-553.123.1.el8_10`, 9.7 ab `kernel-5.14.0-611.54.1.el9_7`, 10.1 ab `kernel-6.12.0-124.55.1.el10_1`. Nur die neuesten Minor-Releases werden gepatcht.
CloudLinux	CL7 nicht betroffen. CL7h/CL8 ab `kernel-4.18.0-553.121.1.lve...`; CL9/CL10 folgen AlmaLinux-Kernelständen. KernelCare-Livepatches sind für viele EL-, Debian-, Ubuntu- und Proxmox-7-Kernel verfügbar, müssen aber per `kcarectl` nachgewiesen werden.
SUSE / openSUSE	SUSE-CVE-Seite: overall state resolved, CVSS 3.1 7.8, viele SUSE-SU- und ESSA-Advisories seit Anfang Mai. Produkt- und Service-Pack-Tabelle prüfen.
Amazon Linux / AWS	AWS Security Bulletin 2026-030 meldet verfügbare Updates für Amazon Linux-Kerneltracks 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 und 6.18. Bottlerocket, ECS, EKS, EMR, Fargate und SageMaker haben eigene Rollout-Termine oder Image-Wechsel.
Plesk	Plesk hat die KB am 15.05.2026 aktualisiert und verweist auf OS-Vendor-Fixes, KernelCare, `kmod` bei Ubuntu und `grubby`/Kernel-Update bei EL-Systemen. Plesk selbst patcht den Kernel nicht.
Proxmox VE	PSA-2026-00018-1: `proxmox-kernel-7.0.0-*-pve` ist für Copy Fail laut Proxmox nicht betroffen. Gefixt sind `6.17.13-6-pve`, `6.14.11-7-pve`, `6.14.11-7-bpo12-pve` und `6.8.12-22-pve` oder neuer. Zusätzlich `pve-container >= 6.1.5` für PVE 9.x bzw. `>= 5.3.5` für PVE 8.x, weil neue LXC-Starts AF_ALG per seccomp blockieren.

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 AF_ALG/algif_aead wirksam nach Vendor-Anweisung blockiert ist, bis ein Kernel-Fix eingespielt wurde. Auf EL-Systemen ist das oft keine modprobe.d-Regel, weil algif_aead dort fest einkompiliert sein kann.
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
kcarectl --patch-info 2>/dev/null | grep -Ei 'CVE-2026-31431|algif_aead|copy.?fail' || 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 Zwischenlösung: algif_aead oder gleich AF_ALG nach Vendor-Anweisung blockieren. Vorher solltest du prüfen, ob in deiner Umgebung Anwendungen explizit AF_ALG verwenden.

Auf Ubuntu ist die saubere Zwischenlösung das aktualisierte kmod-Paket. Wenn du sie manuell nachbauen musst, entspricht das einer modprobe.d-Regel:

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

Auf RHEL-, Rocky-, AlmaLinux- und CloudLinux-nahen Systemen ist algif_aead häufig fest einkompiliert. Dann sieht modinfo algif_aead als Dateiname nur (builtin), und install algif_aead /bin/false blockiert nichts. Red Hat, CloudLinux und Plesk verweisen hier auf Kernel-Boot-Argumente. Die engere Variante blockiert nur die betroffene AEAD-Initialisierung:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot
grep -o 'initcall_blacklist=[^ ]*' /proc/cmdline

Die breitere Variante blockiert die gesamte AF_ALG-Schnittstelle und kann mehr Anwendungen treffen:

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

Zurücknehmen nach gepatchtem Kernel:

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

Falls das Modul bereits verwendet wird, kann rmmod fehlschlagen. Dann bleibt meist nur ein Reboot oder eine Vendor-spezifische Kernel-Boot-Option. Solche Maßnahmen solltest du 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 gleichzeitig Dirty Frag, Fragnesia und ssh-keysign-pwn im Blick hast, lohnt es sich, alle Lücken im selben Wartungsfenster abzuarbeiten und den Patch-Stand gemeinsam zu dokumentieren.

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.
2026-05-18: Vendor-Stand aktualisiert: Red Hat RHSB-2026-002 steht auf resolved, Rocky nennt konkrete Kernelstände, AWS meldet Amazon-Linux-Updates im Sammelbulletin, Plesk-KB ist vom 15.05.2026. Proxmox-Stand aus PSA-2026-00018-1 ergänzt, inklusive pve-container-Seccomp-Hinweis. Mitigation für EL-Systeme korrigiert: algif_aead ist dort häufig built-in, daher reicht modprobe.d nicht.