Une vulnérabilité de Docker Engine permet aux attaquants de contourner les contrôles d’autorisation et d’obtenir potentiellement un accès complet aux systèmes hôtes.
Des chercheurs de Cyera ont découvert que la faille affecte un mécanisme de sécurité central sur lequel les organisations s’appuient pour appliquer les politiques relatives aux conteneurs.
« Cette étude montre qu’une grande partie des infrastructures fondamentales continuent de présenter d’anciennes catégories de vulnérabilités dans des environnements désormais très proches des données sensibles et des flux de travail privilégiés », ont déclaré les chercheurs de Cyera dans un e-mail adressé à eSecurityPlanet.
Ils ont ajouté : « Elle montre également qu’il ne s’agit pas d’un problème propre à Docker. Nous continuons de voir des vulnérabilités familières de la classe OWASP dans des infrastructures auxquelles les entreprises confient désormais des agents d’IA, des pipelines de données et des accès aux environnements de production. »
CVE-2026-34040 au cœur de la faille
La vulnérabilité CVE-2026-34040, concerne toute organisation qui utilise Docker avec des plugins d’autorisation (AuthZ) activés — une configuration courante dans les environnements d’entreprise où des outils comme OPA, Prisma Cloud ou des politiques personnalisées servent à appliquer la sécurité des conteneurs.
Compte tenu de l’adoption très répandue de Docker dans les infrastructures cloud et les pipelines de développement, l’exposition potentielle est importante.
Pour aggraver le risque, la faille sous-jacente existe depuis près d’une décennie et affecte des versions remontant jusqu’à Docker Engine 1.10.
Contrôles d’autorisation de Docker
À haut niveau, cette vulnérabilité affaiblit une couche essentielle de la sécurité des conteneurs, sur laquelle les organisations s’appuient pour appliquer les politiques au moment de l’exécution.
Les plugins d’autorisation jouent un rôle central dans ce modèle : ils agissent comme des gardiens qui évaluent les requêtes et les approuvent ou les refusent en fonction de règles de sécurité définies.
Ces contrôles sont censés empêcher les actions à haut risque — comme le lancement de conteneurs privilégiés, le montage de systèmes de fichiers hôtes sensibles ou l’octroi d’un accès à des ressources système critiques — et ainsi réduire la surface d’attaque.
Cependant, cette vulnérabilité permet de contourner silencieusement ces contrôles, sans générer d’alerte ni d’indicateur évident d’échec — créant de fait un angle mort dans des programmes de sécurité pourtant matures.
Fonctionnement de la vulnérabilité
Classée comme un contournement de l’autorisation et assortie d’un score CVSS de 8,8, la faille provient d’un traitement incohérent des corps des requêtes HTTP au sein de l’architecture de Docker.
Lorsqu’une requête d’API dépasse 1 Mo, le middleware de Docker tronque silencieusement son corps avant de le transmettre au plugin d’autorisation.
Malgré cela, le daemon Docker continue de traiter la requête complète et non modifiée, créant une incohérence critique entre ce qui est évalué du point de vue de la sécurité et ce qui est finalement exécuté.
Cette divergence crée une inadéquation dangereuse : le plugin d’autorisation évalue ce qui semble être une requête vide et l’approuve, tandis que le daemon exécute la charge utile complète.
Un attaquant peut exploiter ce comportement en remplissant une requête au-delà du seuil de 1 Mo, neutralisant ainsi les mécanismes de sécurité.
Il peut ainsi créer des conteneurs privilégiés, monter le système de fichiers de l’hôte et accéder à des données sensibles telles que des identifiants cloud, des clés SSH ou des fichiers de configuration Kubernetes.
L’attaque elle-même est simple et fiable. Elle ne nécessite qu’une seule requête HTTP spécialement conçue et ne dépend ni de conditions de concurrence, ni d’un enchaînement complexe, ni de techniques avancées.
Comme elle exploite le comportement standard de l’API Docker, son exploitation est à la fois pratique et difficile à détecter dans des environnements réels.
Lien avec les vulnérabilités antérieures de Docker
Fait notable, cette vulnérabilité s’appuie sur un problème divulgué précédemment, CVE-2024-41110, qui concernait un contournement similaire impliquant des corps de requête de longueur nulle.
Si ce correctif a résolu un cas particulier, il ne tenait pas compte des charges utiles surdimensionnées — laissant cette condition de dépassement exploitable.
Docker a depuis publié un correctif pour résoudre le problème.
Comment réduire les risques liés à Docker
Les organisations doivent adopter une approche en profondeur pour réduire les risques liés à cette vulnérabilité. En plus de l’application des correctifs, plusieurs mesures de configuration, de surveillance et de contrôle des accès peuvent contribuer à renforcer la sécurité globale des conteneurs.
- Appliquer un correctif en mettant à niveau vers la dernière version de Docker Engine et de Docker Desktop afin d’éliminer le contournement de l’autorisation.
- Restreindre et sécuriser l’accès à l’API Docker par la segmentation du réseau, les pare-feu, et des contrôles d’authentification robustes.
- Auditer les environnements pour repérer l’utilisation de plugins d’autorisation et réduire autant que possible leur utilisation ou appliquer les contrôles en amont.
- Surveiller les signes d’exploitation en consultant les journaux Docker et en déployant une détection à l’exécution pour des conteneurs et les comportements anormaux.
- Mettre en place des mesures compensatoires, comme des limites de taille des requêtes sur les reverse proxies et des proxys pour les sockets de conteneurs si l’application du correctif est retardée.
- Renforcer les configurations de l’hôte et des conteneurs en utilisant Docker sans privilèges root, en appliquant le principe du moindre privilège et en réduisant au minimum les données sensibles stockées sur les hôtes.
- Tester les plans de réponse aux incidents et utiliser des outils de simulation d’attaques avec des scénarios portant sur l’exploitation de conteneurs et la compromission d’hôtes.
Ensemble, ces mesures aident les organisations à renforcer leur résilience face à l’exploitation tout en limitant l’ampleur potentielle des dommages en cas de compromission.
Nouveaux risques dans les environnements pilotés par l’IA
Cette vulnérabilité illustre la manière dont de petites incohérences dans le traitement des données par les systèmes peuvent affaiblir des contrôles de sécurité pourtant fiables.
Elle reflète également l’évolution de la façon dont les risques peuvent apparaître, alors que les systèmes automatisés et les outils pilotés par l’IA interagissent de plus en plus avec les infrastructures.
Dans certains cas, ces outils peuvent identifier et exploiter involontairement des faiblesses en tentant d’accomplir des tâches courantes, élargissant ainsi l’éventail des expositions potentielles au-delà des acteurs traditionnels de la menace.
Ces risques en évolution renforcent la nécessité de solutions zero trust, qui ne présupposent aucune confiance implicite et vérifient en continu les accès à l’ensemble des systèmes et des charges de travail.