Container-Security: Criticals in runc und containerd – Sofortmaßnahmen für Docker- und Kubernetes-Self-Hosting

Drei neue Container-Escape-Schwachstellen in runc, veröffentlicht im November 2025 – und wer einen selbst gehosteten Docker- oder Kubernetes-Stack betreibt, sollte jetzt genau wissen, welche Versionen auf seinen Nodes laufen. CVE-2025-31133, CVE-2025-52565 und CVE-2025-52881 sind kein akademisches Problem: Sie ermöglichen unter bestimmten Bedingungen den Ausbruch aus dem Container auf den Host, mit potenziellem Root-Zugriff.

Was passiert gerade: runc als Single Point of Failure

runc ist die Referenz-Implementierung der OCI-Runtime-Spezifikation. Docker nutzt es, containerd setzt darauf auf, Kubernetes spricht über CRI gegen containerd und damit indirekt gegen runc. Wer glaubt, Kubernetes zu betreiben und nicht von runc-Lücken betroffen zu sein, irrt. Die Schicht zwischen Orchestrierung und Kernel-Isolation ist für fast alle Self-Hosting-Stacks identisch.

Am 5. November 2025 hat ein SUSE-Sicherheitsforscher drei neue Schwachstellen koordiniert offengelegt, analysiert von Sysdig und Orca Security. Alle drei erlauben unter unterschiedlichen Bedingungen einen Container-Escape. Keine aktiven Exploits waren zum Veröffentlichungszeitpunkt bekannt – die Empfehlung zur schnellen Aktualisierung gilt trotzdem, denn das Zeitfenster zwischen Advisory und erstem öffentlichen Proof-of-Concept ist historisch kurz.

Die Fix-Versionen von runc für die 2025er Lücken sind 1.2.8, 1.3.3 und 1.4.0-rc.3. Wer noch auf dem 1.1.x-Branch unterwegs ist, muss zusätzlich mindestens auf 1.1.12 sein – das war bereits der Fix für CVE-2024-21626 vom Januar 2024. Wer den letzten Container-Security-Zyklus ausgelassen hat, hat jetzt also einen doppelten Rückstand.

Die drei neuen CVEs im Detail

CVE-2025-31133: Symlink-Trick über maskedPaths

Diese Schwachstelle missbraucht den Mechanismus, mit dem runc sogenannte maskedPaths implementiert – also Pfade, die im Container unsichtbar gemacht werden sollen, etwa /proc/kcore. Über Symlink-Manipulation lassen sich dabei Host-Dateien read/write in den Container einbinden, obwohl das nicht vorgesehen ist. Betroffen sind laut den Researchern alle bekannten runc-Versionen vor dem Fix.

Der Angriffsvektor setzt voraus, dass ein Angreifer einen Container starten oder einen bestehenden beeinflussen kann. In typischen Self-Hosting-Szenarien mit Traefik als Reverse Proxy, wo Container aus einem eigenen Image-Build laufen, ist das Risiko überschaubar – sofern keine externen Images ungeprüft ausgeführt werden. Anders sieht es aus, wenn Nutzer eigene Workloads auf einem Shared-Homeserver deployen dürfen.

CVE-2025-52565: Race Condition beim /dev/console-Mount

Hier nutzt der Angreifer eine Race Condition beim Mount von /dev/console. Über Symlinks und präzises Timing lassen sich Schreibzugriffe auf kritische procfs-Einträge durchführen, bevor die Security-Mechanismen des Containers aktiv sind. Betroffen ist runc ab Version 1.0.0-rc3. Das ist faktisch jeder produktive runc-Einsatz der letzten Jahre.

Race Conditions sind in der Praxis oft schwerer auszunutzen als direkte Speicherfehler, aber nicht unmöglich. Insbesondere auf stark ausgelasteten Nodes mit vielen parallelen Container-Starts steigt die Erfolgswahrscheinlichkeit. Für einen Kubernetes-Cluster mit automatischem Scheduling ist das ein relevantes Szenario.

CVE-2025-52881: Umleitung von /proc-Writes

Die dritte Lücke ermöglicht es, Schreiboperationen, die für /proc-Einträge gedacht sind, auf beliebige andere Ziele umzuleiten – inklusive /proc/sysrq-trigger. Gleichzeitig werden Linux Security Module (LSM) beim Relabeling umgangen. Auch hier sind laut den Forschern alle bekannten runc-Versionen betroffen. Die technische Analyse von Sysdig zeigt, wie die drei Lücken zusammen eine mehrstufige Eskalation ermöglichen können.

Für Homeserver-Betreiber, die Docker mit --privileged-Containern oder mit weitreichenden Capabilities betreiben, ist CVE-2025-52881 besonders relevant: Die LSM-Umgehung hebelt Schutzmechanismen aus, die man eigentlich als Fallback betrachtet.

