Docker Engine 29.8.2 referme une faille DNS qui désactive le TLS des registres d’images

30 septembre 2026. Docker publie Docker Engine 29.8.2, une version de maintenance qui referme 14 vulnérabilités réparties entre le daemon et BuildKit. 30 septembre 2026. La plus grave, la CVE-2026-92543, laisse une réponse DNS malveillante désactiver la vérification du certificat TLS ou faire basculer en HTTP la connexion vers un registre d’images. 30 septembre 2026. L’éditeur embarque au passage BuildKit v0.33.1, qui corrige 11 failles dont plusieurs d’empoisonnement du cache de build. Pourquoi c’est important : la CVE-2026-92543 ouvre la porte à la substitution d’images — le pire cauchemar d’une chaîne d’approvisionnement logicielle, au cœur même des pipelines CI/CD.

Une réponse DNS qui coupe le TLS du registre

La mécanique tient en une phrase. Le client Docker, quand il résout le nom d’un registre, fait confiance à la réponse DNS reçue pour établir la connexion. La CVE-2026-92543 exploite précisément ce maillon : une réponse DNS forgée peut amener la connexion à sauter la vérification du certificat TLS, ou à retomber en HTTP non chiffré, alors que l’opérateur croit dialoguer avec son registre privé.

Les conséquences sont doubles et se cumulent. D’une part, des identifiants de registre — souvent un jeton d’accès GitLab, GitHub ou un secret de cloud — transitent en clair ou vers un tiers. D’autre part, l’image téléchargée peut être substituée par une image malveillante portant le même nom : le daemon l’accepte et l’exécute comme si de rien n’était.

Le danger est démultiplié par la position de cette faille dans le cycle de vie du code. Un registre est rarement interrogé par un humain : ce sont les runners CI, les clusters et les agents de build qui le sollicitent en continu. Un attaquant en position d’homme du milieu sur le réseau — un Wi-Fi partagé, un fournisseur DNS compromis, un poste du réseau interne — peut donc empoisonner l’approvisionnement d’une image que des dizaines de déploiements vont ensuite consommer.

Le scénario d’attaque, pas à pas

Concrètement, l’attaque se déroule en quatre temps. D’abord, l’attaquant se place sur le chemin de la résolution DNS — un réseau partagé, un routeur compromis ou un fournisseur DNS piraté suffit. Ensuite, il répond à la requête du client avec l’adresse de son propre serveur, en se faisant passer pour le registre légitime. Troisième temps : le client, privé de la vérification TLS ou basculé en HTTP, accepte la connexion et transmet ses identifiants. Enfin, l’attaquant sert une image contrefaite que le daemon stocke puis exécute.

Le point d’entrée le plus banal n’est pas le serveur de production, mais le poste du développeur. Un docker pull lancé depuis un réseau d’entreprise, un Wi-Fi d’hôtel ou un espace de coworking, face à un serveur DNS peu fiable, suffit à déclencher toute la chaîne. Le daemon, une fois la résolution détournée, fait le reste sans que personne ne s’en aperçoive.

La leçon est simple : une supply chain d’images se défend là où elle se résout. Refuser tout registre sans TLS, épingler les digests et signer les images rendent la contrefaçon détectable même quand la résolution DNS a été compromise — le correctif 29.8.2 referme la faille, mais ce sont ces réflexes qui empêchent la prochaine de faire le même trou.

Trois failles dans le daemon, onze dans BuildKit

Docker Engine 29.8.2 ne se résume pas à la CVE-2026-92543. Le daemon corrige deux autres failles, et BuildKit en referme onze.

La CVE-2026-53493 touche la chaîne de tirage d’images côté containerd : un index OCI spécialement construit, avec des descripteurs profondément imbriqués ou démultipliés en éventail, peut provoquer une consommation de CPU et de mémoire sans borne. En clair, un dépôt public piégé peut faire tomber un démon qui tente de le résoudre — un vecteur de déni de service à coût quasi nul.

La CVE-2026-92542 concerne Swarm. Un utilisateur non privilégié d’un nœud pouvait injecter des trames Ethernet forgées dans les réseaux overlay chiffrés des nœuds voisins. La brèche compromet l’isolation du plan de données du cluster, exactement là où l’on attendait le chiffrement.

