Top 9 des vulnérabilités de sécurité des conteneurs Docker.

À quand remonte la dernière fois que vous avez examiné en détail les images de conteneurs Docker que vous utilisez ? Car voici la dure vérité : chaque instruction FROM, chaque binaire copié et chaque paquet installé qui compose votre conteneur est un vecteur d'attaque potentiel. 

Cela signifie que si vous n'inspectez pas régulièrement les couches de vos images de conteneurs et les dépendances de compilation, vous héritez probablement de bien plus de risques que vous ne le pensez.

Les CVE (Common Vulnerabilities and Exposures), les images de base non sécurisées, les secrets codés en dur et les privilèges excessifs ne sont que quelques-unes des façons dont les attaquants s'infiltrent. Et cela devrait être une préoccupation pour les organisations comme la vôtre.

En fait, le rapport 2024 de Red Hat sur l'état de la sécurité des conteneurs, qui a interrogé 600 professionnels du DevOps, de l'ingénierie et de la sécurité, a révélé que près de la moitié des équipes (42 %) admettent que la sécurité des conteneurs les empêche de dormir. 

Des vulnérabilités d'exécution des conteneurs aux CVE qui affectent les charges de travail GPU critiques, cet article détaille neuf des vulnérabilités de conteneurs Docker les plus vitales et les plus souvent négligées.

Que sont les vulnérabilités des conteneurs Docker ?

Une vulnérabilité de conteneur Docker est toute faiblesse, mauvaise configuration ou faille au sein d'une image de conteneur, de son environnement d'exécution (runtime) ou de son infrastructure sous-jacente que les attaquants peuvent exploiter pour compromettre la sécurité. Cela inclut à la fois les CVE bien connues et les problèmes négligés comme les configurations par défaut non sécurisées, les secrets exposés ou les privilèges excessifs.

La vitesse et la portabilité qui rendent les conteneurs Docker si puissants pour les développeurs peuvent aussi en faire un cauchemar pour les équipes de sécurité. Par exemple, tirer une image avec le tag « latest » ou exécuter des conteneurs en tant que root peut sembler inoffensif au premier abord. Mais en pratique, ce sont précisément le genre de brèches que les attaquants recherchent.

Une vulnérabilité, en termes simples, est tout élément de votre configuration de conteneur qui facilite la tâche de quelqu'un qui tente de s'introduire.

Dans cette optique, examinons les neuf vulnérabilités de conteneurs Docker les plus courantes et les plus dangereuses auxquelles vous devez faire attention.

Les 9 principales vulnérabilités des conteneurs Docker

Les neuf vulnérabilités suivantes sont des CVE actives et des mauvaises configurations répandues observées dans les environnements de production. Chacune représente une voie de menace pratique pouvant mener à la compromission du conteneur, à l'accès à l'hôte ou au mouvement latéral dans votre infrastructure.

Décortiquons-les.

1. Vulnérabilités d'évasion de conteneurs runC et Docker 

RunC est un runtime de conteneur « de bas niveau » principalement utilisé par des runtimes de conteneurs « de haut niveau » comme Docker pour générer et exécuter des conteneurs. Au fil des ans, nous avons observé plusieurs vulnérabilités d'évasion de conteneurs runC et Docker, qui ont entraîné des attaques. 

Une vulnérabilité majeure, CVE-2019-5736, a été découverte en février 2019. Cette vulnérabilité permettait à un attaquant d'exploiter un déploiement runC exécutant une version de Docker antérieure à 18.09.2 en écrasant le binaire runC de l'hôte, compromettant ainsi l'accès root de l'hôte. 

Bien qu'il s'agisse d'une ancienne vulnérabilité (6 ans en 2025), de nombreuses équipes y sont encore exposées, en particulier dans les environnements avec des versions Docker/runC non patchées ou héritées, des runtimes personnalisés ou forkés, etc. 

