CVE-2026-31431 "Copy Fail" — warum der Kernel zählt

TL;DR — die 90-Sekunden-Zusammenfassung

Betroffen?

Linux-Kernel 5.10 LTS bis 6.6 LTS in praktisch allen Mainstream-Distributionen — Debian, Ubuntu, RHEL, SUSE, Amazon Linux. Auch alle Container-Hosts, unabhängig von der Container-Distribution.

Risiko?

Lokale Privileg-Eskalation bis Root über das AF_ALG-Crypto-Subsystem. Public-PoC verfügbar, trivial reproduzierbar.

Sofortmaßnahme?

Wo Kernel-Patch noch nicht eingespielt: algif_aead via modprobe-Blacklist deaktivieren und crypto_user-Zugang restriktieren. Anschließend PoC gegenprüfen.

Empfehlung?

Mittelstand: Distribution-Patch einspielen, Reboot planen. Enterprise/Kubernetes: zusätzlich Detection-Hooks (eBPF/Tetragon) auf Crypto-User-Syscalls scharfschalten.

Kritikalität?

Hoch (siehe Badge im Seitenkopf).

 

CVE-2026-31431 ist eine reine Kernel-Schwachstelle. Sie sitzt im Crypto-Subsystem des Linux-Kernels, konkret im AF_ALG-Interface und in der Verarbeitung bestimmter Speicheroperationen rund um algif_aead. Der Public-Proof-of-Concept passt auf eine A4-Seite und benötigt keine seltenen Voraussetzungen. Er nutzt Standard-Kernel-Funktionalität, die in praktisch jedem Linux-System aktiv ist, und wirkt distributionsübergreifend.

Die ausführliche technische Aufarbeitung liegt unter copy.fail. Wichtig für die Einordnung: Es handelt sich um eine lokale Privileg-Eskalation. Ein Angreifer benötigt zunächst Code-Ausführung als unprivilegierter Nutzer auf dem Host. Sobald das gegeben ist, eskaliert der Exploit zuverlässig zu Root.

Ein häufiger Denkfehler lautet: „Wenn der Container sicher ist, ist das System sicher.“ Das stimmt für viele Klassen von Schwachstellen. Für Kernel-Lücken stimmt es nicht. Container, egal ob auf Debian-, Alpine- oder Wolfi-Basis, bringen keinen eigenen Kernel mit. Sie nutzen den Kernel des Host-Systems. Sobald ein Prozess innerhalb des Containers den Kernel adressiert und dort eskaliert, ist die Isolation umgangen.

Wer ist betroffen?

Die Schwachstelle wirkt distributionsübergreifend. Entscheidend ist nicht das Userland, sondern der Kernel des Hosts. Container-Images von Debian, Alpine, Ubuntu oder Wolfi sind gleichermaßen betroffen, weil keine davon einen eigenen Kernel mitbringt.

Besonders kritisch ist die Lücke dort, wo viele Workloads sich denselben Kernel teilen: Container-Hosts mit Multi-Tenant-Setup, selbst betriebene Kubernetes-Worker und CI/CD-Runner. Für genau diese Klasse von Risiken planen wir KI-Security-Audits in jeden Release ein.

Kubernetes Blast-Radius-Matrix

In Kubernetes ist die operative Frage nicht „ist der Kernel verwundbar“, sondern „wie weit reicht eine Korruption innerhalb des Clusters“. Der Page-Cache ist nicht namespaced, also node-weit geteilt, und Container-Image-Layer werden auf Node-Ebene nur einmal abgelegt (containerd plus overlayfs). Wer dasselbe Base-Image fährt wie der kompromittierte Pod, liest dieselben vergifteten Pages. Der Host-Node selbst bleibt außen vor, weil Page-Cache-Einträge per (filesystem device, inode number) gekeyed sind und Host- und Container-Files auf getrennten Filesystems liegen.

