Résumé

  • Le rapport retenu sur la CVE-2025-40778 nomme cinq chaînes corrigées : BIND 9 9.18.41, 9.20.15 et 9.21.14, plus BIND Supported Preview Edition 9.18.41-S1 et 9.20.15-S1.
  • L'ensemble affecté n'est décrit que par les mots « various BIND 9 and BIND Supported Preview Edition versions », sans plage : le document permet d'attester une correction, jamais d'établir une exposition.
  • Aucun correctif de prévisualisation n'est nommé pour la ligne 9.21, alors que les deux autres lignes en portent un.

La phrase qui porte la substance technique tient en une ligne. Le rapport retenu qualifie la faille de gravité élevée, la situe dans les résolveurs DNS BIND 9 et la décrit comme exploitable par des attaquants distants non authentifiés, avec pour effet la manipulation d'entrées DNS par empoisonnement du cache.

Quelques lignes plus loin, le même document fait quelque chose de plus lourd de conséquences que nommer une faille : il coupe la question des versions en deux et n'en traite qu'une moitié.

Du côté corrigé, le libellé est précis au chiffre près. Le rapport énumère cinq chaînes : BIND 9 9.18.41, 9.20.15 et 9.21.14, puis, pour BIND Supported Preview Edition, 9.18.41-S1 et 9.20.15-S1. Trois de ces chaînes viennent de lignes distinctes de BIND 9 ; deux portent le suffixe -S1 propre à l'édition de prévisualisation. Un exploitant peut confronter cette liste à la version installée et obtenir une réponse nette, parce que chaque élément est un artefact nommé et non une description.

La précision s'arrête du côté affecté. Le même rapport écrit : « various BIND 9 and BIND Supported Preview Edition versions ». Ce mot tient la place qu'occuperait une plage, et il n'est pas testable. Rien dans la phrase ne dit si une version située quatre révisions sous le correctif est exposée, ni si l'exposition ne commence qu'à la dernière livraison.

Le mécanisme explique pourquoi la question des versions pèse si lourd. L'empoisonnement du cache signifie qu'un résolveur accepte des enregistrements manipulés dans son cache, puis répond à des requêtes ultérieures avec les données qu'a choisies l'attaquant. Les utilisateurs en aval ne voient aucune erreur : ils reçoivent de mauvaises réponses qui ont exactement l'apparence de bonnes réponses. Une faille dont le symptôme est invisible place la chaîne de version au premier rang des rares indices disponibles avant l'incident.

Une erreur de lecture bien précise coûte alors cher. Une liste de correctifs est une liste de sortie, pas une carte d'exposition. Dans un sens, elle rend service : une version égale au correctif nommé pour sa propre ligne peut être tenue pour corrigée, et l'affirmation repose sur une chaîne publiée plutôt que sur une déduction. Dans l'autre sens, elle échoue. L'absence d'une version ancienne dans une liste de correctifs ne dit rien de son exposition, puisque le document n'a jamais énoncé quelles versions étaient touchées.

Traiter la liste comme un test à double sens conduit soit à blanchir un hôte exposé, soit à déclarer une exposition qui n'a pas été établie ; les deux erreurs finissent dans la piste d'audit.

L'édition de prévisualisation mérite une attention à part, car c'est là que les comparaisons soigneuses se brisent. Deux des cinq correctifs portent les mêmes chiffres qu'un correctif stable avec une terminaison différente : 9.18.41 à côté de 9.18.41-S1, 9.20.15 à côté de 9.20.15-S1. Les chiffres coïncident, les artefacts non. Un inventaire qui ne retient que la partie numérique fusionne deux produits distincts en une seule ligne, et une routine de comparaison qui lit la terminaison comme un niveau de correctif inverse leur relation, car la chaîne de prévisualisation n'est pas une révision ultérieure de la version stable.

Le rapport ne nomme d'ailleurs des correctifs de prévisualisation que pour deux des trois lignes : un déploiement de prévisualisation sur la ligne 9.21 n'a donc, dans ce document, aucun correctif nommé auquel se comparer. C'est un trou dans la liste, non une conclusion sur la version installée.

La date exige la même discipline. L'adresse web du rapport retenu porte le 28 octobre 2025, et aucun horodatage de publication n'accompagne le texte : le jour reste non confirmé, et rien ici n'en dépend. L'identifiant CVE-2025-40778 est le point d'accroche stable ; il désignera la même faille quand la date de l'article sera oubliée.

Pour le service qui devra répondre de la mise à jour plus tard, la leçon durable porte sur les champs qu'on écrit. Une note de remédiation qui cite une liste de versions corrigées consigne une installation. Elle ne consigne pas une exposition, parce que l'exposition n'était pas un champ du document cité. Quand une revue d'incident demandera six mois plus tard quels systèmes étaient vulnérables avant la fenêtre de changement, cette note sera lue comme si elle avait répondu, et elle n'aura pas répondu.

Noter la chaîne complète, terminaison d'édition comprise, ainsi que l'identifiant du document qui a autorisé le changement coûte presque rien sur le moment et sépare une réparation vérifiable d'une réparation plausible.

La fiche d'annuaire de l'Internet Systems Consortium ancre ce type de faille du côté institutionnel, et ce texte s'en tient délibérément à la structure interne d'un document plutôt qu'à la question plus large des frontières du support. Ce que furent réellement les plages affectées n'est établi ici ni par ce rapport ni par aucun autre document obtenu : onze recherches sur ce sujet ont renvoyé du contenu deux fois, chaque fois ce même rapport unique, et aucune note d'ISC, aucun article de sa base de connaissances, aucune documentation de référence de BIND 9 sur la déclaration de version et aucun enregistrement CVE n'a été obtenu — les plages de versions affectées de la CVE-2025-40778 ne sont donc pas établies dans le matériel examiné ici. Deux documents changeraient cette classification au lieu de l'élargir : une note de l'éditeur ou de sa base de connaissances énonçant les plages affectées ligne par ligne, ou un enregistrement CVE autoritatif portant des configurations de versions structurées. L'un ou l'autre transformerait « various » en champ testable, et cette analyse deviendrait une comparaison plutôt qu'une frontière.