Une nuance critique de la vulnérabilité CVE-2019-5736 est qu'elle exige que le processus du conteneur s'exécute en tant qu'utilisateur root. Supposons que les conteneurs s'exécutent en tant que conteneurs non-root (par exemple, avec USER 1000 dans le Dockerfile ou securityContext.runAsNonRoot: true dans Kubernetes). Dans ce cas, les attaquants ne peuvent pas déclencher le chemin d'écrasement car ils n'ont pas les privilèges nécessaires, c'est pourquoi il est important de ne pas exécuter vos conteneurs en tant qu'utilisateur root.  

Depuis 2019, d'autres vulnérabilités d'évasion de conteneurs runC et Docker ont fait surface, certaines de faible gravité et d'autres critiques :

• CVE-2024-21626 : Évasion de conteneur via le process.cwd et les descripteurs de fichiers divulgués de runC. 
• CVE-2024-45310 : Évasion de conteneur permettant de créer des fichiers ou des répertoires vides.
• CVE-2024-23651 : Condition de concurrence sur le cache de montage de Buildkit.
• CVE-2024-23652 : Suppression arbitraire lors du démantèlement de conteneur au moment de la construction de Buildkit.
• CVE-2024-23653 : Vérification des privilèges du SecurityMode GRPC de Buildkit.

La correction de ces vulnérabilités de sécurité nécessite la mise à niveau des conteneurs Docker affectés vers une version corrigée.

NOTE : Si vous n'êtes pas sûr de la version de runC présente dans votre environnement, l'exécution de la commande docker version devrait afficher la version dans sa sortie :

Gravité : Faible → Critique

2. CVE-2025-9074 : Accès non authentifié à l'API Docker Engine depuis les conteneurs de Docker Desktop.

L'API Docker Engine fournit une interface de programmation pour interagir avec le démon Docker et gérer les objets Docker. Elle est présente dans tous les outils Docker, y compris Docker Desktop. 

CVE-2025-9074 est une vulnérabilité critique de type server-side request forgery (SSRF) dans Docker Desktop. Avec cette vulnérabilité, les conteneurs peuvent accéder à l'API Docker Engine via le sous-réseau Docker configuré par défaut à 192.168.65.7:2375, même avec l'« Isolation Améliorée des Conteneurs » activée. De plus, cela est possible que l'option « Exposer le démon sur tcp://localhost:2375 sans TLS » soit activée ou non.

La CVE-2025-9074 n'affecte que les machines macOS et Windows. Bien que la plupart des systèmes de production fonctionnent sous Linux, comme Docker, certains utilisent Windows Server (surtout s'ils nécessitent l'utilisation de conteneurs Windows).

Les attaquants peuvent exploiter cette CVE avec seulement ces trois lignes de code Python ci-dessous :

The code above connects to the Docker daemon via TCP socket and runs a new Alpine container that creates a file exploit and mounts it to the host directory /Users/<username>. With that, when the container writes to the /mnt/exploit file, it writes to host /Users/<username>/exploit. 

Un attaquant peut modifier le script pour faire tout ce que le moteur Docker peut faire, y compris contrôler d'autres conteneurs, en créer de nouveaux, gérer des images, etc.

Si vous utilisez Docker Desktop sur macOS ou Windows, assurez-vous de mettre à jour vers la dernière version, car cette vulnérabilité a été corrigée dans la version 4.44.3.

‍Gravité : Critique 

3. CVE-2022-0847 : Dirty pipe (Évasion du noyau Linux)

La CVE-2022-0847, une vulnérabilité du noyau Linux, provient d'une faille dans la logique pipe_buffer.flags du code de pipe du noyau, qui permet à un acteur malveillant d'écrire dans des fichiers en lecture seule, en contournant des protections comme O_RDONLY et immutable. Ils peuvent ensuite élever leurs privilèges. 