Der kritische Fall ist nicht hypothetisch. Ein PoC zielt explizit auf kube-proxy als DaemonSet — privileged, hostNetwork, auf jedem Node — und nutzt das geteilte Base-Image, um über /usr/sbin/ipset Node-level Code-Execution zu erreichen.

Auswirkungen

Copy Fail ist eine lokale Privileg-Eskalation (LPE). Die CVSS-Bewertung liegt nach NVD-Vorab-Score im hohen Bereich (7.8 Local Attack Vector, niedrige Komplexität, keine User-Interaction). RCE oder Remote-Eskalation sind nicht direkt möglich, der Exploit setzt eine bestehende Code-Ausführung im User-Space voraus.

Was das in der Praxis bedeutet:

• Container-Escape effektiv möglich. Jeder kompromittierte Pod auf einem ungepatchten Host kann root auf der Node erlangen. Damit ist die gesamte Worker-Node und mittelbar das Cluster offen.
• CI/CD-Runner als Hochrisiko-Ziel. Self-hosted GitHub-Runner, GitLab-Runner und Jenkins-Agents führen regelmäßig nicht vertrauenswürdigen Code aus. Eine kompromittierte Pipeline reicht — wir haben an anderer Stelle ausführlich beschrieben, warum die CI-Pipeline der größte Verdichtungspunkt für Eskalationen im Stack ist.
• Shared-Hosting und Multi-Tenant-VPS. Klassischer Eintrittspunkt für Cross-Tenant-Eskalation.
• Compliance-Folgen. Wer unter ISO 27001 oder NIS-2 betrieben wird, hat eine Vorfall-Bewertungs-Pflicht, sobald ein Exploit öffentlich verfügbar ist — unabhängig von der Detection-Lage.

Standalone-Server vs. Kubernetes — zwei strukturell verschiedene Bedrohungen

Die Klassifikation „LPE“ trifft den Punkt nur auf einem klassischen Server. In Kubernetes verschiebt sich der Bedrohungstyp:

• Auf einem Standalone-Server ist Copy Fail eine lokale Privileg-Eskalation. Ein unprivilegierter Prozess wird zu root auf derselben Maschine. Der Wirkkreis endet an der Host-Grenze.
• In Kubernetes ist es Cross-Container Lateral Movement. Der Page-Cache ist nicht namespaced, Container-Image-Layer liegen auf Node-Ebene nur einmal vor. Ein kompromittierter Pod vergiftet Pages, die andere Pods mit demselben Base-Image als sauber lesen. Kein root am Host nötig, keine Capabilities, kein klassischer Container Escape — und trotzdem Code-Ausführung in fremden Workloads.

Strukturell anders, nicht schlimmer oder harmloser: Die Mitigations-Logik und das Detection-Profil verschieben sich, weil der Angriff weder Netz noch persistentes Filesystem berührt.

Stream Security: Live-Validierung auf Amazon EKS

Stream Security hat den Angriff auf einem produktionsnahen EKS-Cluster nachgestellt: Kubernetes 1.35, Kernel 6.12.77, Amazon Linux 2023. Das Exploit-Script ist 732 Bytes Python, der Shellcode 233 Bytes. Der Exploit lief in rund zwei Sekunden durch und schrieb über 58 Iterationen den Shellcode in den Page-Cache von /usr/bin/cat. Innerhalb von zehn Sekunden — dem Standard-Intervall der Liveness-Probe — lief der Code in Pod B und Pod C. Pod C trug einen Service-Account mit cluster-admin, und damit war der Cluster komplett übernehmbar. Vom unprivilegierten Pod zum Cluster-Admin in unter zwölf Sekunden, ohne dass ein Netzwerk- oder Filesystem-Indikator Alarm schlug.