Rückblick: CVE-2024-21626 als Lehrstunde

Wer die Container-Security-CVEs des letzten Jahres verfolgt hat, erinnert sich an CVE-2024-21626. runc-Versionen ab 1.0.0-rc93 bis 1.1.11 enthielten ein File-Deskriptor-Leck, über das ein docker exec– oder kubectl exec-Aufruf das Host-Dateisystem zugänglich machen konnte. Fix war runc 1.1.12, veröffentlicht am 31. Januar 2024, sowie containerd 1.6.28 und 1.7.13 und Docker Engine 25.0.2.

Das offizielle GitHub Security Advisory GHSA-xr7r-f8xq-vfvv und der NVD-Eintrag zu CVE-2024-21626 klassifizieren die Lücke als lokal ausnutzbar mit User-Interaktion – kein Remote-Exploit, aber ein Container-Escape mit CVSS-Vektor AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. Der Scope-Wechsel (S:C) macht den Schweregrad deutlich: Der Angriff wirkt sich auf Systeme außerhalb der eigentlich betroffenen Komponente aus.

Die Lektion aus CVE-2024-21626: Wer Docker-Container mit exec-Zugriff für externe Nutzer oder automatisierte CI-Systeme betreibt, hat eine breitere Angriffsfläche als gedacht. Das gilt für Selbsthosting von GitLab Runner, Woodpecker CI oder ähnlichen Build-Systemen direkt auf dem Host.

Verteilung: Welche runc-Version läuft wirklich?

Das ist der Punkt, an dem viele Self-Hoster schlecht dastehen. Die Frage, welche runc-Version aktiv ist, lässt sich mit runc --version klären – aber das beantwortet nicht, ob der Docker-Daemon oder containerd diese Version auch tatsächlich verwendet. In Ubuntu- und Debian-Setups werden runc und containerd als eigenständige Pakete gepflegt. apt show runc zeigt die Paketversion; ob das Paket-Repository den aktuellen Fix bereits enthält, ist distributions- und zeitabhängig.

Arch Linux rollt Security-Updates für Kernpakete typischerweise schnell aus. Ubuntu LTS-Releases sind konservativer; hier lohnt ein Blick auf die Ubuntu Security Notices (USN) für runc und containerd. Fedora und seine Downstream-Derivate liefern Updates über Security Advisories im Bodhi-System. Wer Kubernetes über kubeadm oder ein Managed-Offering betreibt, sollte die jeweilige Plattform-Advisory-Seite prüfen – AWS hat nach eigenen Angaben von Sysdig bereits am 5. November 2025 Updates für ECS/EKS ausgerollt.

Mein persönlicher Eindruck: Die größte Gefahr ist nicht das Exploit selbst, sondern das trügerische Sicherheitsgefühl von Admins, die Docker per apt upgrade aktualisiert haben und glauben, alles sei erledigt. runc ist ein eigenes Paket. containerd ist ein eigenes Paket. Das Docker-Meta-Paket zieht nicht automatisch immer die neueste runc-Version mit.

Konkrete Sofortmaßnahmen für Self-Hosting-Stacks

Schritt 1: Inventur

Auf jedem Node ausführen:

• runc --version – zeigt die aktive runc-Version
• containerd --version – zeigt die containerd-Version
• docker version – zeigt Engine- und runc-Version im Client/Server-Block
• kubectl get nodes -o wide + crictl version auf den Worker-Nodes für Kubernetes-Setups

Zielversionen nach aktuellem Stand: runc mindestens 1.1.12 für CVE-2024-21626, für die 2025er Lücken mindestens 1.2.8 oder 1.3.3. containerd mindestens 1.6.28 bzw. 1.7.13 für CVE-2024-21626; für neuere Advisories die jeweiligen Release-Notes auf containerd.io/security prüfen. Die offizielle Übersicht gibt containerd.io/security mit allen Advisories und Fix-Versionen.

Schritt 2: Paketupdate und Container-Neustart

Nach dem Update von runc und containerd laufen bestehende Container noch unter der alten Runtime, bis sie neu gestartet werden. Das ist der kritische Schritt, den viele überspringen. Alle laufenden Container müssen gestoppt und neu gestartet werden – erst dann nutzen sie die gepatchte Runtime. Bei Docker Compose genügt docker compose down && docker compose up -d. In Kubernetes sollten Deployments gerollt werden: kubectl rollout restart deployment/<name> -n <namespace>.

Bei Stateful-Workloads wie Datenbank-Containern (PostgreSQL, MariaDB, Redis) ist ein koordinierter Neustart nötig. Wer dort einfach docker restart aufruft, sollte sicherstellen, dass kein laufender Schreibvorgang unterbrochen wird – PID-Signale und Shutdown-Timeouts entsprechend konfigurieren.

