La réponse en bref
ISC a corrigé 14 vulnérabilités dans BIND 9, et l'une d'elles permet à n'importe qui sur Internet de faire planter votre serveur DNS avec une seule requête. CVE-2026-77692 (CVSS 7.5) abuse de DNS-over-HTTPS : une requête forgée avec un enregistrement SIG(0) invalide, suivie d'une fermeture prématurée de la connexion, déclenche un déréférencement de pointeur NULL et interrompt le processus named. Aucune authentification, aucun identifiant valide, aucun accès préalable — juste un paquet malformé. Si le DNS tombe, tout ce qui résout à travers lui tombe aussi, et c'est pourquoi cela doit figurer en tête de votre file de correctifs cloud et DevOps cette semaine.
Le correctif est simple — passer à BIND 9.20.29 ou 9.21.26 — mais la leçon est plus large. Le DNS faisant autorité et récursif est une infrastructure critique que beaucoup d'équipes traitent en mode « configuré et oublié ». Cette version rappelle qu'il faut le corriger au même rythme que votre pile applicative, le surveiller pour détecter les plantages et s'assurer qu'une seule requête en périphérie ne peut pas mettre à terre un service dont dépend toute l'entreprise.
Ce qu'ISC a corrigé — et la faille à surveiller
Le 16 septembre, l'Internet Systems Consortium — l'organisation à but non lucratif qui maintient BIND, le logiciel de serveur DNS le plus déployé sur Internet — a publié BIND 9.20.29 et 9.21.26, refermant 14 failles de sécurité d'un coup. Sept sont classées haute sévérité et sept moyenne. Le groupe de niveau élevé peut être exploité à distance pour déclencher des plantages de programme, un épuisement mémoire ou un épuisement des ressources, tandis que les problèmes de niveau moyen incluent l'empoisonnement de cache, l'épuisement CPU et l'injection de données arbitraires dans les zones DNS.
La plus marquante est CVE-2026-77692, notée CVSS 7.5. Elle permet à un attaquant distant non authentifié de terminer le démon named en envoyant une seule requête DNS-over-HTTPS (DoH) porteuse d'un enregistrement SIG(0) cryptographiquement invalide, puis en fermant brutalement la connexion de transport avant la fin de la validation. Le résultat est un déréférencement de pointeur NULL qui interrompt le processus — un déni de service net sans identifiant, sans session et sans signature valide. Pour les résolveurs exposés à Internet, c'est presque le pire rapport effort/impact possible.
ISC affirme n'avoir connaissance d'aucune des 14 vulnérabilités exploitée dans la nature. C'est rassurant mais limité dans le temps : le consortium note aussi que des tests reproduisant les failles sont publics, ce qui abaisse fortement le travail nécessaire pour les militariser. Lorsqu'un chemin de preuve de concept est déjà documenté, « pas encore exploité » est un détail de calendrier, pas une raison de reporter. Quiconque exploite BIND devrait traiter cela comme une action de la même semaine et l'intégrer à une routine disciplinée de sécurité et de correctifs.
Pourquoi DNS-over-HTTPS élargit la surface d'attaque
DNS-over-HTTPS a été conçu pour améliorer la confidentialité en enveloppant les requêtes DNS dans du trafic HTTPS chiffré, et son adoption par les résolveurs d'entreprise et les fournisseurs DNS publics n'a cessé de croître. Mais chaque nouveau transport qu'un serveur parle est du code nouveau qui analyse des entrées non fiables, et CVE-2026-77692 réside précisément dans cette jointure : la gestion des signatures de transaction SIG(0) sur le transport DoH. La faille n'est pas dans la logique de résolution DNS elle-même, mais dans la manière dont le serveur gère une connexion interrompue en pleine validation.
Ce schéma — un plantage déclenché par une entrée malformée suivie d'une déconnexion prématurée — est une classe de bug récurrente dans les démons réseau, et c'est exactement pourquoi l'analyse des entrées sur les services exposés en périphérie mérite une attention accrue. Si vos résolveurs exposent DoH, ils sont joignables via les ports HTTPS ordinaires que les pare-feu laissent généralement ouverts ; le modèle mental du « service interne » ne vous protège donc pas. En pratique, sachez quels transports chaque point d'accès DNS parle réellement et traitez chacun comme une surface d'attaque à corriger et à surveiller.
Cela renforce aussi un principe de conception pour tout service qui termine des connexions non fiables : supposez que les clients se comporteront mal, se déconnecteront tôt et enverront des données invalides à dessein. Une gestion robuste du cycle de vie des connexions — et la supervision de redémarrage sur plantage comme filet de sécurité — n'est pas du superflu ; c'est la différence entre une erreur journalisée et une panne à l'échelle de l'entreprise.
Ce que cela signifie pour les équipes en France
La première implication est un problème de rayon d'impact. Le DNS est une dépendance de presque tout : découverte de services, appels d'API, messagerie, validation de certificats et trafic client supposent tous que la résolution fonctionne. Un plantage de named ne fait pas tomber une seule fonctionnalité ; il peut cascader en timeouts sur toute une plateforme. Pour les équipes de la FinTech, de la HealthTech ou de l'e-commerce, où la disponibilité est contractuelle et l'indisponibilité se mesure en revenus et en exposition réglementaire, un DoS DNS non authentifié est un enjeu de continuité d'activité, pas un simple ticket ops.
En France, une dimension réglementaire s'ajoute : l'ANSSI et son CERT-FR publient leurs propres bulletins d'alerte pour ce type d'avis BIND, et les opérateurs d'importance vitale (OIV) comme les opérateurs de services essentiels (OSE) relevant de la transposition de NIS 2 doivent démontrer la disponibilité et la traçabilité de leurs services DNS. Si vous exploitez des résolveurs dans un périmètre OIV/OSE, ce correctif ne doit pas seulement être appliqué techniquement : documentez la date de correction, les systèmes concernés et les mesures compensatoires, car ce sont précisément les éléments attendus en cas de contrôle ou de déclaration d'incident.
La deuxième implication concerne la responsabilité. Beaucoup d'organisations ignorent qui corrige leur DNS. Ce peut être un prestataire infogéré, une équipe plateforme, un boîtier ou une image de conteneur que personne n'a reconstruite depuis des mois. Cette version est un bon déclencheur pour répondre à une question simple : pour chaque résolveur DNS et serveur faisant autorité dont nous dépendons, qui est responsable de l'application de BIND 9.20.29 ou 9.21.26, et pour quand ? Une responsabilité floue est la façon dont une faille documentée et corrigeable survit des mois.
La troisième implication est la résilience par défaut. Même après correction, le prochain bug DNS finira par arriver. Les équipes qui exécutent named sous un superviseur de processus, répartissent la résolution sur des instances redondantes, appliquent une limitation de débit aux points d'accès DoH et alertent sur les redémarrages répétés absorberont la prochaine faille de type plantage avec un simple soubresaut plutôt qu'une panne. C'est la posture que nous intégrons à chaque plateforme de logiciel sur mesure : les services critiques sont supervisés, redondants et observables, si bien qu'une défaillance unique se dégrade en douceur au lieu de mettre le système à terre.
Que faire maintenant
- Inventoriez votre parc BIND. Repérez chaque serveur récursif et faisant autorité, y compris les boîtiers et images de conteneurs. On ne peut pas corriger ce qu'on n'a pas localisé.
- Passez à la version corrigée. Migrez vers BIND 9.20.29 ou 9.21.26 (ou 9.20.29-S1 pour la Supported Preview Edition) sur la branche que vous utilisez. Vérifiez la version en cours d'exécution après le déploiement, pas seulement la version du paquet.
- Réduisez l'exposition DoH. Limitez quels clients peuvent atteindre les points d'accès DNS-over-HTTPS, et placez les résolveurs derrière une limitation de débit et des contrôles réseau afin qu'un flot de requêtes forgées ne puisse pas faire planter le service à répétition.
- Supervisez et surveillez
named. Exécutez-le sous systemd ou un équivalent qui le redémarre automatiquement, et alertez sur les plantages répétés plutôt que de les découvrir via un signalement client. - Attribuez une responsabilité claire. Désignez l'équipe responsable des correctifs DNS et ajoutez BIND au même rythme de revue que vos dépendances applicatives, pour que le prochain avis soit une routine et non un exercice d'urgence.
Questions fréquentes
Qu'a corrigé ISC dans BIND 9 le 16 septembre 2026 ?
ISC a publié BIND 9.20.29 et 9.21.26 pour corriger 14 vulnérabilités — sept de haute sévérité et sept de moyenne. Les problèmes de niveau élevé peuvent provoquer des plantages à distance, un épuisement mémoire ou un épuisement des ressources ; ceux de niveau moyen incluent l'empoisonnement de cache, l'épuisement CPU et l'injection de données arbitraires dans les zones DNS.
Qu'est-ce que la CVE-2026-77692 ?
C'est une faille de haute sévérité (CVSS 7.5) qui permet à un attaquant distant non authentifié de faire planter le service named avec une seule requête DNS-over-HTTPS. L'attaquant envoie une requête DoH forgée avec un enregistrement SIG(0) cryptographiquement invalide et ferme la connexion prématurément, déclenchant un déréférencement de pointeur NULL et un déni de service.
Quelles versions de BIND 9 sont concernées et corrigées ?
CVE-2026-77692 affecte BIND 9.20.0 à 9.20.27, 9.21.0 à 9.21.25 et la Supported Preview Edition 9.20.9-S1 à 9.20.27-S1. Les correctifs sont livrés dans BIND 9.20.29, 9.21.26 et 9.20.29-S1. Passez à la version corrigée de la branche que vous utilisez.
La CVE-2026-77692 est-elle exploitée dans la nature ?
ISC a déclaré n'avoir connaissance d'aucune des 14 vulnérabilités exploitée dans la nature. Il a toutefois noté que des tests reproduisant les failles sont publics, ce qui réduit l'effort nécessaire pour les militariser ; les opérateurs devraient donc corriger rapidement plutôt que d'attendre.
Que faire si nous ne pouvons pas corriger BIND immédiatement ?
Réduisez l'exposition pendant que vous planifiez la mise à niveau : limitez qui peut atteindre les points d'accès DoH, placez les résolveurs derrière une limitation de débit et des contrôles réseau, exécutez named sous un superviseur qui le redémarre automatiquement, et surveillez les plantages répétés. Ces mesures limitent le rayon d'impact mais ne remplacent pas l'application de BIND 9.20.29 ou 9.21.26.
Sources
ISC — 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