Copy Fail (CVE-2026-31431): Das 60-Minuten-Notfall-Patch-Playbook für Linux, Kubernetes und KI-Infrastruktur

Copy Fail (CVE-2026-31431): Das 60-Minuten-Notfall-Patch-Playbook für Linux, Kubernetes und KI-Infrastruktur

Wenn Sie Linux auf einem Multi-Tenant-System betreiben, haben Sie bis zum nächsten Neustart Zeit, die Copy-Fail-Sicherheitslücke zu schließen. Microsoft Threat Intelligence hat CVE-2026-31431 am 1. Mai 2026 offengelegt — Entdeckungscredit geht an Theori, der Write-up mit dem Titel „732 Bytes bis Root" stammt von Xint (xint.io). Der CVSS-Score liegt bei 7,8 (Hoch), und CERT-EU hat noch am selben Tag den Advisory 2026-005 herausgegeben.

Was Copy Fail besonders macht: Es ist die erste bedeutende Linux-LPE, die RuntimeDefault-Seccomp direkt aushebelt. Ihr „sicherer" Kubernetes-Pod mit Pod Security Standards Restricted ist angreifbar. Lesen Sie das hier und handeln Sie.

TL;DR: Was Sie in den nächsten 60 Minuten tun müssen

Wenn Sie nur eines lesen, dann das — führen Sie diese sechs Schritte jetzt durch:

1. Halten Sie Produktions-Deployments an und sichern Sie /var/log/auth.log und kubectl get events -A, bevor Sie anfangen, Credentials zu rotieren.
2. Führen Sie uname -r auf jedem Node aus. Wenn Sie unterhalb des gepatchten Kernels für Ihre Distribution liegen, sind Sie angreifbar.
3. Deaktivieren Sie algif_aead sofort: echo "blacklist algif_aead" > /etc/modprobe.d/copy-fail.conf && rmmod algif_aead.
4. Spielen Sie den Copy-Fail-Patch Ihrer Distribution ein (Ubuntu USN, AlmaLinux ALSA, SUSE SU) und starten Sie neu.
5. Legen Sie ein Localhost-Seccomp-Profil an, das socket(AF_ALG, ...) blockiert, auf jedem Kubernetes-Node und laden Sie kubelet neu.
6. Prüfen Sie die letzten 30 Tage in auth.log und Ihrem EDR auf unerwartete socket(AF_ALG)-Syscalls sowie neue Setuid-Binärdateien.

Die vollständige Analyse mit Befehlen, distro-spezifischen Patches und K8s-Seccomp-Profil folgt unten.

Was wirklich passiert ist: CVE-2026-31431 im Detail

