Docker CVE-2026-34040 : contournement AuthZ et accès hôte

Les faits

Le 7 avril 2026, Docker a divulgué CVE-2026-34040, une vulnérabilité de sévérité haute (CVSS 8.8) dans Docker Engine. La faille provient d'un correctif incomplet pour CVE-2024-41110, une vulnérabilité de sévérité maximale dans le même composant découverte en juillet 2024. Le problème réside dans la gestion des corps de requêtes HTTP surdimensionnés : une requête de création de conteneur dépassant 1 Mo est abandonnée avant d'atteindre le plugin AuthZ, contournant ainsi tout contrôle d'autorisation, selon l'advisory Docker.

Un scénario d'exploitation particulièrement préoccupant a été documenté : un agent IA de codage exécuté dans un sandbox Docker peut être piégé par une injection de prompt cachée dans un dépôt GitHub spécialement conçu. L'agent exécute alors du code malveillant qui exploite CVE-2026-34040 pour créer un conteneur privilégié avec montage du système de fichiers hôte. Avec ce niveau d'accès, l'attaquant peut extraire des identifiants cloud et prendre le contrôle de comptes, clusters Kubernetes et serveurs de production.

Impact et exposition

Toute installation Docker Engine utilisant des plugins AuthZ pour restreindre l'accès à l'API Docker est vulnérable. Cela concerne en particulier les environnements multi-tenant, les plateformes CI/CD, et les sandboxes d'exécution de code — y compris celles utilisées par les agents IA. Le vecteur d'attaque via les agents IA est particulièrement dangereux car il ne nécessite aucune interaction humaine : l'agent analyse un dépôt piégé et exécute le payload automatiquement.

Les organisations qui s'appuient sur les plugins AuthZ comme couche de sécurité Docker en production doivent comprendre que cette protection est actuellement contournable. Le correctif dans Docker Engine 29.3.1 corrige la gestion des requêtes surdimensionnées, mais les versions 29.0 à 29.3.0 restent vulnérables.

Recommandations

• Mettre à jour Docker Engine vers la version 29.3.1 immédiatement sur tous vos environnements
• En attendant le patch : ne pas s'appuyer sur les plugins AuthZ comme seule couche de sécurité — restreindre l'accès à l'API Docker aux seuls utilisateurs de confiance
• Exécuter Docker en mode rootless pour limiter l'impact d'une évasion de conteneur
• Auditer les agents IA ayant accès à Docker — s'assurer qu'ils ne peuvent pas exécuter de code arbitraire provenant de sources non vérifiées

Sur le plan technique, la vulnérabilité exploite une divergence entre le serveur HTTP interne de Docker Engine et le point d'interception du plugin AuthZ. Lorsqu'une requête POST /containers/create dépasse le seuil de 1 Mo, le serveur HTTP de Docker tronque le corps de la requête avant de la transmettre à la chaîne de plugins d'autorisation, mais traite néanmoins la requête originale complète au niveau du moteur de conteneurisation. Un attaquant peut ainsi injecter des paramètres sensibles — Privileged: true, montages de type Binds pointant vers /, ou capacités Linux étendues via CapAdd — en les noyant dans un padding qui fait dépasser artificiellement le seuil critique. Le plugin AuthZ, censé inspecter et bloquer ces paramètres, ne voit jamais la requête complète et laisse passer la création du conteneur.

Les versions concernées couvrent l'ensemble des branches de Docker Engine antérieures à la 29.3.1, y compris les déploiements Docker Desktop intégrant un moteur vulnérable. Docker Swarm et les configurations utilisant dockerd exposé via socket TCP sans TLS mutuel sont particulièrement exposés, de même que les plateformes tierces qui s'appuient sur des plugins AuthZ communautaires comme Twistlock/Prisma Cloud AuthZ Broker ou des implémentations maison. Pour la détection, l'analyse des journaux dockerd permet d'identifier les requêtes anormalement volumineuses vers l'API de création de conteneurs : une corrélation entre des tailles de payload supérieures à 1 Mo et des créations de conteneurs privilégiés constitue un indicateur de compromission fort. Des règles de détection basées sur SIEM peuvent être construites autour de cette signature, en complément d'un audit des conteneurs actifs recherchant des montages inattendus du système de fichiers hôte ou des capacités Linux non justifiées par le cas d'usage.

La mitigation immédiate recommandée par Docker, en l'absence de mise à jour possible, consiste à imposer une limite stricte de taille de requête au niveau du reverse proxy ou du load balancer placé devant le socket API Docker, avant même que la requête n'atteigne dockerd. Cette approche défensive en profondeur reste toutefois un palliatif : seule la mise à jour vers Docker Engine 29.3.1 corrige la faille de traitement à la source. Les équipes doivent également revoir la configuration de leurs pipelines DevSecOps pour s'assurer qu'aucun sandbox d'exécution de code — notamment ceux utilisés par des agents IA autonomes avec accès à l'API Docker — ne contourne les contrôles réseau mis en place autour du démon Docker.