Business-seitig: Downtime durch Reboot ist die wahrscheinlichste direkte Auswirkung auf einem Standalone-Server. In Kubernetes-Umgebungen kommt das Risiko einer unbemerkten Cluster-Übernahme dazu — Datenverlust ist bei sauberer Mitigation kein realistisches Szenario, die Reputationsfrage stellt sich aber deutlich schärfer, wenn ein Vorfall vor dem Patch durchgeht.

Copy Fail in Kubernetes — die zweite Bedrohungsklasse

Auf einer einzelnen Linux-VM ist Copy Fail eine lokale Privileg-Eskalation. In Kubernetes manifestiert sich dieselbe Schwachstelle anders: nicht als Eskalation auf Root, sondern als Lateral Movement zwischen Pods — ohne Container-Escape, ohne Root, ohne Capabilities. Wer K8s betreibt, sollte beide Bilder im Kopf haben.

Die operative Mechanik kommt aus der Kombination zweier Kubernetes-Eigenschaften, die einzeln betrachtet harmlos sind. Erstens: Container-Images werden in Schichten gebaut, und gleiche Base-Layer werden auf einem Node nur einmal physisch gespeichert (OverlayFS). Zweitens: Wenn der Linux-Kernel ein File von der Platte liest, hält er eine Kopie im Page Cache. Der Page Cache ist eine node-weite Ressource und nicht per Container isoliert. Identifiziert wird er über (filesystem device, inode). Zwei Pods aus derselben Base-Layer, die /usr/bin/cat ausführen, lesen denselben Page-Cache-Eintrag.

Genau hier setzt Copy Fail in K8s an. Ein unprivilegierter Prozess in einem Pod öffnet ein File read-only, korrumpiert über den AF_ALG-Pfad dessen Page-Cache-Kopie, und wartet. Der nächste Pod, der dasselbe File ausführt, läuft auf dem manipulierten Inhalt — ohne dass je etwas auf die Platte geschrieben wird. Der Angreifer betritt nie den Host und sieht von außen nichts: er wählt blind eine verbreitete Binärdatei (cat, bash, eine geteilte Library), korrumpiert sie und lässt Kubernetes entscheiden, welcher Pod sie als Nächstes anfasst.

Der Trigger ist Kubernetes selbst. Liveness- und Readiness-Probes sind die Standard-Mechanik, mit der K8s periodisch in Pods reinläuft — typischerweise alle paar Sekunden. Stream Security hat den Ablauf auf einem produktiven EKS-Cluster (Kubernetes 1.35, Kernel 6.12.77, Amazon Linux 2023) end-to-end validiert: zwischen Exploit-Start in einem unprivilegierten Pod ohne Service Account und Code-Execution in einem cluster-admin-Pod lagen weniger als zehn Sekunden, ausgelöst durch eine Liveness-Probe, die cat /tmp/healthcheck ausführte.

Der Host blieb in dem Test unbetroffen. Sein /usr/bin/cat liegt auf einem anderen Filesystem mit anderem Inode — der Page Cache trennt die beiden Einträge sauber. Das heißt: Copy Fail ist in K8s kein Container-zu-Host-Escape, sondern Container-zu-Container-Bewegung über die geteilte Node-Schicht. Das macht es nicht harmloser, sondern strukturell anders. Network Policies, RBAC und File-Integrity-Monitoring sehen den Angriff nicht, weil weder das Netz noch das persistente Filesystem berührt werden.

Der Blast Radius hängt an Ihrer Base-Image-Hygiene:

Die schmerzhafte Konsequenz aus Stream Securitys Demo: Der Angreifer entscheidet nicht, wer getroffen wird. Das entscheiden Kubernetes-Scheduler, Image-Layer-Sharing und Probe-Konfiguration. Wer cluster-admin-Daemonsets aus derselben Base-Layer baut wie unprivilegierte Application-Pods, hat einen Pfad gelegt, den die eigenen Plattform-Konventionen befahrbar machen.

Wolfi OS und die Frage nach der Verantwortung

