Docker Engine 29.8.2 : deux failles de sécurité à corriger

Docker Engine 29.8.2 : changements et actions à mener

Docker Engine 29.8.2 est une mise à jour de sécurité, publiée le 30/09/2026, qui corrige deux vulnérabilités exploitables sans accès root : un contournement TLS déclenché par DNS pour les pulls de registre (CVE-2026-92543) et une injection de trames forgées dans les réseaux overlay Swarm chiffrés (CVE-2026-92542). Si vous exécutez votre propre démon Docker, surtout s'il effectue des pulls depuis des registres privés, mettez-le à niveau maintenant ; les deux avis ont été publiés un jour plus tard, le 01/10/2026. Une mise en garde préalable : cette version présente une régression connue sur Swarm, détaillée ci-dessous.

Aucune source ne signale d'exploitation active. L'urgence vient de la facilité avec laquelle ces bugs sont atteignables : aucun ne nécessite d'accès privilégié sur l'hôte cible.

Ce que contient Docker Engine 29.8.2 et pourquoi c'est important

La version est documentée dans les notes de publication officielles, avec la liste des modifications reprise dans la discussion moby/moby #53829. Elle corrige trois CVE :

Mises à jour des composants intégrés : BuildKit v0.33.1, binaires statiques containerd v2.3.6 et runc v1.5.2.

Les sources primaires pour les deux bugs principaux sont les avis GHSA-7cfq-22r6-qp73 et GHSA-6m9p-4h64-m6vh, tous deux publiés le 01/10/2026.

Les deux bugs en un paragraphe

Le premier bug permet à toute partie contrôlant les réponses DNS sur le réseau de forcer votre démon à communiquer avec un registre sans vérifier les certificats, exposant ainsi vos identifiants de registre et ouvrant la porte à la substitution d'images. Le second permet à tout utilisateur non privilégié sur un nœud Linux Swarm de forger des paquets UDP qui seront chiffrés avec les paramètres IPsec d'un réseau overlay et injectés comme trames dans un réseau overlay chiffré, potentiellement sur un autre nœud.

Quel CVE s'applique à quelle configuration

Vous n'avez pas besoin de prêter attention aux trois de manière égale. Si vous n'exécutez pas Swarm, CVE-2026-92542 ne s'applique pas du tout. Si vous effectuez uniquement des pulls depuis des registres publics sur des réseaux que vous contrôlez entièrement, votre exposition à CVE-2026-92543 est limitée mais non nulle. Si vous exécutez des nœuds Kubernetes avec containerd et sans le moteur Docker, la mise à niveau de Docker ne résout rien pour vous ; vous avez besoin de l'avis containerd pour CVE-2026-53493.

CVE-2026-92543 : comment une réponse DNS désactive le TLS pour vos pulls de registre

Selon l'avis, la cause racine réside dans la façon dont le démon décide si un hôte de registre est considéré comme non sécurisé.

Le bug de correspondance loopback, étape par étape

loadInsecureRegistries() définit en dur 127.0.0.0/8 et ::1/128 comme CIDR non sécurisés. Lorsque le démon vérifie si un nom d'hôte de registre est non sécurisé, isCIDRMatch résout toutes les adresses du nom d'hôte et renvoie vrai si l'une d'entre elles tombe dans la liste des CIDR non sécurisés. Ainsi, un ensemble de réponses DNS contenant une seule IP loopback plus une IP contrôlée par l'attaquant suffit à classer l'ensemble du nom d'hôte comme non sécurisé.

Comme le transport se reconnecte au nom d'hôte, la connexion vers l'adresse de l'attaquant saute alors la vérification du certificat et peut retomber sur du HTTP simple.

Exposition des identifiants via X-Registry-Auth

Deux conséquences en découlent. Premièrement, le démon envoie l'en-tête X-Registry-Auth avec chaque pull authentifié, de sorte que ces identifiants arrivent sur l'hôte de l'attaquant avec un certificat invalide et sont divulgués. Deuxièmement, un tag d'image fiable peut être substitué par un manifeste et des couches contrôlés par l'attaquant dans le magasin d'images.

Qui est le plus exposé : les runners CI sur des réseaux partagés ou cloud, les machines de développeurs sur des réseaux non fiables, et tout hôte dont le résolveur, ou le chemin vers celui-ci, n'est pas entièrement fiable.