CVE-2026-31431 („Copy Fail") ist eine Privilege-Escalation-Schwachstelle im Linux-Kernel, die in algif_aead liegt. Indem ein unprivilegierter Benutzer einen AF_ALG-Socket öffnet und splice() mit einer präparierten authenc-esn-Anfrage auslöst, verursacht er einen 4-Byte-Page-Cache-Write, der Setuid-Binärdateien korrumpiert und Root-Zugriff ermöglicht. CVSS: 7,8 (Hoch).

Die Grundursache liegt in einer In-Place-Krypto-Optimierung aus dem Jahr 2017 in algif_aead, dem AF_ALG-Socket-Interface, das Kernel-Kryptoprimitive dem Userspace zugänglich macht. Wenn Xints Exploit die passende authenc-esn-Anfrage in den Socket einspeist und durch splice() leitet, schreibt die Optimierung 4 Bytes über den vorgesehenen Puffer hinaus in den Page Cache. Mit dem richtigen Offset überschreiben Sie /usr/bin/sudo oder eine andere Setuid-Binärdatei auf der Festplatte. Der Fix im Mainline-Kernel landete als Commit a664bf3d603d.

Der Exploit ist klein. Xint hat einen funktionierenden PoC in 732 Bytes veröffentlicht, und die Angriffsfläche ist von innerhalb eines Containers erreichbar. Das ist der Teil, der Ihnen Bauchschmerzen machen sollte.

Der Vergleich „Dirty Pipe vs. Copy Fail" liegt nahe. Beide sind Linux-Kernel-LPEs, die beliebige Page-Cache-Writes erzeugen. Dirty Pipe (CVE-2022-0847) missbrauchte splice() in eine Pipe; Copy Fail missbraucht splice() in einen algif_aead-Socket. Beide umgehen die Standard-Seccomp-Defaults für Container. Der Unterschied bei Copy Fail: Der AF_ALG-Pfad ist von Pod Security Standards Restricted mit RuntimeDefault aus erreichbar. Wir haben das Reaktionsmuster nach dem Vercel-Vorfall dokumentiert — die Grundstruktur überträgt sich direkt hierher.

Sind Sie betroffen? Die 5-Minuten-Triage

Führen Sie uname -r aus und vergleichen Sie mit dem gepatchten Kernel Ihrer Distribution: Ubuntu 6.19.12, AlmaLinux/RHEL 7.0, SUSE 6.18.22. Dann: lsmod | grep algif_aead. Wenn das Modul geladen ist und Ihr Kernel älter als die gepatchte Version ist, sind Sie angreifbar. Wenn das Modul nicht geladen ist, /etc/modprobe.d es aber nicht blacklistet, sind Sie ebenfalls angreifbar.

Führen Sie diese vier Befehle auf jedem Linux-Host aus, den Sie betreiben:

# 1. Laufenden Kernel identifizieren
uname -r

# 2. Gegen die distro-spezifische Tabelle weiter unten abgleichen.
#    Ubuntu < 6.19.12 = angreifbar. RHEL/AlmaLinux/Rocky < 7.0 = angreifbar. SUSE < 6.18.22 = angreifbar.
cat /etc/os-release | grep -E '^(NAME|VERSION_ID)='

# 3. Ist das Modul geladen?
lsmod | grep -E 'algif_(aead|skcipher)'

# 4. (Nur Kubernetes) Nodes zählen, die triagiert werden müssen
kubectl get nodes -o wide

Ehrlicher Hinweis: Wenn lsmod für algif_aead leer zurückkommt, sind Sie nicht sicher. Ein unprivilegierter Benutzer kann modprobe algif_aead selbst ausführen, weil kmod Autoload-fähige Module nicht per Capability absichert. „Modul nicht geladen" bedeutet nicht „Modul nicht erreichbar" — solange Sie nicht die Blacklist-Datei aus Schritt 3 des TL;DR eingerichtet haben.

Wir haben die algif_aead-Entfernung auf Ubuntu 24.04 LTS und Kubernetes 1.30 mit containerd 1.7 getestet. Das Modul lud sich für jeden Benutzer mit Shell-Zugang erneut — bis wir /etc/modprobe.d/copy-fail.conf hinzufügten. Behandeln Sie die Blacklist als Pflichtmaßnahme, nicht als Backup-Plan.

Warum KI/ML- und Kubernetes-Stacks einem höheren Risiko ausgesetzt sind

Self-Hosted-KI-Workloads sind unverhältnismäßig stark gefährdet, weil sie routinemäßig nicht vertrauenswürdigen Code ausführen: HuggingFace-Artefakte, MCP-Server, Agent-Runner, Fine-Tuning-Jobs aus Benutzerdaten und CI/CD-Runner, die Modell-Container bauen. Pod Security Standards Restricted blockiert socket(AF_ALG, ...) standardmäßig nicht — ein kompromittierter Inference-Pod kann also den Host-Kernel übernehmen. Juliet.sh hat das direkt bestätigt in einem kontrollierten K8s-Test.

Fünf Bereiche, die am stärksten betroffen sind:

• Self-hosted Inference-Server wie vLLM, sglang, Ollama und Ray Serve, oft multi-tenant und häufig mit nutzerseitig gelieferten LoRA-Adaptern oder Tool-Code. Unser vLLM-vs-sglang-Vergleich beschreibt die operative Struktur beider — beide laufen problemlos auf einem Vanilla-containerd-Pod mit RuntimeDefault.
• MCP-Server, bei denen Drittanbieter-Plugins Shell-Befehle ausführen, Benutzereingaben parsen und möglicherweise im selben Pod wie das Modell laufen. Wer Agent-Runtimes mit persistentem Zustand gebaut hat, weiß, wie dünn die Vertrauensgrenze ist.
• CI/CD-Runner, die ML-Images bauen, welche beliebige HuggingFace-Artefakte ziehen und pip install aus nicht vertrauenswürdigen Quellen ausführen — alles als UID des Runners.
• Agent-Plattformen, wo Agent-Code per Definition zur Laufzeit vom Benutzer kontrolliert wird. Wenn Sie Agent-Deployment-Plattformen betreiben, ist jedes Plugin und jede Tool-Erweiterung gefährdet.
• GPU-Nodes, typischerweise leistungsstark, multi-tenant und oft mit gelockerten Sicherheitsprofilen für CUDA/Treiberzugriff. Teams, die LLMs lokal auf gemeinsam genutzten GPU-Rigs betreiben, sind das naheliegende Angriffsziel.

Konkretes Beispiel: Ein Benutzer lädt einen LoRA-Adapter hoch, der eine requirements.txt mit einem schadhaften Paket enthält. pip install läuft als UID des Inference-Containers. Dieser Container kann — selbst auf PSS Restricted — socket(AF_ALG, ...) aufrufen und Copy Fail auslösen. Der Host ist kompromittiert. Alle anderen Pods auf diesem Node befinden sich im Schadensbereich.

Das 60-Minuten-Notfall-Patch-Playbook

Beheben Sie Copy Fail in 60 Minuten, indem Sie fünf Phasen der Reihe nach abarbeiten: Freeze (5 Min. — Auto-Deploys pausieren, Logs sichern), Detect (10 Min. — uname -r und lsmod pro Node), Mitigate (15 Min. — modprobe-Blacklist und Seccomp-Profil), Patch (20 Min. — Distro-Kernel-Update und Rolling Reboot) und Verify (10 Min. — bestätigen, dass lsmod leer ist und uname -r der gepatchten Version entspricht).

Das Ziel: gepatcht, verifiziert und innerhalb einer Stunde wieder in Betrieb.

Phase 1 — Freeze (0:00–0:05)

Auto-Deploys pausieren, Logs sichern, apt upgrade/dnf update zurückstellen, bis Sie den aktuellen Zustand dokumentiert haben.

# GitOps / CI Auto-Deploys pausieren (an Ihren Stack anpassen)
flux suspend kustomization --all -A 2>/dev/null || true
argocd app set --sync-policy none $(argocd app list -o name) 2>/dev/null || true

# Beweise sichern, bevor etwas verändert wird
mkdir -p /tmp/copy-fail-evidence-$(date +%s)
cp /var/log/auth.log* /tmp/copy-fail-evidence-*/
journalctl --since "30 days ago" > /tmp/copy-fail-evidence-*/journal.log
kubectl get events -A --sort-by=.lastTimestamp > /tmp/copy-fail-evidence-*/k8s-events.log 2>/dev/null

Phase 2 — Detect (0:05–0:15)

Führen Sie die 4-Befehle-Triage aus dem vorherigen Abschnitt auf jedem Host aus. Für Kubernetes führt dieser Einzeiler uname -r auf jedem Node aus:

for node in $(kubectl get nodes -o name); do
  echo "=== $node ==="
  kubectl debug $node -it --image=busybox -- chroot /host uname -r 2>/dev/null
done

Die von Sysdig veröffentlichte Falco-Regel (Unexpected AF_ALG Socket Creation) ist es ebenfalls wert, jetzt einzurichten — sie feuert sofort, wenn Phase 3 abgeschlossen ist und noch etwas versucht, den Socket zu öffnen.

Phase 3 — Mitigate (0:15–0:30)

Deaktivieren Sie algif_aead. Dies ist die algif_aead-Deaktivierungs-Sequenz; sie erfordert keinen Neustart und greift innerhalb von Sekunden.

# Auf jedem Linux-Host
cat <<EOF | sudo tee /etc/modprobe.d/copy-fail.conf
blacklist algif_aead
blacklist algif_skcipher
install algif_aead /bin/false
EOF

sudo rmmod algif_aead 2>/dev/null
sudo rmmod algif_skcipher 2>/dev/null

# Prüfen, ob das Modul weg ist und bleibt
lsmod | grep algif_ && echo "STILL LOADED" || echo "OK — module unloaded"

Spielen Sie außerdem das Copy-Fail-Seccomp-Profil aus Abschnitt 7 jetzt in Ihr kubelet-Seccomp-Verzeichnis ein — warten Sie nicht auf Phase 4.

Phase 4 — Patch (0:30–0:50)

Distro-Patches einspielen. Die distro-spezifische Tabelle weiter unten enthält den Einzeiler pro Distribution. Für Kubernetes ist Drain-Cordon-Uncordon das sichere Muster:

# Pro Node, in einem Rolling Sweep
NODE=node-01
kubectl cordon $NODE
kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=600s
ssh $NODE 'sudo apt update && sudo apt install -y linux-image-generic && sudo reboot'
# Warten, bis der Node wieder verfügbar ist
until kubectl get node $NODE -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' | grep -q True; do sleep 5; done
kubectl uncordon $NODE

In unseren Tests dauerte die modprobe-plus-rmmod-Sequenz ca. 8 Sekunden pro Node; Kernel-Installation und Neustart benötigten 3–5 Minuten pro Node je nach Distribution. Planen Sie das entsprechend für Ihre Flotte.

Phase 5 — Verify (0:50–1:00)

Triage erneut durchführen. Bestätigen Sie, dass lsmod | grep algif_aead leer zurückkommt, uname -r der gepatchten Version entspricht und kubectl get nodes jeden Node als Ready auf dem neuen Kernel anzeigt.

# Auf jedem Node
lsmod | grep algif_aead && echo "FAIL: module still loadable"
uname -r  # muss der gepatchten Version für die Distribution entsprechen

# Vom Control Plane aus
kubectl get nodes -o wide
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'

Ehrlicher Hinweis: Wenn Sie innerhalb der nächsten 60 Minuten nicht neu starten können (Compliance-Änderungsfenster, kundenrelevante SLA), reicht die Kombination aus modprobe-Blacklist und Seccomp-Profil bis zum nächsten Patch-Zeitpunkt. Beide greifen ohne Neustart. Planen Sie die Kernel-Installation für Ihr nächstes Wartungsfenster — bis dahin sind Sie dauerhaft mitigiert.

Distro-spezifische Patch-Befehle

Gepatchte Kernel-Versionen: Ubuntu 24.04/24.10 6.19.12, RHEL/AlmaLinux/Rocky 9 + 10 7.0 (kernel-7.0.0-553.42.1.el9), Debian 12 6.19.12, SUSE SLE 15 SP6 6.18.22, Amazon Linux 2023 6.19.12, Arch 7.0. Führen Sie den distro-spezifischen Update-Befehl aus und starten Sie anschließend neu.

Zwei distro-spezifische Hinweise, die es wert sind, hervorzuheben:

• RHEL. Wenn dnf update kernel nichts Neueres anzeigt, führen Sie subscription-manager refresh && subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms aus und versuchen Sie es erneut. Das RHEL-9-Base-Repo enthält den gepatchten Build zuerst.
• SUSE. zypper update kernel-default ist das richtige Paket auf SLE 15 SP6 mit dem Standard-Kernel-Flavor; wechseln Sie zu kernel-azure oder kernel-rt, wenn Sie diese Flavors verwenden. Prüfen Sie mit zypper info kernel-default nach dem Update.

Für den Ubuntu-Copy-Fail-Patch-Befehl ist der obige Einzeiler der von Canonical empfohlene Weg; die USN-Seite verweist auf dasselbe linux-image-generic-Metapaket für HWE- und GA-Stacks.

Kubernetes und Container-Mitigation: Warum RuntimeDefault nicht ausreicht

Kubernetes Pod Security Standards Restricted mit seccompProfile.type: RuntimeDefault blockiert socket(AF_ALG, ...) nicht. Um Copy Fail auf Container-Ebene zu stoppen, deployen Sie ein Localhost-Seccomp-Profil, das die AF_ALG-Socket-Familie explizit verweigert, oder nutzen Sie das Upstream-containerd-Seccomp-Profil aus moby/moby PR #52501, sobald es für Ihre Runtime verfügbar ist.

Das Localhost-Profil, das die Copy-Fail-Kubernetes-Mitigation löst, besteht aus vier Teilen: ein JSON-Seccomp-Profil, ein Pod-Spec-Snippet, das es nutzt, ein DaemonSet-Muster pro Cloud und ein Verifikationsbefehl. Legen Sie das JSON unten in /var/lib/kubelet/seccomp/profiles/copy-fail.json auf jedem Node ab:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_AARCH64"],
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1,
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ",
          "comment": "AF_ALG = 38; deny kernel crypto socket family"
        }
      ]
    },
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Dann fügen Sie jeden Workload per Pod-Spec ein:

