La réponse courte
Un résolveur BIND non corrigé peut être mis à terre par une seule requête. Le 16 septembre 2026, l'ISC a divulgué 14 vulnérabilités dans BIND 9 — sept de gravité élevée (CVSS 7.5), sept moyennes — et publié les correctifs dans BIND 9.20.29 et 9.21.26. La plus frappante est la CVE-2026-77692 : un attaquant non authentifié fait planter le processus named en envoyant une requête DNS-over-HTTPS malformée avec un enregistrement SIG(0) cryptographiquement invalide, puis en fermant la connexion tôt. D'autres failles permettent l'épuisement mémoire, l'empoisonnement de cache et l'injection de données arbitraires dans les zones DNS. L'ISC indique n'avoir connaissance d'aucune exploitation dans la nature ; la remédiation consiste à mettre à jour immédiatement.
Pour les équipes en France, l'enjeu n'est pas une CVE isolée — c'est que le DNS est la dépendance sous toutes les autres dépendances. Si la résolution de noms s'arrête, tout ce qui résout un nom d'hôte s'arrête aussi, de votre passerelle API au callback de votre prestataire de paiement. C'est pourquoi le DNS relève de la même cadence de correctifs et de la même conception de résilience que le reste de votre plateforme cloud et DevOps, et non d'une case marquée « on installe et on oublie ».
Ce que l'ISC a divulgué
BIND 9 est l'implémentation open source de référence du Domain Name System, maintenue par l'Internet Systems Consortium (ISC) et exploitée par les fournisseurs d'accès, les hébergeurs, les entreprises et les fabricants d'appliances du monde entier. Son démon named répond aux requêtes DNS qui transforment les noms d'hôtes en adresses IP. Parce que tant d'infrastructures résolvent les noms via BIND, un défaut ne reste pas dans un seul réseau — il se propage à tout ce qui se trouve en aval de la résolution.
Le 16 septembre 2026, l'ISC a publié une mise à jour de sécurité coordonnée couvrant 14 CVE et a diffusé BIND 9.20.29 et 9.21.26 pour les corriger. Sept des problèmes sont classés de gravité élevée avec un score CVSS de 7.5, et sept de gravité moyenne. BIND 9.20.29 traite les quatorze ; BIND 9.21.26 en traite treize, car l'une des failles n'affecte pas la branche de développement 9.21. L'ISC a également livré une build Supported Preview Edition correspondante pour les clients sur cette branche.
La faille la plus spectaculaire est la CVE-2026-77692 (CVSS 7.5), un crash distant non authentifié. Un attaquant peut arrêter named en transmettant une seule requête DNS-over-HTTPS (DoH) contenant un enregistrement de signature SIG(0) cryptographiquement invalide, puis en fermant brutalement la connexion de transport. Aucune authentification, aucune information d'identification valide et aucune chaîne d'exploitation en plusieurs étapes ne sont requises — une requête forgée suffit à mettre le résolveur à terre, exactement le type de primitive de déni de service bon marché et répétable qui rend les équipes DNS nerveuses. Les autres problèmes de gravité élevée sont également des crashes déclenchables à distance, de l'épuisement mémoire ou de la saturation de ressources. Accessible, peu coûteux et visant la tuyauterie centrale : c'est précisément le profil de risque qu'un test d'intrusion et audit de sécurité est censé faire remonter avant qu'un attaquant ne le fasse. L'ISC a déclaré n'avoir connaissance d'aucune exploitation des bogues corrigés dans la nature, et recommande une mise à jour sans délai.
Pourquoi un crash DNS est pire qu'il n'y paraît
Les failles de déni de service sont faciles à sous-estimer. Elles ne fuitent 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. Mais le DNS est l'exception qui brise cet instinct : c'est la dépendance sous toutes les autres dépendances. Quand named plante, la résolution de noms s'arrête, et tout ce qui résout un nom d'hôte 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 que les résolveurs soient joignables via du HTTPS ordinaire, ce qui signifie que la requête qui fait planter ressemble à 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 de déni de service 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 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. 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.
Ce que cela signifie pour les équipes logicielles en France
La première leçon est que le DNS est une infrastructure que vous possédez, pas un service public que vous louez — 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 — serveurs autonomes, conteneurs et appliances embarquées — 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, pour qu'un crash ne soit pas une panne. 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 d'un incident métier en non-événement. Partez du principe que les composants d'infrastructure vont défaillir ; concevez de sorte que la résolution de noms survive quand l'un d'eux lâche.
Troisièmement, il s'agit d'une obligation de disponibilité et d'intégrité, pas seulement d'un ticket d'exploitation. Pour les équipes de l'UE, DORA rend explicites la résilience des systèmes d'information et la gestion des composants tiers pour les entités financières, et NIS2 — transposée en droit français — relève le niveau d'exigence pour les services essentiels et importants. Pour les équipes en FinTech et santé, la disponibilité et l'intégrité des systèmes centraux relèvent directement des attentes de l'ACPR, de l'ISO 27001 et, pour les données de santé, de l'hébergement certifié HDS. Une panne DNS ou une zone empoisonnée est exactement le type d'événement que ces cadres demandent de prévenir, de détecter et de tracer. Pouvoir montrer quels résolveurs exécutaient les versions concernées, quand vous avez corrigé et comment la résolution reste opérationnelle lors d'une défaillance de composant, c'est la preuve que rechercheront les auditeurs.
Que faire maintenant
- Inventoriez chaque instance de BIND. Trouvez tous les résolveurs et serveurs autoritaires exécutant BIND 9 — hôtes autonomes, conteneurs et images de base, ainsi qu'appliances ou produits qui l'embarquent. Les instances que vous oubliez sont celles qui restent vulnérables.
- Mettez à jour vers les builds corrigés. Passez à BIND 9.20.29 ou 9.21.26 (ou la build Supported Preview Edition correspondante). Traitez les résolveurs exposés sur Internet et tout ce qui expose DNS-over-HTTPS comme la priorité absolue, puisque la CVE-2026-77692 ne requiert qu'une seule requête non authentifiée.
- Réduisez l'exposition là où vous ne pouvez pas corriger instantanément. Restreignez quels réseaux et clients peuvent atteindre le point de terminaison DoH, limitez le débit et filtrez en périphérie, et assurez-vous qu'un résolveur qui plante est automatiquement retiré de la rotation afin que les clients basculent au lieu de rester bloqués.
- Surveillez l'empoisonnement, pas seulement les crashes. Les problèmes de gravité moyenne peuvent injecter silencieusement des données dans les caches et les zones. Surveillez les enregistrements inattendus, validez les réponses avec DNSSEC lorsque c'est possible, et alertez sur les redémarrages de
namedet les anomalies de réponse, pas uniquement sur les temps d'arrêt. - Intégrez de la redondance et testez-la. Faites tourner plus d'un résolveur, envisagez un DNS managé ou secondaire pour les zones critiques, et ajoutez les serveurs DNS et leurs protocoles exposés au périmètre de votre prochain test d'intrusion pour que cette couche cesse d'être un angle mort.
Questions fréquentes
Qu'est-ce qui a été corrigé dans BIND 9.20.29 et 9.21.26 ?
L'ISC a corrigé 14 vulnérabilités dans BIND 9, divulguées le 16 septembre 2026 — sept de gravité élevée (CVSS 7.5) et sept moyennes. BIND 9.20.29 corrige les 14 ; BIND 9.21.26 en corrige 13, car une faille n'affecte pas la branche 9.21. L'ISC recommande de passer immédiatement aux versions corrigées.
Qu'est-ce que la CVE-2026-77692 ?
C'est un crash distant non authentifié du processus named de BIND, noté CVSS 7.5. Un attaquant arrête le serveur en envoyant une seule requête DNS-over-HTTPS malformée portant un enregistrement de signature SIG(0) cryptographiquement invalide, puis en fermant prématurément la connexion. Une requête suffit, et aucune authentification n'est requise — un vecteur de déni de service bon marché et répétable contre tout résolveur BIND exposant un point de terminaison DoH.
Ces failles sont-elles exploitées dans la nature ?
Au moment de la divulgation, le 16 septembre 2026, l'ISC a déclaré n'avoir connaissance d'aucune exploitation des bogues corrigés. Ce n'est pas une raison pour attendre : le crash DoH ne requiert qu'une requête non authentifiée, plusieurs autres failles de gravité élevée sont des dénis de service déclenchables à distance, et une panne DNS se répercute sur tout service qui dépend de la résolution de noms.
Que permettent les autres vulnérabilités de BIND ?
Les problèmes de gravité élevée restants permettent à des attaquants distants de provoquer des crashes, un épuisement mémoire ou une saturation des ressources, aboutissant tous à un déni de service. Les problèmes de gravité moyenne peuvent causer un empoisonnement de cache, une consommation excessive de mémoire ou de CPU, ou l'injection de données arbitraires dans les zones DNS, via des techniques telles que des requêtes QTYPE TKEY forgées, des réponses négatives surdimensionnées et des enregistrements SVCB/HTTPS en AliasMode. L'empoisonnement de cache est le plus dangereux car il peut rediriger silencieusement le trafic.
Que doivent faire les équipes qui exploitent BIND maintenant ?
Inventoriez chaque résolveur et serveur autoritaire BIND, y compris les conteneurs et appliances qui embarquent BIND, et mettez à jour vers 9.20.29, 9.21.26 ou la build Supported Preview Edition correspondante. Priorisez les résolveurs exposés sur Internet et les points de terminaison DoH, restreignez l'accès DoH là où vous ne pouvez pas corriger instantanément, faites tourner un DNS redondant ou managé pour qu'un résolveur en panne ne fasse pas tomber la résolution, et ajoutez le DNS au périmètre de votre prochain test d'intrusion.
Sources
ISC Knowledge Base — CVE-2026-77692: Unauthenticated remote crash of named via a single DoH SIG(0) request
SecurityWeek — ISC Patches 14 Vulnerabilities in BIND 9 Security Update
The Hacker News — BIND 9 Update Fixes 14 Flaws, Including an Unauthenticated Crash Over DNS-over-HTTPS