Pourquoi les configurations split-horizon et les DNS d'entreprise méritent qu'on les examine de plus près

Les configurations split-horizon peuvent légitimement renvoyer des ensembles d'adresses différents selon l'origine de la requête. C'est un fonctionnement normal, pas une attaque. La question à poser est de savoir si un attaquant peut influencer les réponses reçues par votre démon. Si le résolveur de votre démon est à l'intérieur de votre propre réseau et que vous le contrôlez, votre risque est bien plus faible que celui d'un runner CI utilisant le DNS fourni par son fournisseur cloud.

Ce qui ne constitue pas une mitigation, selon l'avis :

• Supprimer les entrées insecure-registries. Les CIDR loopback sont codés en dur.
• Utiliser un certificat CA de confiance pour le registre. Cela n'aide pas si le nom d'hôte peut résoudre vers loopback.
• Le pinning par digest. Défense en profondeur contre la substitution d'images uniquement ; cela ne fait rien contre la divulgation d'identifiants.

CVE-2026-92542 : trames falsifiées dans les réseaux overlay Swarm chiffrés

GHSA-6m9p-4h64-m6vh décrit une faille dans les règles de pare-feu du driver overlay.

La faille de marquage du chiffrement

Les règles iptables qui marquent les datagrammes VXLAN pour le chiffrement correspondent à la fois aux datagrammes authentiques envoyés par le noyau et aux datagrammes falsifiés émis par des processus utilisateur. Tout datagramme UDP provenant de l'espace de noms réseau hôte d'un nœud Linux Swarm, envoyé vers le port du chemin de données Swarm et commençant par un en-tête VXLAN pour le VNI d'un réseau overlay chiffré auquel un conteneur actif est connecté, est chiffré avec les paramètres IPsec de ce réseau overlay.

Résultat : un utilisateur non privilégié sur un nœud Swarm peut facilement injecter des trames Ethernet falsifiées dans un réseau overlay chiffré sur un autre nœud. Le profil CVSS reflète cela : impact élevé sur l'intégrité et la disponibilité, aucun impact sur la confidentialité (CVSS 4.0 6.9, AV:L/PR:L).

Les versions affectées sont <= 25.0.18 et de 26.0.0 à 29.8.1. Corrigé dans 29.8.2 et v25.0.19.

La solution de contournement iptables officielle

L'avis propose une mitigation exacte, empêchant les processus en espace utilisateur d'envoyer des paquets UDP vers le port du chemin de données Swarm :

iptables -I OUTPUT -p udp --dport "$(docker info --format '{{.Swarm.Cluster.DataPathPort}}')" -m owner --socket-exists -j DROP

Si vous n'exécutez pas Swarm, ce CVE ne s'applique pas à vous. Ignorez entièrement cette section.

Vérifiez si vous êtes exposé avant la mise à niveau

Vérifications de version, de CIDR et de DNS

Vérifiez la version du démon, pas celle du client :

docker version --format '{{.Server.Version}}'

C'est la version du serveur qui compte. Vous devez avoir la 29.8.2.

Examinez ensuite ce que le démon classe actuellement comme registres non sécurisés :

docker info --format '{{json .RegistryConfig.InsecureRegistryCIDRs}}'

Si la sortie inclut des plages loopback, c'est attendu (elles sont codées en dur), mais cela signifie que tout nom d'hôte de registre résolvant vers une adresse loopback est traité comme non sécurisé. Pour chaque nom d'hôte de registre dont vous effectuez des pulls, faites une vérification ponctuelle :

getent ahosts "$host"

Attention : les réponses DNS peuvent changer entre les vérifications. Cela confirme si vous étiez vulnérable à ce moment-là, pas si vous l'étiez toujours.

Audit des runners CI et du Docker-in-Docker

Les configurations CI épinglent souvent les versions du moteur ou utilisent des images Docker-in-Docker, et ce sont ces hôtes qui effectuent des pulls authentifiés sur des réseaux non fiables :

grep -rnE "docker:[0-9]+\.[0-9]+|docker-version|dind" .github/ .gitlab-ci.yml

Chaque résultat est un hôte à mettre à niveau ou à mettre à jour.

Quelles CVE s'appliquent à votre configuration

