Les vulnérabilités récemment divulguées dans runC placent les environnements conteneurisés en état d’alerte maximale : des chercheurs avertissent que des attaquants pourraient potentiellement s’échapper de conteneurs Docker et Kubernetes et obtenir un accès root à l’hôte.
Les failles — suivies sous les identifiants CVE-2025-31133, CVE-2025-52565 et CVE-2025-52881 — affectent presque toutes les versions de runC et reposent sur des conditions de course ainsi que sur la manipulation des montages, ce qui compromet les mécanismes fondamentaux d’isolation des conteneurs.
« En exploitant des conditions de course lors des montages et des redirections d’écriture de procfs, un attaquant pourrait obtenir un accès root au système hôte », ont déclaré les chercheurs de Sysdig.
Pourquoi runC est important
runC sert de moteur bas niveau à de grandes plateformes de conteneurs, notamment Docker, Kubernetes et de nombreux services cloud gérés de conteneurs.
Toute faiblesse dans runC peut se répercuter sur l’ensemble de l’écosystème des conteneurs et affecter les organisations qui s’appuient sur ces outils pour leurs charges de production, leurs pipelines CI/CD et leurs applications cloud natives.
Au cœur des vulnérabilités de runC
Les trois vulnérabilités concernent la manière dont runC gère les chemins masqués, les cibles de montage et les écritures dans procfs — autant d’éléments susceptibles d’être manipulés dans certaines conditions de course.
CVE-2025-31133 – Exploitation de maskedPaths au démarrage du conteneur
Cette faille découle de l’utilisation par runC de /dev/null pour masquer des fichiers sensibles de l’hôte.
Comme runC ne vérifie pas correctement que /dev/null est légitime, les attaquants peuvent le remplacer par un lien symbolique pendant l’initialisation.
Cela permet de monter arbitrairement des chemins de l’hôte dans le conteneur, ce qui autorise l’écriture dans des fichiers tels que /proc/sys/kernel/core_pattern, un vecteur connu d’évasion de conteneur.
CVE-2025-52565 – Conditions de course dans la gestion du montage de /dev/console
Lors de la configuration du conteneur, runC monte un périphérique pseudo-terminal sur /dev/console.
Les attaquants qui manipulent les cibles de montage à l’aide de liens symboliques peuvent rediriger ce montage avant l’activation des protections de sécurité.
Cette vulnérabilité temporelle expose des entrées procfs protégées, permettant une nouvelle fois de s’échapper du conteneur.
CVE-2025-52881 – Redirection arbitraire des écritures dans /proc
Peut-être la plus dangereuse des trois, cette vulnérabilité permet aux attaquants de rediriger les écritures de runC vers des fichiers arbitraires grâce à des techniques de montage partagé.
Les attaquants peuvent contourner les étiquettes des modules de sécurité Linux et forcer runC à écrire directement dans des emplacements dangereux tels que /proc/sysrq-trigger, ce qui peut provoquer des plantages du système ou une élévation de privilèges.
Les chercheurs de Sysdig soulignent que l’exploitation de ces failles nécessite généralement de pouvoir lancer des conteneurs avec des configurations de montage personnalisées, ce qui fait des images de conteneurs malveillantes et des Dockerfiles frauduleux les vecteurs d’attaque les plus probables.
Mesures essentielles pour protéger les conteneurs
Les organisations qui souhaitent réduire leur exposition aux vulnérabilités de runC devraient adopter une stratégie de sécurité en couches, fondée sur la défense en profondeur, pour sécuriser leurs environnements de conteneurs.
Ces mesures contribuent à améliorer l’isolation, à détecter les activités suspectes et à renforcer la sécurité globale de la chaîne d’approvisionnement des conteneurs.
- Mettez runC à jour vers la version 1.2.8, 1.3.3, 1.4.0-rc.3 ou une version ultérieure, et appliquez toutes les mises à jour correspondantes des fournisseurs, notamment celles de plateformes comme AWS ECS/EKS.
- Activez les espaces de noms utilisateur et privilégiez les conteneurs pour limiter l’accès aux fichiers procfs sensibles et réduire l’impact d’une évasion.
- Limitez les opérations privilégiées en désactivant le mode privilégié, en supprimant les capacités Linux dangereuses et en bloquant les montages personnalisés ou hostPath au moyen de contrôles d’admission.
- Appliquez des politiques de sécurité telles qu’AppArmor, SELinux, Seccomp et les Kubernetes Pod Security Standards afin de limiter l’accès au système de fichiers, les appels système et le comportement des montages.
- Surveillez les activités suspectes , notamment la création de liens symboliques, les opérations de montage inhabituelles et les écritures inattendues dans /proc.
- Renforcez la sécurité de la chaîne d’approvisionnement en analysant les images, en imposant la signature et la vérification des images et en limitant l’utilisation d’images ou de Dockerfiles non fiables.
Bâtir une véritable cyber-résilience exige d’aller au-delà de l’application de correctifs, en combinant des contrôles en couches pour se protéger contre les menaces émergentes.
La nouvelle réalité des menaces visant la sécurité des conteneurs
Ces vulnérabilités mettent en évidence un défi systémique plus large : à mesure que les environnements cloud natifs se développent, même des composants fondamentaux comme runC peuvent devenir des points uniques de défaillance.
Les failles permettant de s’échapper des conteneurs montrent que les attaquants ciblent de plus en plus la couche d’exécution et les points d’entrée de la chaîne d’approvisionnement, notamment au moyen d’images non fiables et de workflows CI/CD.
Ces risques montrent clairement que sécuriser le runtime des conteneurs ne représente qu’une pièce du puzzle et soulignent directement la nécessité d’une approche DevSecOps plus robuste et mieux intégrée couvrant l’ensemble du pipeline de livraison logicielle.