BIND 9 corrige 14 failles dont un crash DNS-over-HTTPS non authentifié en une seule requête
Le 16 septembre 2026, l’ISC a publié BIND 9.20.29 et 9.21.26 pour corriger 14 vulnérabilités, dont CVE-2026-77692 qui permet de faire planter named avec une seule requête DNS-over-HTTPS malformée. Inventoriez chaque résolveur, corrigez et rendez la résolution redondante avant qu’un seul paquet ne mette votre plateforme à terre.
16 septembre 2026. L’Internet Systems Consortium publie BIND 9.20.29 et 9.21.26 pour corriger 14 vulnérabilités dans le serveur DNS le plus déployé d’Internet. CVE-2026-77692. Un attaquant non authentifié fait planter le processus named avec une seule requête DNS-over-HTTPS malformée. 7,5 sur l’échelle CVSS. Pourquoi c’est important : le DNS est la dépendance sous toutes les autres dépendances, et une requête forgée suffit à l’arrêter.
Ce que l’ISC a divulgué
BIND 9 est l’implémentation open source de référence du DNS, maintenue par l’Internet Systems Consortium. Son démon named répond aux requêtes qui transforment les noms d’hôtes en adresses IP. Parce que des fournisseurs d’accès, des hébergeurs, des entreprises et des fabricants d’appliances l’exploitent partout, un défaut ne reste jamais confiné à un seul réseau : il se propage à tout ce qui résout un nom en aval.
Le 16 septembre 2026, l’ISC a diffusé une mise à jour de sécurité coordonnée couvrant 14 CVE, avec sept failles de gravité élevée (CVSS 7,5) et sept de gravité moyenne. BIND 9.20.29 corrige les quatorze ; 9.21.26 en corrige treize, car l’une des failles n’affecte pas la branche de développement 9.21. Une Supported Preview Edition correspondante a aussi été livrée pour les clients de cette branche.
La faille la plus spectaculaire est CVE-2026-77692, un crash distant non authentifié. Un attaquant arrête named en envoyant une requête DNS-over-HTTPS contenant un enregistrement de signature SIG(0) cryptographiquement invalide, puis en fermant brutalement la connexion de transport. Aucune authentification, aucune information d’identification valide, aucune chaîne d’exploitation en plusieurs étapes : une requête forgée suffit. C’est exactement le genre de primitive de déni de service bon marché et répétable qui rend les équipes DNS nerveuses.
Les autres failles de gravité élevée sont des crashes déclenchables à distance, de l’épuisement mémoire ou de la saturation de ressources. L’ISC a déclaré n’avoir connaissance d’aucune exploitation dans la nature au moment de la divulgation, et recommande une mise à jour sans délai.
Pourquoi un crash DNS est pire qu’un autre déni de service
Les failles de déni de service sont faciles à sous-estimer. Elles ne fuient pas de données et ne donnent pas de shell à l’attaquant, alors on les classe sous les gros titres d’exécution de code à distance. Le DNS est l’exception qui brise cet instinct : c’est la dépendance sous toutes les autres. Quand named plante, la résolution s’arrête, et tout ce qui résout un nom s’arrête avec elle : les appels internes de service à service, les connexions de base de données adressées par DNS, les points de terminaison d’API cloud, les callbacks de webhooks, la remise des e-mails et la porte d’entrée que frappent vos clients. Une panne de résolveur ne dégrade pas une fonctionnalité ; elle peut engloutir toute une plateforme d’un coup.
Le crash DoH aggrave encore les choses. Le DNS-over-HTTPS est de plus en plus activé pour rendre les résolveurs joignables via du HTTPS ordinaire. La requête qui fait planter ressemble alors à du trafic web chiffré normal et peut arriver de partout où le point de terminaison est accessible. Un seul paquet non authentifié qui fait tomber le processus de manière fiable est un outil qu’un attaquant peut déclencher à répétition, remettant le résolveur à terre aussi vite qu’il redémarre. Si ce résolveur est un résolveur interne partagé ou un service exposé sur Internet, le rayon d’impact est chaque client qui se trouve derrière.
Les failles moyennes, le danger silencieux
Les problèmes de gravité moyenne portent un risque plus discret mais sans doute plus vicieux : l’empoisonnement de cache et l’injection de données arbitraires dans les zones DNS. Là où un crash est bruyant et évident, un cache empoisonné est silencieux : il peut orienter utilisateurs et services vers des adresses contrôlées par l’attaquant pendant que chaque tableau de bord reste au vert.
Les vecteurs cités par l’ISC sont concrets : des requêtes QTYPE TKEY forgées, des réponses négatives surdimensionnées et des enregistrements SVCB/HTTPS en mode AliasMode. C’est la différence entre une panne que vous remarquez en quelques secondes et une compromission que vous pourriez ne pas remarquer pendant des jours. Raison pour laquelle ces failles moins bien notées méritent le même correctif, pas un report. La validation DNSSEC, là où elle est déployée, reste la parade structurelle contre une zone altérée.
Ce que vous devez faire
La première leçon est que le DNS est une infrastructure que vous possédez, même quand il paraît invisible. Beaucoup d’équipes corrigent leurs dépendances applicatives selon un calendrier serré mais laissent dériver le résolveur fourni avec une image de base, un conteneur ou une appliance réseau, parce que « ça marche tout seul ». BIND est présent dans plus d’endroits qu’un inventaire d’actifs n’en recense d’ordinaire. Trouver chaque instance est le travail ingrat qui décide si cette mise à jour atteint réellement tout ce qu’elle doit atteindre.
La deuxième leçon est la résilience par conception. Si la défaillance d’un seul résolveur fait tomber votre plateforme, c’est un problème d’architecture que cette CVE n’a fait que révéler. Des résolveurs redondants, un DNS managé avec bascule automatique, des contrôles de santé qui retirent un named mort de la rotation et des limites strictes sur qui peut atteindre un point de terminaison DoH transforment un crash à une requête en non-événement.
Concrètement, l’inventaire se fait en une commande, puis la mise à jour suit :
# Lister les processus named et leur version sur un hôte
ps aux | grep -E '[n]amed' || true
named -v 2>/dev/null || /usr/sbin/named -v 2>/dev/null
# Sur Debian/Ubuntu : vérifier la version du paquet bind9
dpkg-query -W -f='${Version}\n' bind9 2>/dev/null || trueUn résolveur qui tourne encore en 9.20.x antérieur à 9.20.29 ou en 9.21.x antérieur à 9.21.26 doit être priorisé, surtout s’il expose un point de terminaison DoH sur Internet. Là où vous ne pouvez pas corriger immédiatement, restreignez quels réseaux atteignent le DoH, limitez le débit en périphérie, et assurez-vous qu’un résolveur qui plante est automatiquement retiré de la rotation.
Verdict
CVE-2026-77692 n’est pas une exécution de code, mais c’est un rappel que la disponibilité du DNS est un point de défaillance unique pour presque tout le reste. Si vous exploitez des résolveurs BIND exposés ou partagés, corrigez vers 9.20.29 ou 9.21.26 dès aujourd’hui et priorisez tout ce qui sert du DoH vers l’extérieur. Si vous n’avez pas d’inventaire DNS à jour, commencez par là : l’instance que vous oubliez est celle qui restera vulnérable. La parade de fond n’est pas le correctif, c’est une résolution redondante où un crash à une requête ne vaut pas une panne métier.