Wir setzen bei Moselwal auf Wolfi OS als Container-Basis. Für eine Schwachstelle wie Copy Fail ist die saubere Einordnung wichtig, weil die Frage „liegt es an unserer Container-Distribution?" sonst falsch beantwortet wird.

Wolfi ist eine Undistro, also reines Userland ohne eigenen Kernel. Wolfi nutzt vollständig den Kernel des Host-Systems. Daraus folgen zwei Dinge gleichzeitig: Wolfi ist nicht die Ursache von Copy Fail, und Wolfi kann die Schwachstelle auch nicht beheben. Die Verantwortung liegt vollständig auf der Host-Schicht. Das gilt 1:1 auch für Distroless-Images, Chainguard-Bilder, Alpine, Debian-slim und jede andere schmale Container-Basis: keine bringt einen eigenen Kernel mit.

Aus genau diesem Grund haben wir uns vor einigen Wochen grundsätzlich von compose.yaml verabschiedet und unsere Container-Topologien deklarativ aufgebaut. Wenn die Schichten klar getrennt sind — Image, Pod-Spec, Host-Kernel — lässt sich die Verantwortung pro Vorfall eindeutig verorten. Im Fall Copy Fail: beim Host-Kernel. Image-Rebuilds wären reine Beschäftigungstherapie und würden die Validierung der eigentlichen Mitigation nur verärgern.

Wer Wolfi-Images im Einsatz hat, profitiert trotzdem indirekt: Die schmalere Angriffsfläche im Userland reduziert die Wahrscheinlichkeit, dass ein Angreifer überhaupt erst an den Punkt kommt, an dem er einen lokalen Kernel-Exploit startet. Aber das ist Defense-in-Depth, nicht Mitigation.

Mitigation und Sofortmaßnahmen

Die kurze Antwort: Distribution-Patch einspielen und neu starten. Wo ein Reboot nicht sofort möglich ist, deaktivieren Sie algif_aead per Modul-Blacklist und schränken den Crypto-User-Zugang ein. Beide Workarounds wirken zur Laufzeit.

Patch einspielen

# Debian/Ubuntu
sudo apt update && sudo apt upgrade -y linux-image-generic
sudo reboot

# RHEL/Rocky/AlmaLinux
sudo dnf upgrade -y kernel
sudo reboot

# SUSE
sudo zypper patch --category security
sudo reboot

NixOS — deklarativer Patch und Modul-Blacklist

NixOS-Hosts patchen anders: Kernel und Modul-Blacklist werden in /etc/nixos/configuration.nix deklariert, dann zieht nixos-rebuild switch beides in einem Schritt. Vorteil: die nächste Generation lässt sich über den Bootloader zurückrollen, falls die Mitigation eine produktive Funktion bricht.

# /etc/nixos/configuration.nix
boot.kernelPackages = pkgs.linuxPackages_6_6;  # gepatchtes LTS-Channel-Update
boot.blacklistedKernelModules = [ "algif_aead" ];
boot.kernel.sysctl = {
  "kernel.crypto_user_api" = 0;
};

# anschließend
sudo nixos-rebuild switch
sudo reboot

Wer den Kernel-Channel nicht direkt anheben möchte, kann zunächst nur die Modul-Blacklist und das sysctl deklarieren (Stopgap), und den Channel-Bump im nächsten Wartungsfenster nachziehen. Die deklarative Form macht beide Schritte audit-fest und automatisch reproduzierbar.

Workaround ohne Reboot: algif_aead deaktivieren

# Modul live entladen (sofortige Wirkung)
sudo modprobe -r algif_aead

# Persistent blacklisten
echo "blacklist algif_aead" | sudo tee /etc/modprobe.d/cve-2026-31431.conf
sudo depmod -a

crypto_user-Zugang restriktieren

# sysctl-Stopgap: Crypto-User-API für unprivilegierte Prozesse sperren
echo "kernel.crypto_user_api = 0" | sudo tee /etc/sysctl.d/99-cve-2026-31431.conf
sudo sysctl --system