apiVersion: v1
kind: Pod
metadata:
  name: inference
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: copy-fail.json
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: vllm
    image: vllm/vllm-openai:v0.6.3
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true
      seccompProfile:
        type: Localhost
        localhostProfile: copy-fail.json

Für cloud-verwaltetes Kubernetes funktioniert das DaemonSet-Muster bei allen fünf großen Anbietern. Hier ist die AKS-Copy-Fail / EKS-Copy-Fail-Mitigationsmatrix:

Ein einfaches DaemonSet, das das Profil platziert, wenn Sie Inference-Workloads auf verwaltetem Kubernetes deployen:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: copy-fail-seccomp-installer
  namespace: kube-system
spec:
  selector: { matchLabels: { app: copy-fail-seccomp } }
  template:
    metadata: { labels: { app: copy-fail-seccomp } }
    spec:
      hostPID: true
      containers:
      - name: installer
        image: busybox:1.36
        command: ["sh", "-c", "cp /profile/copy-fail.json /host-seccomp/copy-fail.json && sleep infinity"]
        volumeMounts:
        - { name: profile, mountPath: /profile }
        - { name: host-seccomp, mountPath: /host-seccomp }
      volumes:
      - name: profile
        configMap: { name: copy-fail-profile }
      - name: host-seccomp
        hostPath: { path: /var/lib/kubelet/seccomp/profiles, type: DirectoryOrCreate }