Mitigations provisoires pendant que vous planifiez la mise à niveau

Épinglage des noms d'hôtes de registres et restrictions egress

Pour CVE-2026-92543, l'avis liste deux mitigations : épingler le nom d'hôte du registre à son adresse attendue via un DNS fiable ou une entrée dans le fichier hosts, et restreindre l'accès réseau sortant du démon uniquement aux points de terminaison de registres fiables. L'épinglage via une entrée dans le fichier hosts est le plus rapide à déployer ; le filtrage egress est le meilleur contrôle à long terme dans tous les cas.

Verrouillage du port du chemin de données Swarm

Pour CVE-2026-92542, appliquez la règle DROP iptables owner-match ci-dessus sur chaque nœud Swarm Linux.

Définissez une date de fin pour chaque solution de contournement

Ce sont des mitigations partielles, pas des correctifs. Attribuez une date de fin à chacune dans votre tracker, et considérez la mise à niveau comme la seule remédiation complète. Rappelez une nouvelle fois ce qui ne fonctionne pas : modifier insecure-registries (les CIDRs loopback sont codés en dur), remplacer par une CA fiable, ou compter sur l'épinglage par digest pour protéger les identifiants. Les opérateurs continuent de commettre ces trois erreurs parce qu'elles semblent logiques ; l'avis les exclut explicitement.

Comment mettre à niveau vers 29.8.2 en toute sécurité

Mise à niveau des paquets Debian/Ubuntu

Si vous avez installé depuis le dépôt apt de Docker :

sudo apt-get update && sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin
sudo systemctl restart docker

Mise à niveau des nœuds Swarm un par un

Redémarrez les nœuds workers un par un et confirmez que les services d'overlay chiffrés sont rétablis avant de toucher au nœud suivant. Cela compte plus que d'habitude pour cette version, pour des raisons couvertes dans la section régression ci-dessous.

Binaires statiques et la branche 25.0

Si vous installez depuis des binaires statiques, récupérez les binaires 29.8.2 et redémarrez le démon. Sur la branche 25.0, la correction a été intégrée dans v25.0.19 selon l'avis principal. Des sources secondaires indiquent que le support de sécurité de la ligne 25.0 prendrait fin le 4 décembre 2026, donc planifiez votre sortie de cette branche de toute façon.

N'oubliez pas BuildKit dans les builders séparés

Les builders exécutés via le driver docker-container, les builders distants et les builders Kubernetes exécutent leur propre BuildKit. Ils peuvent rester sous v0.33.1 même après la mise à niveau du moteur. Vérifiez chaque builder séparément.

Checklist post-mise à niveau : cache, identifiants et vérification

Vérifiez que le patch est appliqué partout

• Chaque hôte effectuant des pulls depuis un registre privé affiche 29.8.2 depuis docker version --format '{{.Server.Version}}'.
• Les images des runners CI et les services Docker-in-Docker sont mis à niveau (la sortie grep obtenue précédemment constitue votre liste de tâches).
• Chaque builder buildx affiche BuildKit v0.33.1 ou ultérieur.

Purgez le cache de build compromis

La mise à niveau arrête le nouvel empoisonnement du cache mais n'annule pas l'empoisonnement antérieur. Purgez le cache de build après la mise à niveau, en priorisant les builders partagés qui ont exécuté des builds de PR forkées :

docker builder prune

Décidez de la rotation des identifiants de registre

GHSA-7cfq-22r6-qp73 liste la divulgation d'identifiants via X-Registry-Auth comme impact possible. Les identifiants utilisés par un démon vulnérable effectuant des pulls depuis un registre privé doivent être traités comme potentiellement divulgués. Aucune source n'impose la rotation, donc c'est votre décision, basée sur l'historique d'exposition : si votre démon effectuait des pulls sur des réseaux dont le DNS n'était pas totalement fiable, la rotation est le choix par défaut le plus sûr. Vérifiez ~/.docker/config.json sur vos hôtes runner pour voir quels registres ont des identifiants stockés.

Hôtes containerd uniquement

Comparez les hôtes exécutant containerd sans Docker à l'avis de sécurité propre à containerd pour le CVE-2026-53493.

Et terminez proprement le volet des solutions de contournement : chacune de celles que vous avez appliquées doit recevoir une date de fin ou être supprimée.