Kubernetes: PodSecurity-Profil verschränken

apiVersion: v1
kind: Pod
metadata:
  name: hardened-workload
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: registry.example.com/app:1.0.0
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]

Kubernetes: Base-Image-Hygiene und seccomp-Block

Wer K8s-spezifische Lateral-Movement-Risiken (siehe Sektion „Copy Fail in Kubernetes“ oben) strukturell minimieren will, hat drei Hebel jenseits des Kernel-Patches:

• Diverse Base-Images. Verschiedene Workloads sollten nicht alle auf ubuntu:24.04 sitzen. Image-Layer, die nur von einem Workload genutzt werden, landen nicht in einem geteilten Page-Cache-Eintrag, die Lateral-Bewegung läuft ins Leere.
• Distroless oder scratch für Workloads. Application-Container brauchen typischerweise keine System-Binärdateien wie /usr/bin/cat oder /bin/sh. Was nicht im Image liegt, kann auch nicht in dessen Page Cache korrumpiert werden. Das ist die strukturelle Antwort auf Copy Fail im K8s-Kontext.
• Privileged DaemonSets vom Workload-Pfad trennen. CNI-Agents, Logging-Sidecars und Monitoring-Daemons mit hostNetwork oder hostPath sollten nie aus derselben Base-Layer kommen wie unprivilegierte Application-Pods. Sonst wird der Page Cache zum Aufzug ins cluster-admin-Stockwerk.

Auf Pod-Ebene blockt ein Seccomp-Profil den Eintritt direkt am Syscall. Das RuntimeDefault-Profil von Docker und Kubernetes lässt AF_ALG-Sockets durch — die Sperre muss explizit gesetzt werden:

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

Rollback. Modul-Blacklist lässt sich mit sudo rm /etc/modprobe.d/cve-2026-31431.conf und Reload rückgängig machen. Anwendungen, die AEAD-Crypto im User-Space über AF_ALG nutzen (selten, meist nur spezielle VPN-Tools oder Krypto-Benchmarks), funktionieren ohne das Modul nicht mehr.

Technischer Deep Dive

Der ausnutzbare Pfad sitzt im Crypto-Subsystem des Kernels. AF_ALG ist eine Socket-Familie, mit der Userspace-Prozesse Kernel-Crypto-Implementierungen ansprechen können — historisch eingeführt für IPsec-Daemon-Implementierungen und HW-beschleunigte Crypto. Das Modul algif_aead implementiert speziell AEAD-Cipher-Operationen (Authenticated Encryption with Associated Data) über dieses Interface.

Die Schwachstelle entsteht in der Verarbeitung gewisser recvmsg()-Pfade in Kombination mit fehlerhaftem Reference-Counting auf Skb-Strukturen. Unter bestimmten Race-Conditions schreibt der Kernel in einen Buffer, der bereits freigegeben wurde — ein klassisches Use-After-Free im Kernel-Heap. Mit kontrollierter Heap-Allokation lässt sich der freie Slot mit einer angreifer-kontrollierten Datenstruktur belegen, was zu Kernel-Memory-Disclosure und letztlich Privilege-Escalation über cred-Struktur-Manipulation führt.

Wichtige Aspekte für die Bewertung:

• Kein Capability-Bedarf. Die AF_ALG-Socket-Erstellung benötigt weder CAP_NET_ADMIN noch CAP_SYS_MODULE. Jeder unprivilegierte Prozess kann den Pfad erreichen, sofern das Modul geladen ist.
• Auto-Load-Verhalten.algif_aead wird auf den meisten Distributionen automatisch geladen, sobald der erste AF_ALG-Socket für AEAD geöffnet wird. Reine Modul-Entladung reicht ohne Blacklist nicht: ein Angreifer lädt es bei Bedarf nach.
• Container-Namespaces helfen nicht. User-Namespaces isolieren UID-Mappings, aber nicht den Kernel-Code-Path. Die Crypto-Sockets werden unabhängig vom Container-Kontext gegen den Host-Kernel geöffnet.
• seccomp-bpf als Defense-in-Depth. Ein restriktives seccomp-Profil, das den socket()-Syscall auf AF_INET/AF_INET6/AF_UNIX einschränkt, blockiert den Eintrittspunkt. Docker und Kubernetes-Default-seccomp-Profile decken das nicht ab.

