Drei neue Schwachstellen im universellen Container-Runtime runC – dem De-facto-Standard unter Docker, Kubernetes und anderen OCI-kompatiblen Plattformen – eröffnen Angreifern unter bestimmten Bedingungen die Möglichkeit, Schreibzugriffe auf den Host mit Root-Rechten durchzusetzen. Die Lücken tragen die Kennungen CVE-2025-31133, CVE-2025-52565 und CVE-2025-52881 und werden von den Maintainern als kritisch eingestuft.
Hintergrund: Warum runC für Container-Sicherheit zentral ist
Die Meldung stammt von Aleksa Sarai (SUSE, OCI Board). RunC setzt die Open Container Initiative-Spezifikation um und übernimmt Low-Level-Aufgaben wie das Starten von Prozessen in Namespaces, das Mounten von Dateisystemen sowie die Konfiguration von cgroups. Fehler in diesem Layer wirken systemisch: kompromittierte Isolation an dieser Stelle kann die Schutzwirkung ganzer Plattform-Stacks unterlaufen.
Betroffene Versionen und verfügbare Patches
Laut den veröffentlichten Details betreffen die erste und dritte Schwachstelle alle runC-Versionen, während die zweite seit 1.0.0-rc3 relevant ist. Fixes liegen in runC 1.2.8, 1.3.3 sowie 1.4.0-rc.3 und neuer vor. Administratoren sollten umgehend Aktualisierungen über Distributionen, containerd/Docker Engine oder Kubernetes-Pakete einspielen, da diese runC als Abhängigkeit ausliefern.
Angriffsvektoren, Auswirkungen und realistische Szenarien
Die Ausnutzung zielt auf Container Escape ab: Angreifer können Host-Dateien mit root-Rechten schreiben und so Vertrauensgrenzen durchbrechen. Nach Einschätzung von Industriebeobachtern (u. a. Sysdig) ist dafür in der Praxis die Fähigkeit nötig, Container mit benutzerdefinierten Mount-Optionen zu starten. Dies lässt sich über präparierte Images und Dockerfiles erreichen, die riskante Mount-Kombinationen erzwingen.
Indikatoren für Kompromittierung und Telemetrie-Hinweise
Aktive Exploits in freier Wildbahn sind zum Zeitpunkt der Veröffentlichung nicht bekannt. Gleichwohl sollten Teams auffällige Symlink-Operationen, unübliche Mount-Sequenzen sowie Anomalien beim Kopieren zwischen Container und Host überwachen – typische Begleitmuster bei Versuchen, Isolationsmechanismen zu umgehen.
Sofortmaßnahmen für Docker- und Kubernetes-Umgebungen
1) Patchen ohne Verzögerung. Aktualisieren Sie runC auf 1.2.8/1.3.3/1.4.0-rc.3 oder neuer. Prüfen Sie Updates in Docker Engine, containerd und Kubernetes-Distributionen, da diese die gefixten runC-Versionen integrieren.
2) User Namespaces aktivieren. Setzen Sie User Namespaces standardmäßig ein, damit Container-Root nicht Host-Root entspricht. Die Unix-DAC-Grenzen reduzieren Angriffsfläche und stoppen gängige Eskalationspfade.
3) Rootless-Container bevorzugen. Wo möglich, Container im rootless-Modus betreiben. So bleiben potenzielle Auswirkungen kompromittierter Workloads auf dem Host deutlich begrenzt.
4) Privilegien minimieren. Vermeiden Sie privileged-Pods, beschränken Sie hostPath-Mounts, reduzieren Sie Capabilities (insb. CAP_SYS_ADMIN) und untersagen Sie gefährliche Mount-Optionen. In Kubernetes helfen Pod Security Admission, seccomp-Profile, AppArmor und schreibgeschützte Root-Filesysteme.
5) Beobachtbarkeit und Supply-Chain-Hygiene. Aktivieren Sie Erkennungsregeln für Symlink-Missbrauch und untypische Mounts in EDR/Runtime-Security-Tools. Nutzen Sie Image-Signaturen, SBOMs und Artefakt-Signaturen, um nur geprüfte Images zuzulassen. Orientierung bieten Best Practices von CIS Benchmarks sowie Härtungsleitfäden von NSA/CISA.
Einordnung: Lehren aus früheren Container Escapes
Der Fall erinnert an CVE-2019-5736 in runC, der branchenweit zu strengeren Least-Privilege-Modellen führte. Die aktuellen Findings bestätigen: selbst bewährte Basiskomponenten benötigen kontinuierliche Härtung, zeitnahes Patch-Management und Telemetrie mit Fokus auf I/O- und Mount-Anomalien. In modernen CI/CD- und Kubernetes-Umgebungen ist ein Zusammenspiel aus Technik (Patches, Policies) und Prozess (Reviews, Freigaben) entscheidend, um die residualen Risiken beherrschbar zu halten.
Organisationen sollten jetzt handeln: runC aktualisieren, User Namespaces aktivieren, rootless-Betrieb forcieren und restriktive Ausführungsrichtlinien durchsetzen. Kombiniert mit konsequentem Monitoring und Supply-Chain-Kontrollen lässt sich die Wahrscheinlichkeit erfolgreicher Container-Escapes deutlich verringern – bevor Angreifer die Lücken in Produktionsclustern ausnutzen.
