Confession à retardement. Les développeurs de Bitcoin Core ont publié mardi 10 novembre trois avis de sécurité sur des bugs corrigés depuis plus d’un an. L’un d’eux pouvait empêcher un mineur de construire des blocs, un autre faisait traiter n’importe quelle connexion Tor entrante comme un ami de confiance. Aucun ne permettait de voler des bitcoins. Deux semaines après le trio de failles déniché par une IA, c’est la deuxième fournée de l’automne, et elle n’a rien à voir avec la première.
- Les développeurs de Bitcoin Core ont publié des avis de sécurité concernant trois bugs, dont un empêchait la production de blocs par les mineurs.
- Un bug permettait à des connexions Tor d’être traitées comme de confiance, exposant ainsi de nombreux nœuds.
Bitcoin Core et la faille qui laissait les mineurs sans bloc à produire
La plus sérieuse des trois porte le matricule CVE-2025-62861 et le niveau « élevé ». Elle touche les versions 28.0 à 28.2 et 29.0 à 29.1 du logiciel. Le coupable est la règle d’« éviction de frère » introduite avec les transactions TRUC (une catégorie de transactions aux règles de remplacement plus strictes, conçue pour les canaux Lightning). Lors d’une réorganisation de la chaîne, quand un bloc est remplacé par un concurrent, ses transactions retournent dans le mempool, la salle d’attente du nœud. Mauvaise surprise. Le logiciel pouvait alors y laisser des transactions filles qui dépensaient des sorties disparues, et le nœud devenait incapable de produire un modèle de bloc valide jusqu’au redémarrage. Un mineur touché aurait tourné à vide sans comprendre pourquoi.
Niklas Goegge, contributeur de Bitcoin Core, a signalé le problème le 26 septembre 2025. Le correctif est arrivé dans la version 30.0 le 10 octobre suivant, puis dans les 29.2 et 28.3 dans la foulée. D’après l’avis publié sur bitcoincore.org, aucune attaque exploitant cette faille n’a été observée.
Tor et compact blocks : deux failles de niveau moyen
La deuxième (CVE-2025-62860) concerne les nœuds qui utilisent l’option « -whitelist », une liste d’adresses IP de confiance dispensées des limites anti-spam et des protections de vie privée. Quand l’adresse du proxy Tor tombait dans une plage ainsi déclarée, toutes les connexions Tor entrantes héritaient du passe-droit. L’avis parle de « milliers de nœuds joignables sur le réseau principal » qui ouvraient grand la porte à n’importe quel inconnu passé par Tor. Martin Zumsande et Antoine Poinsot ont remonté le bug le 12 septembre 2025, et Poinsot a prévenu en privé les éditeurs de logiciels concernés une semaine plus tard. Les nœuds qui n’ont jamais touché à cette option n’ont rien risqué.
La troisième (CVE-2025-62859) remonte à avril 2025 et à un rapport d’Eugene Siegel. Un pair malveillant qui annonçait le premier un bloc compact pouvait geler le traitement des blocs de sa victime pendant dix minutes. L’attaque devenait répétable à l’infini si l’assaillant contrôlait les trois pairs « haut débit » du nœud, ou si celui-ci tournait en mode « -blocksonly ». Corrigée dès juin 2025 sur la branche principale, la faille n’a disparu des versions stables qu’avec la 29.2 et la 30.0.
Le calendrier n’a rien d’un hasard. Bitcoin Core attend que la dernière version vulnérable soit abandonnée, puis deux semaines, avant de publier le détail d’une faille moyenne ou élevée. La branche 29 a atteint sa fin de vie le 27 octobre, le compte y est. Cette règle, qui avait déjà conduit à révéler un bug sévère deux ans après sa correction, a été assouplie en octobre. Les bugs faciles à retrouver, y compris par une IA, font désormais l’objet d’une version corrigée et d’un avis au plus vite. Pour l’utilisateur, la consigne tient en un chiffre : la dernière version en date est la 32.1, publiée le 27 octobre, et tout nœud resté en 29.1 ou plus ancien reste exposé aux trois failles du jour, en plus de celles corrigées fin octobre.
