Docker Engine 29.9.0 corrige cinq failles HTTP/2 héritées de Go et active le lazy-pull par défaut
Le 8 octobre 2026, Docker Engine 29.9.0 met à jour son runtime Go et comble cinq CVE qui permettent à un client HTTP/2 de faire planter le daemon ou d’épuiser sa mémoire, tout en activant le lazy-pull pour les snapshotters distants. Si votre API Docker est joignable depuis le réseau, planifiez la mise à jour ; sinon, profitez-en pour vérifier votre exposition.
8 octobre 2026. Docker publie Engine 29.9.0, une version de maintenance qui vaut surtout pour ses correctifs de sécurité. Cinq CVE. C’est le nombre de failles HTTP/2 comblées par la mise à jour du runtime Go vers la 1.26.9. Client HTTP/2. C’est le seul attaquant nécessaire : il peut faire planter le daemon ou épuiser sa mémoire. Pourquoi c’est important : ces failles vivent dans la pile réseau du daemon, pas dans un plugin exotique, et elles frappent quiconque expose l’API Docker sur le réseau.
Cinq failles HTTP/2, une seule origine
Les cinq vulnérabilités proviennent toutes du runtime Go, corrigées en amont dans Go 1.26.9 puis reprises par Docker Engine. Elles partagent un dénominateur commun : un client HTTP/2 malveillant qui abuse du protocole pour dégrader ou interrompre le daemon.
La liste précise aide à mesurer le risque.
- CVE-2026-97032 — un client peut faire planter le daemon en modifiant la taille de la table HPACK pendant l’envoi des requêtes.
- CVE-2026-78659 — un client peut épuiser la mémoire en déclarant un grand nombre de champs dans un en-tête Trailer, contournant les limites de taille d’en-tête.
- CVE-2026-78663 — un client peut contourner la limite de contrôle de flux de la connexion en réinitialisant les flux, forçant le daemon à mettre en tampon plus de données que prévu.
- CVE-2026-78669 — un client peut provoquer une consommation CPU excessive en ouvrant de nombreux flux et en modifiant répétitivement la taille de fenêtre initiale.
- CVE-2026-56857 — sur Windows, le daemon peut créer un répertoire hors de sa racine de données si un utilisateur disposant d’un accès en écriture y a placé une jonction.
La mise à jour de golang.org/x/net vers la v0.60.0 applique les mêmes correctifs HTTP/2 à l’endpoint déprécié /grpc et au serveur gRPC que BuildKit exécute pour les conteneurs frontaux — par exemple une image référencée par une directive # syntax=.
Qui est réellement exposé
La réponse dépend d’une seule question : où votre API Docker est-elle joignable ? Par défaut, le daemon écoute sur un socket Unix local (/var/run/docker.sock), inaccessible depuis le réseau. Dans ce cas, l’attaquant « non authentifié » des avis n’a aucun chemin vers le code vulnérable.
Le risque bascule dès que l’on sort de ce défaut. Trois configurations dominent chez ceux qui sont exposés.
- Le port TCP 2375 (sans TLS) ou 2376 (avec TLS) ouvert pour les agents de CI/CD, les outils de supervision ou les intégrations tierces. C’est la porte classique.
- Un reverse proxy devant l’API Docker, qui parle HTTP/2 avec le client. Les failles vivent alors dans le chemin HTTP/2 du daemon, quel que soit le proxy.
- Les builds distants qui utilisent
# syntax=pour charger un frontend BuildKit : le serveur gRPC interne reçoit la correction via x/net v0.60.0.
Les deux premières CVE (97032 et 78659) sont les plus préoccupantes, car elles transforment un simple client HTTP/2 en vecteur de déni de service contre le daemon — et donc contre tous les conteneurs qu’il gère.
Le lazy-pull : tirer moins, démarrer plus vite
Au-delà de la sécurité, 29.9.0 introduit un vrai changement d’usage. La fonctionnalité de daemon lazy-pull contrôle si docker pull saute le téléchargement des couches que le snapshotter fournit déjà.
Concrètement, elle est activée par défaut pour les snapshotters distants reconnus — nydus, overlaybd, soci et stargz. Pour ces backends, le contenu n’est rapatrié qu’à la demande, au moment où un conteneur y accède réellement, au lieu d’être téléchargé intégralement au pull. Le gain est double : des pulls plus courts et des démarrages plus rapides sur les images volumineuses.
La version corrige aussi un bug de pull qui sautait des blobs de couche requis quand des couches décompressées existaient déjà, laissant des images exécutables mais incomplètes pour l’export ou le push. Avec le containerd image store, c’est une correction de cohérence importante pour quiconque reconstruit ou redistribue des images.
Les correctifs réseau au passage
Le volet réseau de la version mérite une lecture attentive, car un correctif touche à la confidentialité des overlays chiffrés.
Un bug faisait qu’en cas d’erreur de programmation du chiffrement de l’overlay au niveau du noyau, du trafic pouvait être transmis en clair vers certains nœuds. Le pair destinataire rejetait ces paquets clairs comme falsifiés, si bien que la perte de confidentialité restait limitée aux flux unidirectionnels — par exemple des requêtes DNS UDP — et aux tentatives de handshake qui n’aboutissent pas. Le correctif ferme la fuite.
La version rétablit aussi la suppression de la chaîne iptables vide DOCKER-INGRESS laissée par Engine 28.0.0, libère les associations IPsec quand le dernier conteneur quitte un overlay chiffré, et corrige l’omission des ports publiés dans docker ps pour les réseaux en mode routed gateway. Autant de rustines qui concernent surtout les déploiements Swarm et les réseaux overlay.
Un rythme de correctifs qui s’accélère
Cette version n’est pas un cas isolé : elle prolonge une séquence. La 29.8.2, publiée le 30 septembre 2026, avait déjà refermé une série de failles dans le moteur et dans BuildKit — dont CVE-2026-53493, une image OCI malformée capable de saturer CPU et mémoire, et CVE-2026-92543, une réponse DNS malveillante qui pouvait faire sauter la vérification TLS du registre. La 29.9.0 arrive huit jours plus tard avec un lot comparable, mais centré cette fois sur la pile HTTP/2 du runtime Go.
Ce rythme rapproché change la posture attendue. Un moteur Docker qu’on met à jour « une fois par an » accumule désormais plusieurs vagues de correctifs réseau exploitables à distance. La mise à niveau de 29.8 vers 29.9 est un chemin court — même branche majeure, peu de changements cassants — et elle vaut surtout par les cinq CVE HTTP/2 qu’elle transporte.
Le lazy-pull n’est pas qu’un gain de performance : il réduit aussi la surface de données rapatriées. Avec un snapshotter distant comme stargz ou nydus, le daemon ne télécharge plus des couches entières qu’il n’utilisera peut-être jamais, ce qui diminue la bande passante consommée et le temps d’exposition d’un registre interne. La fonctionnalité s’active par défaut, mais elle suppose le containerd image store : les déploiements restés sur le stockage d’images classique n’en bénéficient pas tant qu’ils n’ont pas migré.
Enfin, il faut noter ce que la version ne fait pas : elle ne retire pas l’endpoint /grpc déprécié, elle le corrige. Les équipes qui l’utilisent encore pour des intégrations héritées doivent planifier sa disparition à terme, mais ne sont pas forcées de migrer en urgence pour être protégées.
Verdict
Si votre daemon Docker écoute sur un socket Unix local et que vous ne publiez pas l’API sur le réseau, les cinq failles HTTP/2 ne sont pas exploitables chez vous : planifiez la mise à jour au prochain cycle de maintenance et activez le lazy-pull si vous utilisez un snapshotter distant. Si vous exposez l’API sur TCP 2375/2376, derrière un reverse proxy HTTP/2, ou si vos builds utilisent # syntax=, traitez 29.9.0 comme une mise à jour prioritaire : un client HTTP/2 non authentifié suffit à faire tomber le daemon, et donc l’ensemble de vos conteneurs. Dans tous les cas, si vous exploitez des overlays chiffrés, appliquez le correctif pour refermer la fuite en clair — même limitée, une confidentialité qui fuit par intermittence est une confidentialité qu’on ne peut pas auditer.