Schritt 3: Härtung über den Patch hinaus

Updates allein sind reaktiv. Strukturelle Härtung ist langlebiger. Die Empfehlungen aus den Sicherheitsanalysen von Sysdig und Orca Security sind konsistent:

• User-Namespaces aktivieren: Wo möglich (Linux-Kernel ≥ 5.12 mit entsprechender Konfiguration), isoliert das Container-UID-Mappings vom Host und reduziert die Wirkung eines erfolgreichen Escapes erheblich.
• Rootless-Container bevorzugen: Podman läuft defaultmäßig rootless; Docker unterstützt es seit längerer Zeit als Option. Wer nginx oder Traefik rootless betreibt, entzieht einem Angreifer nach einem Container-Escape sofort relevante Rechte.
• Keine --privileged-Container in Produktion: Das ist kein frommer Wunsch, sondern messbare Risikoreduzierung. Capabilities einzeln vergeben, nicht en bloc.
• Nur signierte, verifizierte Images: Kein docker pull random-image:latest auf Produktionssystemen. Docker Content Trust oder Cosign für Image-Verifizierung.
• Runtime-Monitoring: Tools wie Falco überwachen Syscall-Muster und schlagen Alarm, wenn ein Container versucht, auf /proc/sysrq-trigger zu schreiben oder ungewöhnliche Mounts durchzuführen. Das ist die Detektionsebene, die über reine Patch-Hygiene hinausgeht.

Risikobewertung für typische Self-Hosting-Setups

Ein typischer Homeserver-Stack mit Traefik als Reverse Proxy, einigen Web-App-Containern, einer Nextcloud-Instanz und einer Datenbank hat in der Regel eine moderate Angriffsfläche. Entscheidend ist, wer exec-Zugriff auf laufende Container hat. Wenn nur der Admin selbst docker exec ausführt und keine externen Nutzer eigene Workloads deployen können, ist das Risikoprofil für CVE-2024-21626 und ähnliche exec-abhängige Lücken deutlich niedriger.

Anders bei CI/CD-Setups, Gitea/Forgejo mit Runners, oder Self-Hosted-Build-Systemen, wo externe Code-Beiträge automatisch in Containern ausgeführt werden. Hier ist Container-Escape ein realistisches Angriffsszenario, und die CVSS-Bewertungen sind kein Übertreibung. Das gilt auch für Anbieter von Shared-Hosting auf Basis von Container-Isolation – die runc-Lücken treffen genau das Threat-Model, auf dem solche Angebote basieren.

Kubernetes-Cluster im Homelab mit kubeadm sind oft weniger gut gewartet als Cloud-Managed-Angebote. Wer seinen Cluster seit Monaten nicht aktualisiert hat, sollte jetzt nicht nur runc patchen, sondern die gesamte Control-Plane-Version prüfen. Eine veraltete kubelet-Version kann eigene Angriffsflächen mitbringen, die über das aktuelle runc-Problem hinausgehen. Wer die Bedeutung solcher Schwachstellen im breiteren Kontext einordnen möchte, findet im regelmäßig aktualisierten KEV-Katalog der CISA einen nützlichen Referenzpunkt – dort werden aktiv ausgenutzte Schwachstellen gelistet, die priorisiertes Patching erfordern.

Alternative Runtimes und ihre Sicherheitsversprechen

Eine Frage, die bei jeder runc-Lücke lauter wird: Sollte man auf eine alternative Container-Runtime wechseln? gVisor (runsc) von Google und Kata Containers sind die bekanntesten Alternativen, die einen anderen Isolationsansatz verfolgen. gVisor interceptiert Syscalls im Userspace und reicht sie gefiltert weiter; Kata Containers starten jede Workload in einer leichtgewichtigen VM. Beide Ansätze eliminieren nicht alle Angriffsflächen, verkleinern aber den potenziellen Blast Radius eines Container-Escapes erheblich.

Der Wechsel ist allerdings kein trivialer Schritt. Viele Anwendungen setzen Syscalls voraus, die gVisor nicht vollständig unterstützt. Kata Containers benötigen Hardware-Virtualisierung und eine entsprechend konfigurierte Node-Infrastruktur. Für einen typischen Homeserver-Stack, der primär Web-Apps, Datenbanken und Monitoring-Tools betreibt, ist der Migrations-Aufwand meist nicht verhältnismäßig. Sinnvoller ist es, für besonders kritische oder exponierte Workloads – etwa öffentlich erreichbare Build-Runner oder experimentelle Dienste – eine härtere Isolation durch alternative Runtimes zu evaluieren, während der Hauptstack mit gepatchtem runc und struktureller Härtung weiterläuft.