Cipher-Wahl und Schreib-Mechanik im PoC

Der öffentlich dokumentierte PoC nutzt einen AEAD-Socket mit dem Cipher-String authencesn(hmac(sha256),cbc(aes)). Der eigentliche Schreibvorgang in den Page-Cache läuft als Kette aus vier Schritten:

1. Das Ziel-Binary (im PoC: /usr/sbin/ipset aus dem kube-proxy-Image) wird read-only geöffnet — mehr braucht der Angriff nicht.
2. Ein AF_ALG-AEAD-Socket wird erstellt und auf den oben genannten Cipher konfiguriert.
3. Ein kleines Payload-Chunk wird mit dem Flag MSG_MORE gesendet, das dem Kernel signalisiert, dass weitere Daten folgen.
4. splice() transferiert File-Content vom Ziel-FD über eine Pipe in den AF_ALG-Socket. Der CoW-Bug schreibt dabei die Angreifer-Bytes in die Page-Cache-Pages des Ziels, anstatt eine isolierte Kopie zu erzeugen.

Der Schreibvorgang erfolgt nicht in einem Schritt, sondern in 4-Byte-Windows pro Iteration. In der Stream-Reproduktion waren 58 Iterationen nötig, um 233 Byte Shellcode in die Pages von /usr/bin/cat zu schreiben — das passt zur 4-Byte-Window-Mechanik. Der gesamte Lauf dauerte rund zwei Sekunden.

Warum kube-proxy ein ideales Target ist

Der PoC zielt nicht zufällig auf kube-proxy. Vier Eigenschaften machen das DaemonSet zum idealen Hebel:

• Läuft als DaemonSet auf jedem Node des Clusters.
• Ist mit privileged: true und hostNetwork: true ausgestattet.
• Bringt ipset als regulären Bestandteil des Images mit — ein attraktives Korruptions-Ziel für das Lateral-Movement.
• imagePullPolicy: IfNotPresent ist Default; das PoC-Image kann über FROM registry.k8s.io/kube-proxy:v1.35.2 denselben Base-Layer wie das produktive kube-proxy auf der Node nutzen, womit die Page-Cache-Pages garantiert geteilt werden.

Das PoC-Payload mountet anschließend Host-Root und schreibt ein Marker-File nach /root/res, um Code-Execution auf Node-Ebene zu beweisen. Die Mechanik wurde unabhängig auf ACK (Alibaba Cloud) und EKS (AWS) reproduziert — die Schwachstelle wirkt cross-cloud, weil sie im Kernel und nicht im Distributions-Userland sitzt.

Trade-off bei der Stopgap-Mitigation: Die Modul-Blacklist deckt nur den AEAD-Pfad. Es gibt verwandte AF_ALG-Module (algif_hash, algif_skcipher, algif_rng, algif_aead), die nicht alle vom selben CVE betroffen sind, deren Prüfung sich aber im Rahmen einer sauberen Patch-Welle empfiehlt.

Detection und Prüfung

Lead-Fragen

• Läuft auf meinen Linux-Hosts ein Kernel der Linien 5.10/5.15/6.1/6.6 LTS oder älter — und liegt der eingespielte Patch unter 6.18.22 / 6.19.12 / 7.0?
• Ist algif_aead auf meinen Hosts ladbar oder built-in?
• Sehe ich in den Logs ungewöhnliche AF_ALG-Socket-Operationen von unprivilegierten Prozessen — vor allem in Kombination mit setresuid/setreuid/setuid kurz danach?
• Wurde der Host in den letzten 7–10 Tagen ohne Kernel-Update gestartet, während Exploit-Code in Cybercrime-Foren zirkulierte?

