Runtime achter Docker en Kubernetes bevat drie kwetsbaarheden
In dit artikel:
De Amerikaanse National Vulnerability Database meldt drie nieuwe kwetsbaarheden in runC — de container-runtime die als referentie-implementatie van de Open Container Initiative wordt gebruikt door onder meer Docker en Kubernetes. Het gaat om CVE-2025-31133, CVE-2025-52565 en CVE-2025-52881. Door manipulatie van mounts en symbolische links (symlinks) kunnen aanvallers de scheiding tussen container en hostsysteem doorbreken en mogelijk code met root‑rechten op de host uitvoeren.
De problemen zijn ontdekt door SUSE‑ontwikkelaar en OCI‑bestuurslid Aleksa Sarai. In bepaalde situaties vertrouwt runC op tijdelijke bind‑mounts (bijvoorbeeld van /dev/null of /dev/console) om gevoelige paden te verbergen. Als een aanvaller tijdens de containerinitialisatie een symlink plaatst of profiteert van racecondities, kan runC per ongeluk een door de aanvaller gekozen doel mounten. Dat opent de deur naar schrijfbewerkingen in kritieke paden zoals /proc en andere kernelinterfaces, en daarmee tot een volledige container‑escape.
Volgens NVD zijn CVE-2025-31133 en CVE-2025-52881 universeel en treffen ze alle runC‑versies; CVE-2025-52565 heeft betrekking op versies vanaf 1.0.0-rc3. De fouten zijn opgelost in runC 1.2.8, 1.3.3 en 1.4.0-rc.3 (en latere releases). Onderzoekers van Sysdig en berichtgeving door BleepingComputer wijzen erop dat misbruik theoretisch mogelijk is via gemanipuleerde Docker‑images of aangepaste containerconfiguraties, maar dat een exploit niet triviaal is omdat de aanvaller de mogelijkheid moet hebben containers te starten met specifieke mountopties.
Sysdig adviseert te letten op verdachte symlink‑activiteit tijdens het opstarten van containers en logs/auditdata hierop te monitoren. Tot dusver zijn er geen aanwijzingen dat deze kwetsbaarheden in het wild worden uitgebuit, maar vanwege de eenvoudige architectuurlaag en de hoge privileges van runC is het risico aanzienlijk.
Aanbevelingen: upgrade zo snel mogelijk naar de gepatchte runC‑versies; schakel waar mogelijk extra mitigaties in zoals user namespaces (zodat root binnen de container niet automatisch root op de host wordt) en overweeg rootless containers om de impact van een eventuele exploit te beperken.