Wer containerd als Basis behält, kann über RuntimeClass in Kubernetes unterschiedliche Runtimes pro Workload definieren. Das erlaubt einen graduellen Ansatz: kritische Pods laufen mit gVisor, Standard-Workloads mit runc. Diese Flexibilität ist einer der Gründe, warum containerd als CRI-Implementierung im Kubernetes-Ökosystem so dominant geworden ist.

Patch-Management als kontinuierlicher Prozess

Wer auf einem einzelnen Advisory reagiert, löst ein konkretes Problem. Wer Patch-Management als Prozess etabliert, verhindert strukturell, dass das nächste Advisory zum Notfall wird. Für Container-Infrastruktur bedeutet das konkret: eine klare Inventur aller Runtime-Komponenten, ein regelmäßiger Abgleich mit den jeweiligen Security-Advisory-Feeds und ein definiertes Zeitfenster, innerhalb dessen kritische Updates eingespielt werden.

Für runc und containerd bieten sich GitHub-Releases mit Benachrichtigungsfunktion an – wer das Repository beobachtet, bekommt neue Releases direkt per E-Mail. Ergänzend lohnt es sich, den RSS-Feed der jeweiligen Distribution für Security Notices zu abonnieren. Ubuntu USN, Debian Security Advisories und Arch Linux Security Advisories liefern alle maschinenlesbare Feeds, die sich in Monitoring-Tools oder einfache Skripte integrieren lassen.

Ein weiterer pragmatischer Schritt ist die Automatisierung der Versions-Prüfung im eigenen Monitoring. Ein einfaches Shell-Skript, das täglich runc --version ausführt und das Ergebnis gegen eine konfigurierte Mindestversion prüft, sendet eine Benachrichtigung, bevor ein Advisory überhaupt die eigene Aufmerksamkeit erreicht. Wer Prometheus und Alertmanager im Stack hat, kann diese Prüfung als Custom-Metric exponieren und in bestehende Alert-Rules einbinden. Das ist kein Hexenwerk – aber es ist der Unterschied zwischen reaktivem Feuerlöschen und proaktiver Sicherheitshygiene.

Warum Container-Security kein Einmal-Projekt ist

CVE-2024-21626 im Januar 2024, CVE-2024-45310 im gleichen Jahr, jetzt drei neue Lücken im November 2025 – alle in runc, alle mit Escape-Potenzial. Das ist kein Zufall und kein Versagen einzelner Entwickler. runc sitzt an der Schnittstelle zwischen Userspace und Kernel-Namespaces, verwaltet Mounts, Symlinks, /proc-Einträge und File-Deskriptoren unter extremen Bedingungen. Die Angriffsfläche ist inhärent komplex.

Der strukturelle Fehler vieler Self-Hosting-Setups ist, Container wie fertige, unveränderliche Infrastruktur zu behandeln. Ein nginx-Container, der seit acht Monaten läuft, ist kein Zeichen von Stabilität – er ist ein Zeichen dafür, dass die Runtime-Version nicht geprüft wurde. Container-Security erfordert die gleiche Update-Disziplin wie klassisches Paketmanagement, plus die zusätzliche Komplexität der gestapelten Komponenten (Image, Runtime, Orchestrierung, Kernel).

Ich halte die Empfehlung für solide: Wer runc, containerd und Docker in separaten Paket-Upgrades trackt, einen automatisierten Check der Runtime-Versionen in sein Monitoring einbaut und Rootless-Container wo immer möglich als Standard setzt, ist strukturell besser aufgestellt als neun von zehn Self-Hosting-Setups, die ich in der Praxis sehe.

Was bleibt und was tun?

Die Fix-Versionen für die aktuellen Lücken liegen vor. Die Distributionen rollen Updates aus. Die eigentliche Frage für jeden Betreiber eines Docker- oder Kubernetes-Stacks lautet jetzt: Wie lange dauert es bei mir vom Advisory bis zum gepatchten System – und weiß ich diese Zahl überhaupt?

Wer das nicht beantworten kann, sollte damit beginnen: runc --version auf jedem Node, Paket-Repository-Stand prüfen, Container nach dem Update neu starten. Danach lohnt sich die Einrichtung eines regelmäßigen Checks – sei es über ein einfaches Skript, das die runc-Version gegen eine Mindestversion validiert, oder über ein vollständiges Container-Security-Scanning im CI/CD-Prozess. Tools wie Trivy machen genau das für Images; für die Runtime-Ebene braucht es eigene Checks oder spezialisierte Monitoring-Lösungen.

Container-Escape-Lücken werden nicht aufhören. runc ist zu zentral für die gesamte Container-Infrastruktur, als dass dieser Angriffsvektor irgendwann verschwindet. Die Frage ist nur, wie schnell man reagiert – und ob man beim nächsten Advisory weiß, wo man anfangen muss.