„Copy Fail“ (CVE-2026-31431): Warum ein Kernel-Bug jeden Kubernetes-Node betrifft
Die Linux-Lücke „Copy Fail“ kann aus einem unprivilegierten Pod Root auf dem Node machen. Ein neues Container-Image hilft dagegen nicht, denn der Fehler steckt im Kernel des Nodes. So sichern Sie Ihre Kubernetes- und AKS-Nodes ab.
Was ist passiert?
Ende April 2026 wurde die Schwachstelle CVE-2026-31431 veröffentlicht, genannt „Copy Fail“. Entdeckt hat sie Taeyang Lee vom Sicherheitsunternehmen Theori, unterstützt vom Xint-Code-Team. Die Lücke liegt in der Krypto-Schnittstelle AF_ALG des Linux-Kernels, genauer im Modul algif_aead, und geht auf eine Optimierung aus dem Jahr 2017 (Kernel 4.14) zurück. Sie ist mit CVSS 7.8 bewertet.
Über AF_ALG und den Systemaufruf splice() kann ein unprivilegierter Prozess gezielt vier Bytes in den Page Cache einer beliebigen lesbaren Datei schreiben, etwa eines setuid-Programms wie /usr/bin/su. Die Datei auf der Festplatte bleibt unverändert, Integritätsprüfungen schlagen deshalb nicht an. Das Ergebnis sind Root-Rechte. Ein öffentlicher Exploit erschien innerhalb eines Tages, laut Berichten ein Python-Skript von nur 732 Bytes. Behoben ist der Fehler in den Kernel-Versionen 6.18.22, 6.19.12 und 7.0, die Distributionen liefern ihre Updates schrittweise aus.
Die US-Behörde CISA hat Copy Fail am 1. Mai in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) aufgenommen. US-Bundesbehörden müssen bis zum 15. Mai patchen.
So wird aus einem Pod Root auf dem Node:
Warum betrifft Sie das?
Alle Container auf einem Node teilen sich dessen Kernel und damit auch den Page Cache. Öffnet ein Prozess einen AF_ALG-Socket, lädt der Kernel das Modul algif_aead bei Bedarf automatisch nach, besondere Rechte braucht der Pod dafür nicht. Ein kompromittierter oder bösartiger Pod kann so über die Container-Grenze hinaus wirken. Im AKS-Issue zur Lücke berichtete ein Nutzer, dass ein Pod ohne Root-Rechte auf diesem Weg Root auf dem Node erlangte. Ein öffentlicher Kubernetes-Proof-of-Concept soll laut seinem Autor auch auf EKS und GKE funktioniert haben, andere Teams konnten das allerdings nicht in jeder Umgebung nachstellen.
Der entscheidende Punkt: Ein aktualisiertes Container-Image schließt die Lücke nicht. Erst ein gepatchter Kernel, der tatsächlich gebootet wurde, behebt sie. Ein installiertes Paket ohne Neustart reicht nicht.
Besonders exponiert sind Cluster, in denen fremder oder wenig geprüfter Code läuft, etwa CI-Runner, Build-Agents oder mandantenfähige Plattformen. Workloads in MicroVMs wie Firecracker oder in gVisor sind laut Analysen nicht über diesen Pfad angreifbar.
Was Sie jetzt tun sollten
Microsoft hat am 1. Mai im Repository Azure/AKS (Issue #5753) Hinweise veröffentlicht. Neue Node-Pools und Node-Image-Upgrades erhalten demnach bereits eine Mitigation, die das automatische Laden von algif_aead blockiert. Bestehende Nodes brauchen ein Node-Image-Upgrade oder das bereitgestellte DaemonSet.
- Sofort mitigieren: Rollen Sie das DaemonSet aus dem Issue aus oder aktualisieren Sie das Node-Image. Die Mitigation setzt die modprobe-Regel
install algif_aead /bin/false. Die Regel allein entschärft ein bereits geladenes Modul nicht, prüfen Sie deshalb jeden Node. - Node-Image prüfen und aktualisieren:
az aks nodepool show -g <rg> --cluster-name <cluster> -n <pool> --query nodeImageVersion -o tsv
az aks nodepool get-upgrades -g <rg> --cluster-name <cluster> --nodepool-name <pool> --query latestNodeImageVersion -o tsv
az aks nodepool upgrade -g <rg> --cluster-name <cluster> -n <pool> --node-image-only
- Jeden Node verifizieren:
kubectl get nodes -o custom-columns='NAME:.metadata.name,IMAGE:.metadata.labels.kubernetes\.azure\.com/node-image-version,KERNEL:.status.nodeInfo.kernelVersion'
- Kernel-Fix nachziehen: Sobald Node-Images mit gepatchtem Kernel verfügbar sind, aktualisieren Sie erneut. Erst dann ist die Lücke geschlossen.
- Routine etablieren: Automatische Node-OS-Updates mit festem Wartungsfenster sorgen dafür, dass der nächste Kernel-Fix keine Handarbeit mehr ist:
az aks update -g <rg> -n <cluster> --node-os-upgrade-channel NodeImage
az aks maintenanceconfiguration add -g <rg> --cluster-name <cluster> \
--name aksManagedNodeOSUpgradeSchedule --schedule-type Weekly \
--day-of-week Sunday --interval-weeks 1 --start-time 02:00 --duration 4
- Angriffsfläche verkleinern: Blockieren Sie AF_ALG per Seccomp für nicht vertrauenswürdige Workloads, verzichten Sie auf privilegierte Pods und setzen Sie Pod Security Standards durch.
- Übrige Linux-Systeme einbeziehen: Eigene Kubernetes-Nodes, VMs, Bastion-Hosts und Build-Server brauchen dasselbe Kernel-Update samt Neustart.
Fazit
Copy Fail zeigt deutlich, dass Container keine Sicherheitsgrenze gegen Kernel-Fehler sind. Wer Node-Images nur bei Kubernetes-Upgrades erneuert, ist bei solchen Lücken zu langsam. Eine feste Routine aus automatischen Node-Image-Updates und Wartungsfenstern macht den nächsten Kernel-Patch zur Formsache. Wenn Sie dabei Unterstützung wünschen, sprechen Sie uns an.