Bien qu'il ne s'agisse pas d'une vulnérabilité spécifique aux conteneurs, elle peut être utilisée depuis un conteneur Linux non privilégié pour écraser des binaires comme /usr/bin/sudo sur l'hôte, injecter des portes dérobées et peut servir à enchaîner des exploits.

La seule correction connue pour cette vulnérabilité est de mettre à niveau vos hôtes Linux vers des versions de noyau corrigées. 

Gravité : Élevée 

4. Images de base non sécurisées

Les images de base sont le fondement de chaque conteneur que vous construisez, et si elles sont vulnérables, votre application l'est aussi. Malheureusement, lors de la création de conteneurs, de nombreuses équipes utilisent encore des tags d'image comme ubuntu:latest ou node:alpine sans se rendre compte que ces tags sont des cibles mouvantes. 

La dernière image utilisée par votre conteneur aujourd'hui pourrait être différente de celle qu'il utilisera demain. Cela peut introduire des vulnérabilités de sécurité inattendues.  

Pour atténuer cette vulnérabilité, pointez vers des versions spécifiques et fiables (par exemple, FROM debian:bullseye-20230912) au lieu d'utiliser des tags comme latest. Et pendant que vous utilisez des versions fiables d'une image particulière, n'oubliez pas de scanner régulièrement à l'aide d'outils comme Aikido Security pour détecter les CVE et les vulnérabilités AutoFix. 

Vous devriez également analyser les images de votre registre de conteneurs pour corriger les vulnérabilités avant qu'elles n'atteignent votre environnement. Aikido peut également s'intégrer et analyser les images de votre registre de conteneurs, qu'il s'agisse de Docker Hub ou de Harbor. 

‍

‍Gravité : Faible → Critique (selon les images de conteneurs et leur utilisation)

5. Accès non restreint à la Socket Docker

Monter le Socket Docker, généralement situé à (/var/run/docker.sock), dans un conteneur est l'une des erreurs de configuration les plus dangereuses dans les environnements conteneurisés. Cela accorde au conteneur un accès complet à l'API Docker Engine, lui permettant de contrôler l'intégralité de l'hôte. Ce n'est pas intrinsèquement mauvais ; cependant, un seul conteneur malveillant pourrait signifier qu'un attaquant a désormais le contrôle de l'ensemble de votre hôte. 

Les équipes montent parfois la Socket Docker pour permettre des builds "Docker-in-Docker" ou à des outils de monitoring de gérer les conteneurs, mais c'est presque toujours un raccourci dangereux. 

Pour atténuer cette vulnérabilité, vous ne devriez jamais monter le Socket Docker dans des conteneurs. Si vous avez besoin de la fonctionnalité Docker-in-Docker, elle doit être isolée dans des environnements de build étroitement contrôlés en utilisant rootless Docker, gVisor, ou Kata Containers. 

Si vous utilisez Kubernetes, vous devriez appliquer les Pod Security Standards ou des politiques d'admission pour empêcher les conteneurs d'accéder aux ressources de niveau hôte comme le Socket Docker. 

Gravité : Critique