Quick-Check pro Host

# Kernel-Version prüfen
uname -r

# algif_aead-Modul-Status
lsmod | grep algif_aead
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

# Distribution-Patch-Stand
# Debian/Ubuntu
apt list --installed 2>/dev/null | grep linux-image
# RHEL/AlmaLinux/Rocky
rpm -qa | grep kernel
# SUSE
zypper search --installed-only -t package kernel-default

Falco/eBPF-Korrelation

Wer Falco oder vergleichbares eBPF-Monitoring betreibt, sollte auf eine 3-Syscall-Korrelation pro Prozess achten: socket(AF_ALG) → bind/accept auf einen aead-Cipher → setresuid(0,0,0) oder setreuid(0,0) binnen weniger Sekunden. Das ist das Exploit-Signaturmuster, das auch in PoC-Variationen stabil bleibt.

Eine konkrete Falco-Rule-Skizze:

- rule: AF_ALG Aead Followed By Setuid
  desc: Unprivileged process opens AF_ALG socket and then transitions to UID 0
  condition: >
    evt.type = socket and
    evt.arg.domain = AF_ALG and
    proc.uid != 0 and
    proc.aname[1] != systemd
  output: >
    Possible Copy Fail exploitation
    (user=%user.name pid=%proc.pid command=%proc.cmdline)
  priority: WARNING

Die Rule allein löst False Positives bei legitimen Workloads aus (z.B. einige libgcrypt-Pfade). Sie ist als Korrelations-Anker gedacht, nicht als Blocking-Regel — die zusätzliche setuid-Folge in der Output-Sammlung macht den Fall verifizierbar.

Audit-Routine pro Host

Für Mittelständler ohne dedizierte SOC-Mannschaft: einmal pro Woche pro Host uname -r in eine zentrale Tabelle pflegen und gegen die aktuell empfohlene gepatchte Version abgleichen. Wer das nicht automatisiert hat, bekommt Patch-Drift, die genau in solchen High-Severity-Zyklen teuer wird.

Betreiberempfehlung

Operational Decision Block

Wenn Sie Linux-Hosts auf RHEL/AlmaLinux/Rocky/CentOS Stream betreiben — dann

Distribution-Patch via dnf upgrade kernel einspielen und neu starten. Wer keinen Reboot fahren kann: KernelCare Live-Patch für EL8/EL9 ist als Stopgap verfügbar.

Wenn Sie Ubuntu LTS-Hosts betreiben — dann

Kernel-Update via apt upgrade linux-image-* plus Reboot. KernelCare deckt Ubuntu 22.04 LTS (Jammy) inkl. AWS- und HWE-Varianten als Live-Patch ab.

Wenn Sie Debian Stable (bookworm/trixie) betreiben — dann

Patches sind verfügbar — Debian Stable hat die Updates seit Anfang Mai eingespielt. Wenn der Host noch nicht aktualisiert ist, ist das diese Woche zu schließen. Sid hat linux 7.0.4-1.

Wenn Sie EC2, Hetzner Cloud, Azure, GCP nutzen — dann

Cloud-Provider patchen den Hypervisor nicht für Sie. Ihr Guest-Kernel muss aktualisiert werden. Bei Amazon Linux: AWS Security Bulletin 2026-027 mit konkreten Kernel-Versionen.

Wenn Sie Kubernetes-Plattformen betreiben — dann

Node-Image-Update einplanen — alle Worker-Nodes brauchen den gepatchten Kernel, sonst eskalieren kompromittierte Pods auf den Host. Container-Images selbst sind nicht betroffen (Container teilen sich den Host-Kernel).

Wenn Sie Hosts haben, auf denen AF_ALG-Anwendungen NICHT laufen — dann