Une régression à surveiller : le bug Join/Leave overlay de 29.8.2

Un mot de prudence avant de redémarrer massivement les nœuds Swarm. Cette section provient d'un post-mortem communautaire et du suivi upstream, pas des avis officiels.

Symptômes et cause

Le problème est suivi en amont sous la référence moby/moby#53834 et documenté dans un post-mortem communautaire. Lorsqu'un démarrage de conteneur échoue après l'appel Join du pilote overlay, un double Leave se déclenche et décrémente le compteur d'endpoints par nœud. Après N+1 échecs de ce type, le sandbox overlay est détruit pour les conteneurs sains sur ce nœud, tandis que docker ps continue de les signaler comme actifs. Aucun correctif n'avait été publié au 03/10/2026.

La séquence de contournement

Selon le rapport terrain : corrigez d'abord le démarrage qui échoue (un conflit de port est visible via docker service ps --no-trunc), faites passer à zéro le service en échec, puis systemctl restart docker et redémarrez les conteneurs sans politique de redémarrage.

La conclusion pratique rejoint la procédure de mise à niveau déjà décrite : ne redémarrez pas tous les nœuds Swarm d'un coup. Une mise à niveau rolling, un nœud à la fois, limite le rayon d'impact de cette régression de la même manière que pour la correction du CVE.

Ce que nous ferions en premier

Si vous exécutez Docker sur des serveurs que vous gérez, l'ordre logique est : vérifier docker version --format '{{.Server.Version}}' sur chaque hôte, appliquer la règle iptables sur les nœuds Swarm et épingler les noms d'hôtes de registres sur les runners CI aujourd'hui, mettre à niveau vers 29.8.2 nœud par nœud cette semaine, purger les caches de build, puis décider de la rotation des identifiants. Les solutions de contournement de l'avis vous achètent des jours, pas des mois. La mise à niveau est la correction.

Une précision sur les lectures complémentaires : aucun de nos articles de blog existants ne couvre suffisamment en détail les versions de sécurité de Docker Engine pour y renvoyer ici. Les avis et notes de version mentionnés ci-dessus constituent donc les meilleures références.

Questions fréquentes

Docker Engine 29.8.2 corrige-t-il les problèmes sur les clusters Kubernetes ?

La plupart des nœuds Kubernetes exécutent containerd sans Docker Engine. Une mise à niveau de Docker n'a aucun effet pour eux sur CVE-2026-53493, dont l'avis se trouve dans le dépôt containerd — consultez plutôt les versions corrigées de containerd. CVE-2026-92542 s'applique uniquement à Swarm.

Dois-je faire tourner mes identifiants de registre après avoir appliqué le correctif ?

La divulgation d'identifiants via X-Registry-Auth est une conséquence possible mentionnée pour CVE-2026-92543 ; les identifiants utilisés par un démon vulnérable effectuant des pulls depuis un registre privé doivent donc être considérés comme potentiellement compromis. Aucune source n'impose leur rotation ; prenez votre décision en fonction de savoir si votre démon a effectué des pulls sur des réseaux dont vous ne pouviez pas entièrement faire confiance au DNS.

Mon cache de build est-il sûr après la mise à niveau ?

Non. La mise à niveau empêche les nouveaux empoisonnements du cache mais n'annule pas les empoisonnements antérieurs. Purgez le cache de build, en priorisant les builders partagés ayant exécuté des builds de PR forkées, et vérifiez que chaque builder indique BuildKit v0.33.1 ou une version ultérieure.

Y a-t-il une exploitation active de ces vulnérabilités Docker ?

Aucune source ne signale d'exploitation dans la nature. CVE-2026-92543 n'a pas de score EPSS et ne figure pas dans le catalogue KEV de la CISA, ce qui signifie que la probabilité est inconnue plutôt que faible. L'urgence provient du fait que les exploits ne nécessitent aucun accès privilégié.

Que se passe-t-il si je n'exécute pas Docker Swarm ?

CVE-2026-92542 ne s'applique pas. Votre exposition concerne CVE-2026-92543 (pulls de registre via un DNS que vous ne contrôlez pas) et, sur les hôtes utilisant uniquement containerd, CVE-2026-53493 via l'avis propre à containerd.