6. CVE-2025-23266 : Vulnérabilité NVIDIA AI (Faille d'accès GPU)

L'IA et le ML sont au centre de toutes les discussions depuis un an. C'est parce qu'ils ont changé notre façon de travailler et de vivre en général. 

CVE-2025-23266 est une vulnérabilité d'Escape de conteneur qui affecte le NVIDIA  Container Toolkit et le GPU Operator, qui nous permettent de construire et d'exécuter des conteneurs accélérés par GPU.

Le NVIDIA Container Toolkit utilise des hooks OCI (Open Container Initiative) (scripts ou binaires personnalisés) pour configurer les conteneurs pour l'accès GPU. L'un de ces hooks, enable-cuda-compat, hérite des variables d'environnement du conteneur. Cela ouvre la porte à un attaquant pour créer une image malveillante qui définit LD_PRELOAD pour référencer une bibliothèque partagée malveillante.  

Lorsque le hook privilégié s'exécute, la bibliothèque est chargée sur l'hôte, en dehors du sandbox du conteneur, accordant ainsi à l'attaquant un accès root sur le nœud. 

Dans les clusters GPU multi-locataires, cela crée un risque sérieux de fuite de données inter-locataires et de compromission de nœud.

NVIDIA a publié des versions corrigées des deux composants. La mise à niveau vers Toolkit  v1.17.8  et GPU Operator 25.3.1 ou la désactivation d'un hook optionnel atténue la vulnérabilité.

Gravité : Importante 

7.  Secrets exposés

Le rapport IBM Cost of a Data Breach 2025 révèle que les violations de données causées par des identifiants compromis ont été les plus longues à identifier et à contenir. Avec un coût moyen de violation de données de 4,4 millions de dollars, les organisations ne peuvent pas se permettre d'avoir des secrets exposés. 

Pourtant, ils restent l'une des erreurs les plus courantes commises par les développeurs. Ces secrets incluent des identifiants sensibles tels que des clés API, des mots de passe, des clés de chiffrement, des clés privées, et plus encore, ce qui pourrait permettre aux attaquants d'accéder à des données confidentielles ou de les voler.

Les développeurs peuvent divulguer des secrets dans les conteneurs Docker via :

• Dockerfiles (instructions ENV ou ARG)
• fichiers .env copiés dans les couches d'images, etc. 

Le plus inquiétant est que même après la suppression d'un conteneur, si l'image est toujours présente (ou poussée vers un registre), les secrets peuvent rester accessibles.

Il est fort probable que votre organisation ait divulgué des secrets. Mais que pouvez-vous faire à ce sujet dès maintenant ? 

Eh bien, vous pouvez et devriez :

• Identifier tous les secrets actifs, puis 
• Empêcher que de nouveaux secrets n'atteignent la production. 

Il existe également des solutions qui offrent une fonctionnalité de détection de secrets en temps réel qui peut vous aider à évaluer les risques potentiels liés aux secrets exposés.

‍Gravité : Élevée

8. Vulnérabilités liées aux privilèges des conteneurs

Comme mentionné précédemment, il ne faut pas exécuter les conteneurs en tant qu'utilisateurs root. Bien que cela ne donne pas automatiquement accès à l'hôte, comme vous l'avez vu, cela augmente considérablement le risque d'évasion lorsqu'il est combiné à d'autres vulnérabilités comme CVE-2022-0492 ou à des erreurs de configuration dans les montages de volumes et les capacités. 

Au-delà de l'exécution de conteneurs en tant qu'utilisateurs root, il existe d'autres façons pour un conteneur d'être vulnérable via les privilèges. Ceci est particulièrement vrai lors de l'utilisation d'un orchestrateur de conteneurs comme Kubernetes, qui crée, modifie et supprime automatiquement les conteneurs. 

Avec CVE-2023-2640 et CVE-2023-32629, un attaquant peut utiliser un conteneur privilégié non-root avec un montage de volume pour escalader les privilèges. 

Dans Kubernetes, vous utiliseriez le Security Context pour définir les paramètres de privilèges et de contrôle d'accès pour un conteneur.

Dans le Security Context ci-dessus : 

• runAsNonRoot: true : Garantit que le conteneur ne démarrera pas en tant qu'UID 0
• runAsUser: 1000 : Exécute explicitement le conteneur en tant qu'utilisateur non-root
• allowPrivilegeEscalation: false : Bloque setuid ou toute autre escalade
• capabilities.drop: [ALL] : Supprime toutes les capacités Linux par défaut

La gestion des privilèges et de l'accès des conteneurs nécessite de comprendre le comportement de votre application. Par exemple, si vous n'effectuez aucune écriture sur le disque, alors vous devriez monter tous les volumes associés en lecture seule, réduisant ainsi davantage la surface d'attaque.

Lisez notre guide sur les vulnérabilités d'escalade de privilèges des conteneurs et comment s'en protéger.

Gravité : Élevée → Critique

9. gh0stEdit : Vulnérabilité d'accès basée sur les couches

Les images Docker sont conçues pour garantir que leurs utilisateurs finaux peuvent clairement évaluer et visualiser le contenu d'une image avant de l'exécuter. 

Mais dans le cas de gh0stEdit, cette visibilité n'a pas d'importance. 

Bien que n'étant pas une CVE formelle, gh0stEdit (nom donné par ses chercheurs) décrit une nouvelle vulnérabilité où un attaquant peut manipuler des images Docker (même signées avec Docker Content Trust) sans rompre la signature de l'image ni être détecté par les analyses statiques/dynamiques. 

Figure 1 : Contournement de l'intégrité des images Docker : Couches modifiées, Manifeste inchangé. Source (Hackernoon)‍

Cette manipulation est possible car Docker se concentre sur le manifeste (la recette qui liste les couches d'images et leurs digests), et non sur chaque fichier à l'intérieur de chaque couche. 

Si un attaquant injecte un script malveillant dans une couche, le conteneur s'exécute, contournant le Dockerfile, le processus de build et les vérifications du registre. Il peut se propager silencieusement dans tout votre système. 

La correction et la défense contre gh0stEdit impliquent plusieurs étapes, notamment :

• Toujours reconstruire les images de conteneurs à partir de sources fiables
• Signature et vérification des images de conteneurs avec des outils comme cosign
• L'analyse des vulnérabilités et du contenu avec des outils comme Aikido complète les scanners open source avec des règles personnalisées, comblant les lacunes et révélant les failles de sécurité. 
• Utiliser un contrôleur d'admission pour empêcher l'exécution d'images non signées ou non analysées au sein de votre cluster.

Gravité : Faible → Critique (Selon les images de conteneurs et la surface d'attaque)

Établir une posture de sécurité Docker résiliente

Comme nous l'avons exploré dans cet article, des vulnérabilités telles que les évasions de conteneurs runC, les images de base non analysées, les secrets exposés et les privilèges excessifs peuvent discrètement compromettre l'ensemble de votre environnement. 

Mettre en œuvre une posture de sécurité Docker résiliente signifie aller au-delà des analyses superficielles pour adopter des défenses contextuelles, conscientes de l'exécution et basées sur des politiques, qui détectent et corrigent automatiquement les vulnérabilités. 

Chez Aikido, nous apprécions les projets open source établis comme Trivy, Syft et Grype. Mais nous savons aussi par expérience que les utiliser de manière isolée n'offre pas une très bonne expérience développeur. 

Aikido améliore ces projets avec des règles personnalisées pour combler les lacunes et révéler les failles de sécurité que vous ne pourriez pas trouver autrement. Contrairement à l'enchaînement de divers outils open source, Aikido vous libère de la nécessité de créer un script d'analyse ou de configurer une tâche personnalisée dans votre CI/CD.

Il y a toujours plus à apprendre sur la sécurité Docker. Pour répondre à davantage de vos questions sur la sécurisation de Docker, consultez notre checklist de sécurité Docker sans fioritures pour le développeur soucieux des vulnérabilités. 

Continuer la lecture :
Les 7 principales vulnérabilités Cloud    
Les 10 principales vulnérabilités de sécurité des applications Web que chaque équipe devrait connaître    
sécurité Kubernetes 9 principales sécurité Kubernetes et erreurs de configuration sécurité Kubernetes    
Les principales vulnérabilités de sécurité du code présentes dans les applications modernes    
Les 10 principales vulnérabilités de sécurité Python que les développeurs doivent éviter    
Les principales vulnérabilités de sécurité JavaScript dans les applications Web modernes    
sécurité de la chaîne d’approvisionnement logicielle 9 principales sécurité de la chaîne d’approvisionnement logicielle expliquées