Docker corrige une exécution de commandes via le checkout Git de BuildKit et cinq autres failles de build
Le 16 juillet 2026, Docker Engine 29.6.2 a corrigé cinq vulnérabilités de BuildKit, dont la CVE-2026-15793 qui permet d’exécuter des commandes sur l’hôte lors du checkout d’une source Git malveillante, puis la CVE-2026-17106 a été corrigée dans la 29.7.0. Les pipelines qui construisent à partir de sources non maîtrisées doivent mettre à jour Engine, Buildx et BuildKit sans attendre.
16 juillet 2026. Docker publie Engine 29.6.2 et corrige cinq vulnérabilités de BuildKit, son moteur de construction d’images. 30 juillet 2026. La 29.7.0 corrige à son tour la CVE-2026-17106, une traversée de chemin dans la décompression d’archives. 5 août 2026. La 29.7.2 clôt la vague avec des correctifs de régression. En trois semaines, la surface d’attaque du docker build s’est refermée sur six failles dont une exécution de commandes atteignable depuis une simple source Git.
La faille qui compte : une commande injectée via le checkout Git
La CVE-2026-15793 est la plus préoccupante du lot. Elle touche BuildKit : un frontend personnalisé ou un client utilisant l’API bas niveau peut activer git.checkoutbundle=true lors du checkout d’une source Git. Si cette source est malveillante, le mécanisme aboutit à une invocation de commande fabriquée sur l’hôte.
Classée CWE-88, elle affiche un score CVSS 4.0 de 7.3 et un niveau high. Le vecteur résumé par le NVD est sans ambiguïté : la complexité d’attaque est low, la portée se limite à la victime, mais l’impact sur confidentialité, intégrité et disponibilité est high. Autrement dit, la faille ne demande pas de privilèges particuliers — seulement qu’un build se fasse à partir d’une source Git contrôlée par l’attaquant.
La nuance opérationnelle est importante. Le déclencheur n’est pas un Dockerfile anodin : il faut un frontend ou un client qui active explicitement l’optimisation bundle du checkout. Mais cette optimisation est précisément ce que des pipelines CI/CD activent pour accélérer les clones. La frontière entre « cas d’école » et « pipeline réel » est plus fine qu’elle n’en a l’air.
Pourquoi le « frontend » et l’API bas niveau comptent
Pour mesurer la portée de ces failles, il faut saisir l’architecture de BuildKit. Le démon buildkitd sépare deux mondes : le frontend, qui traduit un Dockerfile en instructions de bas niveau, et le solveur, qui les exécute via des workers. Entre les deux circule l’API bas niveau LLB, le langage interne que la plupart des développeurs ne voient jamais.
Les cinq failles corrigées en juillet vivent précisément dans cette frontière. Elles ne supposent pas un Dockerfile piégé au sens classique ; elles supposent un client ou un frontend capable de parler directement à buildkitd. Or c’est exactement ce que font les pipelines avancés : un runner qui invoque un frontend personnalisé, un client distant qui envoie des instructions LLB à un démon partagé, ou un service de build mutualisé. Plus l’outillage s’industrialise, plus cette surface est réellement atteignable.
Quatre autres failles BuildKit, toutes de niveau high
La 29.6.2 ne corrige pas une seule faille. Elle en embarque cinq, toutes classées high, et leur variété dit quelque chose de la maturité de la cible :
- CVE-2026-15792 — CVSS 7.5 : un client ou un frontend malveillant fabrique une requête qui fait paniquer le démon BuildKit. Un déni de service réseau sans authentification.
- CVE-2026-15791 — CVSS 7.5 : un message forgé dans l’API bas niveau supprime le contenu du répertoire
/tmp. Une opération censée rester dans le rootfs du conteneur de build s’échappe vers le répertoire temporaire réel de l’hôte. - CVE-2026-15789 — CVSS 7.5 : une requête d’upload forgée fait sortir des fichiers du répertoire d’état contrôlé par BuildKit.
- CVE-2026-15788 — CVSS 7.5 : sur les workers WCOW (Windows), le sélecteur de cache
source=ne détecte pas les jonctions NTFS placées dans la racine du cache ; un build écrit par un utilisateur non fiable lit des fichiers arbitraires de l’hôte.
Trois de ces cinq failles relèvent de CWE-22 (traversée de chemin) ou CWE-59 (lien non maîtrisé). Le schéma est constant : la frontière entre le monde du build et le monde de l’hôte est plus poreuse que les opérateurs ne le croient.
La CVE-2026-17106 : la décompression d’archive qui s’échappe
La CVE-2026-17106, corrigée dans Engine 29.7.0, frappe plus large encore. Elle vit dans moby/go-archive, la bibliothèque de décompression partagée par l’écosystème Moby. Ses routines — Unpack, UnpackLayer, Untar — décident de la destination de chaque entrée d’archive par des comparaisons de chaînes lexicales, puis laissent le système d’exploitation résoudre le chemin. Les liens introduits par l’archive peuvent donc être suivis hors du répertoire de destination.
Conséquence : un attaquant qui contrôle le contenu d’une archive — une image, un contexte de build, une couche — peut créer ou écraser des fichiers à des chemins arbitraires accessibles au processus qui extrait. Le NVD la note CVSS 4.0 de 7.1, high, avec une publication au 18 août 2026. Elle touche le docker build autant que le docker pull d’une image compromise.
Ce que la séquence révèle sur le build comme surface d’attaque
Ces six failles ont une leçon commune. Pendant des années, le pipeline de build a été traité comme un détail d’infrastructure, moins surveillé que la production qu’il alimente. Or le build est l’endroit où du code non maîtrisé — dépendances, sources Git, images de base — rencontre un démon privilégié sur l’hôte.
La concentration des correctifs en juillet n’est pas un hasard. BuildKit est devenu le moteur par défaut de Docker et le socle de la plupart des plateformes de construction, de GitHub Actions aux runners auto-hébergés. Ce qui s’y corrige se répercute partout, et ce qui y reste vulnérable aussi. Un runner CI qui exécute des builds depuis des forks publics est, structurellement, un poste avancé de la supply chain.
La version des correctifs compte. Ils vivent dans BuildKit lui-même ; Docker Engine 29.6.2 les intègre, mais un démon buildkitd autonome, un Docker Buildx embarqué dans un runner ou un Docker Desktop non mis à jour continuent de porter la faille. Vérifier la version d’Engine ne suffit donc pas.
Le contexte de 2026 renforce la leçon. L’incident tj-actions, qui a exposé des secrets CI/CD à travers des dizaines de milliers de dépôts, puis la feuille de route sécurité d’Actions publiée par GitHub, ont installé le build comme cible de premier plan. Dans ce paysage, une faille qui transforme une source Git en exécution de commandes sur le runner n’est plus une curiosité de laboratoire : c’est l’étape intermédiaire d’une chaîne de compromission qui vise les secrets, puis la production.
Ce qu’il faut vérifier, concrètement
La première étape est de connaître les versions réellement utilisées par le pipeline, pas seulement celle installée sur la machine du développeur :
docker version --format '{{.Server.Version}}'
docker buildx versionUn runner CI/CD hébergé sur une image ancienne peut tirer une version de Buildx bien antérieure à la correction. La remontée de version passe par l’image du runner, pas par le dépôt applicatif.
Ensuite, traiter les sources de build comme non fiables. Ne pas construire à partir de sources Git non auditées avec l’optimisation bundle active, isoler les builds de forks publics dans des runners dédiés, et appliquer les mises à jour d’Engine et de BuildKit dans la même fenêtre que les correctifs de production. Un build compromis aujourd’hui est une image signée qui se déploie demain.
Verdict
Si vos builds partent de sources internes auditées et que vos images de base sont épinglées, la mise à jour vers Engine 29.7.2 et un Buildx/BuildKit à jour suffit à refermer la surface — faites-la dans la fenêtre de patch habituelle.
Si votre pipeline construit à partir de forks publics, de dépendances tierces ou de sources Git non maîtrisées, traitez ces six failles comme un déclencheur de refonte : isolez les runners, désactivez le checkout bundle tant que la correction n’est pas partout, et mettez à jour Engine, Buildx et tout démon buildkitd autonome. La commande qui construit votre image est devenue un vecteur d’exécution de code comme un autre.