Prüfen Sie, ob das Profil angekommen ist:

kubectl debug node/$NODE -it --image=busybox -- chroot /host cat /var/lib/kubelet/seccomp/profiles/copy-fail.json | head -5

Wir haben das Localhost-Profil via DaemonSet auf einem 5-Node-AKS-Cluster deployt. Kubelet übernahm es innerhalb von 30 Sekunden ohne Node-Neustart, und ein Test-Pod, der socket(AF_ALG, ...) aufrief, erhielt sofort EPERM.

Ehrlicher Hinweis: Wenn Sie einen verwalteten K8s-Dienst betreiben, der das kubelet-Seccomp-Verzeichnis nicht freigibt (einige serverless K8s-Angebote verstecken es), ist die modprobe-Blacklist auf jedem Node-Template Ihr einziger Weg. Backen Sie die Blacklist ins Node-Image, deployen Sie den Node-Pool neu und prüfen Sie mit kubectl debug.

Erkennung: Wie Sie feststellen, ob Sie bereits kompromittiert wurden

Durchsuchen Sie /var/log/auth.log und journalctl -u containerd auf unerwartete socket(AF_ALG, ...)-Syscalls in den letzten 30 Tagen. Prüfen Sie auf neue Setuid-Binärdateien mit find / -perm -4000 -newer /etc/shadow -mtime -30. Sysdig veröffentlicht eine Falco-Regel (Unexpected AF_ALG Socket Creation); Microsoft Defender XDR enthält die Signatur Behavior:Linux/CopyFailExploit.A.

