Un message GSS-TSIG rejoué peut corrompre la mémoire de BIND 9 et mener à une exécution de code

14 octobre 2026. L’ISC notifie ses clients en avant-première d’une faille trouvée en interne dans BIND 9. 21 octobre 2026. L’éditeur publie l’avis public : la CVE-2026-94300, notée 8.1, permet de corrompre la mémoire de named en rejouant un message UDP signé GSS-TSIG. Le point qui compte : il n’existe aucun contournement, la seule parade est la mise à jour vers 9.20.30 ou 9.21.27.

Qui est réellement exposé : les zones intégrées à Active Directory

BIND est le serveur DNS de référence de l’Internet, déployé sur une large part des résolveurs et des serveurs faisant autorité. Mais la CVE-2026-94300 ne touche pas n’importe quel serveur : elle frappe précisément ceux qui acceptent des mises à jour dynamiques signées GSS-TSIG.

GSS-TSIG (RFC 3645) est le mécanisme qui authentifie par Kerberos les mises à jour dynamiques DNS. C’est lui qu’utilise Windows Server pour les zones intégrées à Active Directory, lorsque des postes et des contrôleurs de domaine enregistrent leurs enregistrements de façon sécurisée. Un BIND qui sert ce type de zone — par exemple en frontal d’un domaine AD ou en relayant des mises à jour sécurisées — est la cible naturelle de cette faille. Un serveur qui ne fait que de la résolution récursive ou de l’autorité statique, sans GSS-TSIG configuré, n’a pas ce chemin d’attaque.

Les versions concernées couvrent l’essentiel de la base installée : 9.11.0 à 9.18.50, 9.20.0 à 9.20.29 et 9.21.0 à 9.21.26, ainsi que la branche Supported Preview Edition (9.11.3-S1 à 9.18.50-S1 et 9.20.9-S1 à 9.20.29-S1). Autrement dit, à peu près tout ce qui n’a pas été mis à jour depuis le 21 octobre.

Le mécanisme : rejouer un message déjà signé

L’attaque décrite par l’ISC tient en trois gestes. D’abord, l’attaquant capture un message UDP précédemment signé GSS-TSIG — il lui faut donc une position d’observation sur le flux, ce qui suppose un accès réseau privilégié ou un man-in-the-middle. Ensuite, il rejoue ce message tant que la clé TSIG négociée reste valide, sans avoir besoin de la casser : la signature existe déjà. Enfin, il envoie des requêtes forgées vers une zone qu’il contrôle.

C’est la concurrence entre ces messages rejoués qui corrompt la mémoire de named. L’avis de l’ISC est direct : « rejouer des messages UDP signés GSS-TSIG peut entraîner une corruption mémoire dans named », avec pour impact « la corruption mémoire, menant à l’arrêt du programme et/ou à une exécution de code à distance potentielle ».

Le vecteur CVSS 3.1 reflète cette combinaison : AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Réseau, aucune authentification, aucun clic — mais complexité d’attaque élevée (AC:H), ce qui traduit exactement la double condition : il faut avoir capturé un message valide, et il faut contrôler une zone vers laquelle envoyer les requêtes forgées.

Pas de contournement, une seule sortie

C’est la phrase la plus lourde de l’avis. L’ISC écrit noir sur blanc : « Aucun contournement connu ». Pas de directive de configuration à désactiver, pas de liste de contrôle d’accès à resserrer, pas de correctif de fortune : la seule parade est la mise à niveau.

Les versions corrigées sont 9.20.30 et 9.21.27 — et 9.20.30-S1 pour la branche Supported Preview Edition. La logique de versionnement est simple : 9.20 et 9.21 sont les deux branches actuellement maintenues, les plus anciennes (9.18 et antérieures) étant en fin de vie et non corrigées par l’ISC.

# Vérifier la version installée et la branche
named -V | head -1

# Mettre à niveau selon la branche (exemple Debian/Ubuntu)
apt-get update && apt-get install --only-upgrade bind9 bind9-utils

# Puis vérifier que le service tourne sur le binaire corrigé
named -v
systemctl restart named

Cette contrainte a une conséquence opérationnelle que les équipes DNS connaissent mal : contrairement à un contournement temporaire, la mise à jour de BIND n’est pas reportable. Elle doit entrer dans la fenêtre de maintenance la plus proche, d’autant que l’ISC a publié dans le même lot deux autres avis — la CVE-2026-19630 (épuisement de ressources amplifié dans le traitement des messages entrants) et la CVE-2026-96888 (named peut se terminer de façon inattendue avec une redirect zone et la minimisation stricte QNAME).

Une faille réelle, une exploitation exigeante

Il faut être honnête sur le niveau de menace. La CVE-2026-94300 n’est pas un zero-click à grande échelle : l’attaquant doit capturer un message signé, ce qui suppose déjà une position sur le chemin réseau, et contrôler une zone pour envoyer les requêtes forgées. L’ISC précise par ailleurs « n’avoir connaissance d’aucune exploitation active » au moment de la publication.

Mais cette exigence ne doit pas rassurer à tort. D’abord, BIND est une cible de choix : c’est l’infrastructure qui résout les noms de domaines entiers, et une exécution de code sur un résolveur ou un serveur d’autorité ouvre la porte à la falsification de réponses, au détournement de trafic ou au pivot vers le reste du système d’information. Ensuite, les attaquants qui visent ce type de cible ont précisément les moyens de se placer sur le chemin et de contrôler une zone — c’est le profil d’un acteur étatique ou d’un groupe spécialisé, pas d’un script opportuniste. Enfin, l’absence d’exploitation connue aujourd’hui est une photo à un instant : une fois la mécanique publiée, la barre technique à franchir a baissé pour tout le monde.

La découverte a d’ailleurs une histoire double. L’ISC indique avoir trouvé la faille en test interne, mais remercie aussi Dave Aitel, de chez OpenAI, qui l’a « découverte de façon indépendante et signalée de façon responsable ». Deux équipes qui trouvent la même faille en parallèle, c’est souvent le signe qu’elle était mûre pour être trouvée.

Verdict

Si vous exploitez BIND 9 sur une branche 9.20 ou 9.21, planifiez la mise à niveau vers 9.20.30 ou 9.21.27 immédiatement : il n’y a aucun contournement, et reporter ne fait que prolonger une fenêtre où la seule parade n’est pas appliquée. Si vos serveurs servent des zones intégrées à Active Directory ou acceptent des mises à jour dynamiques GSS-TSIG, traitez cette CVE en priorité absolue : c’est exactement la population que la faille vise, et une exécution de code sur un frontal DNS d’un domaine a un coût qui dépasse de loin une simple panne. Et si vous tournez sur une branche 9.18 ou antérieure, l’avis est un rappel : ces versions sont hors support et ne recevront pas de correctif — la migration vers 9.20 ou 9.21 n’est plus une option, c’est une obligation de sécurité. La CVE-2026-94300 n’est pas la faille la plus facile à exploiter de l’année ; elle est la preuve que, sur DNS, même une faille « exigeante » se traite par la mise à jour, parce qu’il n’y a rien d’autre.

Références

• ISC — CVE-2026-94300 : Concurrent GSS-TSIG messages corrupt memory (21 octobre 2026)
• NVD — CVE-2026-94300
• ISC — CVE-2026-19630 : Amplified resource exhaustion in inbound message processing
• ISC — CVE-2026-96888 : named may terminate unexpectedly when a redirect zone is used with strict QNAME minimization
• Safeguard.sh — BIND 9 CVE-2026-94300 : GSS-TSIG Replay Memory Corruption Explained