Le gros du correctif est ailleurs : la mise à jour de BuildKit vers v0.33.1 referme 11 CVE — de CVE-2026-93315 à CVE-2026-93323, plus CVE-2026-93326. Beaucoup sont des dénis de service sur le démon de build : une opération LLB malformée, un Dockerfile ou un .dockerignore surdimensionné, un frontend externe malveillant suffisent à faire planter le daemon ou à épuiser sa mémoire.

L’empoisonnement du cache de build, l’autre maillon faible

Au milieu de cette liste, deux failles méritent une attention particulière parce qu’elles touchent l’intégrité du build, pas seulement sa disponibilité.

La CVE-2026-93317 et la CVE-2026-93318 permettent d’empoisonner le cache de build : un client manipulant l’API LLB de bas niveau, ou une image malveillante, peut y déposer des couches dont le contenu ne correspond pas au digest annoncé. Le cache étant réutilisé d’un build à l’autre, la corruption se propage silencieusement aux builds suivants.

La CVE-2026-93326 s’attaque aux politiques de source : une source de build Git forgée — via un Git bundle ou une URL distante qui ne correspond pas à l’identifiant attendu — peut contourner les règles qui restreignent les dépôts autorisés. C’est une faille d’audit de la chaîne plus que d’exécution : elle laisse construire à partir d’un dépôt que la politique était censée interdire.

Le motif commun est limpide. Là où l’on surveillait la sécurité de l’image finale, ce sont les étapes intermédiaires — résolution DNS, cache, source — qui se révèlent les plus exposées. La supply chain logicielle se défend aux frontières, pas seulement au résultat.

Que patcher et comment vérifier

La mise à jour est sans ambiguïté : monter le daemon à la version 29.8.2, qui tire BuildKit v0.33.1, containerd v2.3.6 et runc v1.5.2 dans ses binaires statiques. Vérifier la version installée puis comparer :

# Version du daemon et du client
docker version

# Version de BuildKit embarquée par le daemon
docker buildx version

# Pousser le daemon vers 29.8.2 sur Debian/Ubuntu (exemple apt)
apt-get update && apt-get install -y docker-ce=5:29.8.2-* docker-ce-cli=5:29.8.2-*

La mise à jour ne suffit pas à neutraliser le risque DNS de la CVE-2026-92543. Deux réflexes structurels la complètent :

• Épingler les digests. Référencer les images par image@sha256:… plutôt que par un tag flottant rend la substitution détectable : le contenu ne peut plus changer sans casser le manifeste attendu.
• Sécuriser la résolution. Forcer le TLS sur les registres, publier les certificats de registre privé dans la configuration du daemon (/etc/docker/certs.d/) et superviser les réponses DNS des hôtes de build.

La CVE-2026-92542 impose, elle, de corriger tous les nœuds Swarm et de revoir les droits des comptes qui y exécutent du code : un utilisateur non privilégié ne doit jamais pouvoir parler au plan de données du cluster.

Verdict

Si vos runners ou votre daemon tirent des images depuis un registre privé, traitez la 29.8.2 comme une mise à jour de sécurité prioritaire : la CVE-2026-92543 transforme n’importe quel intermédiaire réseau en point d’entrée vers votre chaîne d’approvisionnement. Si vous construisez avec BuildKit sur des dépôts sensibles, la mise à jour est tout aussi urgente — l’empoisonnement du cache et le contournement des politiques de source corrompent des builds entiers sans laisser de trace visible. Dans tous les cas, la version est un prérequis, pas une fin en soi : épinglez les digests, forcez le TLS et restreignez les comptes qui touchent au plan de données, sinon la prochaine faille DNS fera le même trou.

Références

• Docker Docs — Docker Engine 29 release notes, 29.8.2 (30 septembre 2026)
• GitHub Advisory — CVE-2026-92543, GHSA-7cfq-22r6-qp73 (moby/moby)
• GitHub Advisory — CVE-2026-53493, GHSA-pg57-6jwg-q645 (containerd)
• GitHub Advisory — CVE-2026-92542, GHSA-6m9p-4h64-m6vh (moby/moby)
• moby/moby — Discussion de version v29.8.2