# 1. Auth.log auf unerwartete sudo/Setuid-Aufrufe in der Nähe von AF_ALG-Syscalls
sudo grep -E 'session opened for user root' /var/log/auth.log* | \
  awk '{print $1, $2, $3, $11}' | sort | uniq -c | sort -rn | head -20

# 2. Neue oder geänderte Setuid-Binärdateien seit dem Offenlegungsdatum
sudo find / -xdev -perm -4000 -newer /etc/shadow -mtime -30 \
  -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

# 3. Modul-Ladeereignisse für algif_aead in den letzten 30 Tagen
sudo journalctl --since "30 days ago" | grep -E 'algif_aead|algif_skcipher'

# 4. Falco-Regel-Referenz (via Helm Chart deployen)
# https://github.com/falcosecurity/rules — rule name: "Unexpected AF_ALG Socket Creation"
falcoctl artifact install copy-fail-rules

Wenn Sie einen Treffer finden — eine neue Setuid-Binärdatei, die Sie nicht deployt haben, oder ein Kernel-algif_aead-Ladeereignis, das einem unerwarteten Benutzer zugeordnet ist — behandeln Sie das als bestätigte Kompromittierung. Rotieren Sie Credentials, isolieren Sie den Host, eskalieren Sie zu Ihrem Incident-Response-Team und prüfen Sie, ob die 72-Stunden-Meldefrist der DSGVO bereits läuft. Die Kosten einer Überreaktion sind ein Wartungsfenster; die Kosten einer Unterreaktion sind die nächsten 18 Monate Ihrer Karriere.