Sie können als Interim das Modul deaktivieren: echo "install algif_aead /bin/true" > /etc/modprobe.d/blacklist-algif_aead.conf + Reboot. Achtung: auf RHEL-Family ist das Modul built-in, dort muss über grubby der Initcall blacklisted werden — oder direkt patchen.

 

Was wir bewusst nicht tun

• Kein verzögertes Update auf „nächstes Wartungsfenster“, wenn die CISA-KEV-Deadline morgen ist und der Host öffentlich erreichbar ist. Die Real-World-Exploitation gegen Cloud-Provider ist dokumentiert.
• Keine modprobe-only-Workarounds auf RHEL-Family. Das funktioniert dort nicht, weil algif_aead built-in ist — nur Patch oder grubby-Initcall-Blacklist hilft.
• Keine Annahme „unsere VM ist klein, wer sollte das ausnutzen“. Der Exploit ist 732 Byte Python und läuft über jeden Initial-Access-Vektor (SSH, Web-Shell, kompromittierter Service-Account).

Was wir bei Moselwal konkret getan haben

Unsere Build-Container und Production-Hosts laufen auf gepatchten Kernels seit Anfang Mai. Konkret:

• Eigene Plattform-Hosts (moselwal.de, ole-hartwig.eu, blog.ole-hartwig.eu, nozzleops.de): Debian-Stable mit Anfang-Mai-Kernel-Update; Reboot durchgefahren; algif_aead-Status überprüft.
• Build-Container (moselwal/build-base, moselwal/typo3-builder, moselwal/frankenphp-runtime): Base-Images auf gepatchten Distribution-Versionen neu gebaut, Container-Registry-Tags aktualisiert, alle Build-Pipelines auf neue Tags umgestellt.
• Kunden-Hosts unter Wartung: Patches sind in derselben Wartungs-Iteration eingespielt, in der die Mai-CVE-Welle (Composer 2.9.8, TYPO3 14.3.1/13.4.29) verteilt wurde. SBOM-Inventur pro Kunde aktualisiert.
• Detection-Monitoring: Falco-Rule für AF_ALG-Socket plus folgendem setuid-Sprung als Korrelations-Signal in der zentralen Beobachtung aktiviert.

Für Kunden mit eigenen Cloud-VMs oder eigenen Container-Plattformen, die wir nicht selber betreiben, haben wir Patch-Hinweise verteilt und unterstützen bei Bedarf mit Detection-Skripten oder Audit-Routinen.

Fazit

Copy Fail ist die erste der beiden universellen Linux-LPE-Schwachstellen der Mai-2026-Welle und auch die mit der härtesten externen Indikation: CISA-KEV-Listing, FCEB-Remediation-Deadline 15. Mai 2026, mehrere unabhängige Threat-Intel-Bestätigungen aktiver Exploitation. Eine 732-Byte-Python-Schwachstelle, die jeden Linux-Kernel seit 2017 betrifft — das ist nicht der Edge-Case, das ist die Norm im Mittelstand.

Operativ ist der Patch trivial: dnf upgrade kernel oder apt upgrade linux-image-* plus Reboot. Strategisch ist es ein Test dafür, ob die eigene Patch-Routine schnell genug ist, um KEV-Deadlines einzuhalten, ohne dass dazu ein Notfall ausgerufen werden muss. Wer im April 2026 (Initial Disclosure) bis Mitte Mai die Lage nicht gepatcht hat, hat eine Pipeline-Schwäche, nicht ein Komplexitätsproblem.

Die Cluster-Lehre: Copy Fail und Dirty Frag sind Bauarten desselben Musters — in-place-Optimierungen im Kernel, die unprivilegierte Schreib-Primitive in den Page-Cache erlauben. Wer einen davon hat, hat den anderen vor sich. Die Patch-Pipeline muss beide CVEs als zusammenhängende Aufgabe behandeln, nicht als zwei separate Tickets.