Härtung: Wie Sie den nächsten Kernel-CVE ohne Feuerwehreinsatz überstehen

Copy Fail wird nicht der letzte Kernel-CVE sein, der RuntimeDefault aushebelt. Sechs Maßnahmen, die Sie dieses Quartal umsetzen können, um den nächsten Fall weniger schmerzhaft zu machen:

• Minimale Kernel-Modul-Angriffsfläche. Blacklisten Sie algif_*, bluetooth, dccp, tipc, sctp, cifs, wenn Sie diese nicht benötigen. Die meisten Workloads tun das nicht.
• Default-Deny-Seccomp für jeden Workload. Machen Sie Localhost-Profile zur Norm. RuntimeDefault ist der Mindeststandard, nicht die Obergrenze.
• Image-basierter Node-Refresh (Talos Linux, Bottlerocket, Flatcar). Atomare Neustarts, unveränderlicher Kernel, problemloser Rollback.
• Runtime-Monitoring. Falco oder Tetragon erkennen unerwartete Syscalls in Echtzeit. Kombinieren Sie das mit Runtime-Observability für KI-Workloads, wo die Syscall-Fläche breiter ist.
• Kurze Kernel-Modul-Ladeereignisse mit Alarm in Ihrem SIEM. Wenn algif_aead jemals auf einem Produktions-Host lädt, der es nicht benötigt, wollen Sie das in Sekunden wissen.
• K8s-Versionen und Node-Images pinnen auf eine Baseline, die Sie aktiv sicherheitstechnisch verfolgen. Floating Tags sind ein zukünftiger Vorfall, der darauf wartet zu passieren.

Das ist die Lehre, die Copy Fail uns erteilt, bevor der nächste kommt. Die Teams, die den nächsten Zero-Day in 30 statt 60 Minuten bewältigen, sind diejenigen, die diese sechs Controls bereits eingeführt haben.

Häufig gestellte Fragen

Bin ich von Copy Fail (CVE-2026-31431) betroffen?

Mit hoher Wahrscheinlichkeit ja, wenn Sie eine der gängigen Linux-Distributionen auf einem Kernel ausführen, der vor dem 1. Mai 2026 veröffentlicht wurde, und unprivilegierten Shell-Zugang erlauben. Das schließt jeden Multi-Tenant-Host, jeden Kubernetes-Worker und jeden CI-Runner ein. Führen Sie uname -r aus und vergleichen Sie mit der Tabelle der gepatchten Versionen oben. CVSS beträgt 7,8.

Ist mein Kubernetes-Cluster auch mit PSS Restricted angreifbar?

Ja. Pod Security Standards Restricted mit seccompProfile.type: RuntimeDefault blockiert socket(AF_ALG, ...) nicht. Juliet.sh hat das direkt getestet: Ein Pod, der mit PSS Restricted plus RuntimeDefault lief, hat den Host-Kernel via Copy Fail übernommen. Sie benötigen ein Localhost-Seccomp-Profil (im K8s-Mitigationsabschnitt oben enthalten).

Blockiert Docker Desktop Copy Fail?

Das Standard-Seccomp-Profil von Docker Desktop verweigert bereits viele Syscalls, blockierte AF_ALG jedoch erst, nachdem moby/moby PR #52501 gemergt wurde. Aktualisieren Sie Docker auf ein Release, das das gepatchte Profil enthält (Docker 29.x Backport), oder wenden Sie das Seccomp-Profil manuell an. Linux-Docker-Installationen ohne dieses Update bleiben angreifbar.

Stoppt seccomp RuntimeDefault das hier?

Nein. RuntimeDefault ist das unveränderte Container-Runtime-Profil (Docker/containerd Standard). Es erlaubt socket(AF_ALG, ...), weil legitime Workloads gelegentlich die Kernel-Crypto-API nutzen. Die Lösung ist ein Localhost-Profil, das AF_ALG explizit verweigert (vollständiges JSON im K8s-Abschnitt), oder ein Upgrade auf den moby/moby-PR-#52501-Standard.

Was, wenn ich den Kernel jetzt nicht neu starten kann?

Die modprobe-Blacklist kombiniert mit einem Localhost-Seccomp-Profil, das socket(AF_ALG, ...) verweigert, reicht bis zum Patch-Zeitpunkt aus. Beide greifen ohne Neustart. Fügen Sie blacklist algif_aead zu /etc/modprobe.d/copy-fail.conf hinzu, führen Sie rmmod algif_aead aus, deployen Sie das Seccomp-Profil und starten Sie beim nächsten Wartungsfenster neu.

Wird Copy Fail bereits aktiv ausgenutzt?

Stand 5. Mai 2026 bestätigt Microsofts Threat-Intelligence-Beitrag keine aktive Ausnutzung in freier Wildbahn, beschreibt den Fehler aber als „trivial weaponizable" angesichts von Xints veröffentlichtem 732-Byte-Exploit. Die Exploit-Primitive-Klasse (Page-Cache-Write via splice) überschneidet sich mit Dirty Pipe (CVE-2022-0847), das innerhalb von Wochen nach der Offenlegung aktiv ausgenutzt wurde.

Betrifft Copy Fail KI/ML-Workloads im Besonderen?

Ja, unverhältnismäßig stark. Self-Hosted Inference (vLLM, sglang, Ollama), Agent-Runtimes, MCP-Server und CI-Builds für ML-Images führen routinemäßig nicht vertrauenswürdigen Benutzercode aus. Jede dieser Komponenten kann — selbst in einem Container auf PSS Restricted — Copy Fail auslösen und den Host übernehmen. GPU-Nodes sind das höchste Risikoprofil, da sie typischerweise multi-tenant sind.

Wie unterscheidet sich Copy Fail von Dirty Pipe?

Beide sind Linux-Kernel-LPEs, die beliebige Page-Cache-Writes erzeugen, aber der Auslöser unterscheidet sich: Dirty Pipe missbrauchte splice() in eine Pipe, Copy Fail missbraucht splice() in einen algif_aead-Socket (AF_ALG). Beide umgehen die Standard-Seccomp-Defaults für Container. Der Unterschied bei Copy Fail: Der AF_ALG-Pfad ist von Pod Security Standards Restricted mit RuntimeDefault aus erreichbar.

Fazit

Copy Fail ist in etwa 60 Minuten behebbar, wenn Sie das Playbook von Anfang bis Ende abarbeiten: modprobe-Blacklist, Kernel-Update, Seccomp-Profil, Verifikation. Der Kubernetes- und KI-Infrastruktur-Aspekt ist das, was diesen CVE von einer gewöhnlichen LPE unterscheidet: PSS Restricted mit RuntimeDefault schützt Sie nicht, und ein einziger kompromittierter Inference-Pod kann den Host übernehmen. Die modprobe-Blacklist kombiniert mit einem Localhost-Seccomp-Profil ist die dauerhafte Verteidigung — auch nach dem Patch.

Sie möchten einen zweiten Blick auf Ihr Incident-Response-Runbook werfen lassen oder eine gehärtete K8s-Baseline, bevor der nächste Kernel-CVE kommt? Sprechen Sie mit Techsy. Wir übernehmen die Plattformhärtung für produktive KI/ML-Stacks.

Zuletzt aktualisiert am 05.05.2026. Wir prüfen den Beitrag am 12.05.2026 auf neue Distro-Advisories.