Imaginez un instant que votre nœud Bitcoin, celui que vous avez soigneusement configuré pour préserver votre anonymat, ouvre en réalité une porte dérobée à des milliers d’inconnus. C’est exactement ce qui s’est produit pendant des mois pour un grand nombre d’opérateurs. Une vulnérabilité découverte au cœur de Bitcoin Core a permis à des connexions Tor entrantes de recevoir des permissions normalement réservées à des pairs de confiance. Le résultat ? Des protections contre le spam et les fuites d’informations privées purement et simplement neutralisées.
Une faille qui a touché des milliers de nœuds sans bruit
Le 10 novembre 2026, l’équipe de développement de Bitcoin Core a rendu publiques trois vulnérabilités. La plus discutée reste celle liée à Tor, référencée sous le nom CVE-2025-62860. Elle n’est pas d’une gravité maximale, mais son impact réel est loin d’être négligeable. Des milliers de nœuds accessibles sur le réseau principal ont, sans le savoir, accordé des privilèges élevés à des connexions anonymes provenant du réseau Tor.
Le mécanisme est subtil. Quand un nœud Bitcoin reçoit une connexion via Tor, l’adresse IP visible n’est pas celle du pair distant. C’est l’adresse locale du logiciel Tor lui-même, souvent 127.0.0.1 ou une plage privée. Or, de nombreux opérateurs et surtout certains logiciels préconfigurés utilisaient l’option -whitelist pour autoriser précisément ces adresses locales. Résultat : toutes les connexions Tor entrantes se retrouvaient automatiquement traitées comme des pairs de confiance.
Comment la whitelist a transformé l’anonymat en risque
La fonction whitelist existe pour une bonne raison. Elle permet de relâcher certaines limites de déni de service et d’autoriser des actions plus permissives avec des pairs considérés comme fiables. Dans un contexte normal, cela a du sens : on peut faire confiance à un nœud de son propre réseau local ou à un partenaire connu. Mais lorsque cette confiance est accordée à n’importe qui se connectant via Tor, le système s’effondre.
Les connexions Tor ne révèlent jamais l’adresse réelle du pair distant. C’est justement l’intérêt du réseau oignon. Pourtant, le code de Bitcoin Core traitait l’adresse locale de Tor comme s’il s’agissait de l’identité du pair. Dès que cette adresse figurait dans la whitelist, les protections habituelles disparaissaient. Un attaquant pouvait alors envoyer des quantités excessives de données, tenter d’extraire des informations privées ou simplement monopoliser les ressources du nœud.
Ce qui rend la situation particulièrement préoccupante, c’est que plusieurs solutions logicielles populaires livraient Bitcoin Core déjà configuré avec Tor et une whitelist correspondante. Les opérateurs qui pensaient gagner en confidentialité se retrouvaient en réalité avec un nœud plus exposé qu’un nœud classique. Les nœuds qui n’avaient jamais activé l’option whitelist, quant à eux, sont restés parfaitement à l’abri.
Chronologie d’une découverte et d’un correctif rapide
La faille a été signalée le 12 septembre 2025 par Martin Zumsande et Antoine Poinsot. Deux jours plus tard, les développeurs concernés ont été informés. Le correctif a été fusionné dès le 17 septembre. L’idée était simple et élégante : exclure systématiquement les connexions onion entrantes des permissions de whitelist. L’adresse locale de Tor ne pouvait plus servir de critère de confiance.
Bitcoin Core 30.0 est sorti le 10 octobre 2025 avec le correctif intégré. La version 29.2 a suivi le 14 octobre. Les branches 28.3 et suivantes ont également reçu le patch. Le 27 octobre, la série 29.x a officiellement atteint la fin de support. Conformément à la politique de divulgation, les détails complets n’ont été publiés que deux semaines plus tard, le 10 novembre.
Cette politique de retenue est classique dans l’écosystème Bitcoin. Elle laisse le temps aux opérateurs sérieux de mettre à jour avant que les détails techniques ne deviennent publics. Pourtant, beaucoup de nœuds tournent encore sur des versions anciennes. La question reste ouverte : combien d’opérateurs ont réellement appliqué les correctifs à temps ?
Le bug minier qui pouvait bloquer la création de blocs
Parallèlement à la faille Tor, une vulnérabilité de gravité élevée a été révélée sous le nom CVE-2025-62861. Elle concernait les versions 28.0 à 28.2 ainsi que 29.0 et 29.1. Son impact touchait directement les nœuds de minage.
Lors d’une réorganisation de chaîne, les transactions des blocs déconnectés sont renvoyées dans le mempool. Les règles TRUC (version 3 des transactions) limitent normalement les relations entre transactions non confirmées. Pendant une réorganisation, ces restrictions sont censées être levées pour les transactions provenant de blocs déjà validés. Or, une règle de remplacement de transaction restait active par erreur.
Conséquence : une transaction restaurée pouvait être retirée tandis que les transactions qui en dépendaient restaient dans le mempool. L’ensemble devenait incohérent. Le modèle de bloc proposé par le nœud minier échouait alors à la vérification de validité. La création de templates s’arrêtait purement et simplement. Seul un redémarrage permettant de recharger le mempool dans un état cohérent pouvait relancer le processus.
Niklas Goegge a signalé le problème le 26 septembre 2025. Le correctif a été fusionné le 2 octobre. Greg Sanders a précisé que le comportement attendu était bien de contourner les vérifications TRUC pendant les réorganisations, mais que l’argument de contournement n’était jamais consulté. Une erreur de logique simple, mais aux conséquences potentiellement lourdes pour les mineurs.
Des délais artificiels sur le traitement des blocs
La troisième vulnérabilité, CVE-2025-62859, est de gravité moyenne. Elle concerne les compact blocks, un mécanisme conçu pour économiser de la bande passante lors de la propagation des blocs. Un pair malveillant pouvait annoncer un compact block en premier, forçant la victime à demander le bloc complet au même pair. Un contrôle échoué sur les données de témoin altérées déclenchait alors un timeout de dix minutes.
Un attaquant contrôlant les trois pairs à haute bande passante d’un nœud pouvait répéter l’opération indéfiniment. Les nœuds configurés avec l’option -blocksonly étaient également vulnérables à ce type de ralentissement répété. Eugene Siegel a signalé la faille dès le 28 avril 2025, ce qui montre que le problème était connu depuis plusieurs mois avant sa divulgation publique.
Ces délais artificiels n’empêchent pas le réseau de fonctionner, mais ils dégradent la performance et peuvent, dans certains scénarios, favoriser des attaques de type eclipse ou ralentir la propagation d’informations critiques.
Pourquoi ces failles arrivent-elles maintenant ?
Bitcoin Core est l’un des logiciels les plus audités au monde. Pourtant, des bugs continuent d’apparaître. La raison est double. D’un côté, le code évolue constamment pour intégrer de nouvelles fonctionnalités et améliorer les performances. De l’autre, la complexité des interactions entre le réseau, le mempool, Tor et les règles de consensus crée des cas limites difficiles à anticiper.
L’utilisation de Tor avec Bitcoin est devenue plus courante ces dernières années. De nombreux opérateurs cherchent à masquer leur adresse IP réelle, surtout dans des contextes où la surveillance ou les pressions réglementaires augmentent. Les logiciels qui proposent des configurations « prêtes à l’emploi » avec Tor et whitelist ont multiplié le nombre de nœuds exposés sans que les utilisateurs en aient pleinement conscience.
La politique de divulgation de Bitcoin Core a également évolué. Une modification introduite en octobre 2025 permet désormais de publier plus rapidement certaines failles facilement redécouvertes, y compris celles qui pourraient être trouvées par une simple invite d’intelligence artificielle. Cette accélération vise à réduire la fenêtre pendant laquelle des attaquants pourraient exploiter des bugs encore non patchés sur des versions en fin de support.
Les leçons pour les opérateurs de nœuds
La première leçon est évidente : mettre à jour régulièrement. Les versions 30.0 et 29.2 contiennent tous les correctifs nécessaires. Rester sur une version plus ancienne expose non seulement aux failles déjà connues, mais aussi à celles qui seront découvertes ultérieurement.
La deuxième leçon concerne la configuration. L’option whitelist est puissante, mais dangereuse lorsqu’elle est mal utilisée. Si vous faites tourner Bitcoin Core derrière Tor, vérifiez scrupuleusement les permissions accordées. Les connexions onion entrantes ne devraient jamais bénéficier des mêmes privilèges que des pairs de confiance locaux.
Troisièmement, la surveillance active du nœud reste indispensable. Un mempool incohérent, des délais anormaux dans la réception des blocs ou un comportement inhabituel des pairs peuvent signaler qu’une vulnérabilité est en train d’être exploitée, même si le correctif officiel n’est pas encore appliqué.
Enfin, la diversité des implémentations et des configurations reste un atout. Un réseau où tous les nœuds tournent exactement la même version avec les mêmes options est plus fragile. La présence de nœuds configurés différemment, y compris sans Tor ou sans whitelist, limite la portée d’une faille comme celle qui vient d’être révélée.
Impact réel sur la confidentialité et la résilience du réseau
La faille Tor n’a pas permis de compromettre le consensus ni de voler des bitcoins. Elle a cependant affaibli les protections de confidentialité et de résistance au déni de service pour un nombre non négligeable de nœuds. Dans un contexte où la surveillance des flux de transactions et l’analyse de réseau progressent, chaque trou dans le blindage a son importance.
Les mineurs, de leur côté, ont pu être affectés par le bug de mempool. Un nœud incapable de produire un template de bloc valide pendant plusieurs minutes ou heures représente une perte de revenus potentielle et une fragilité temporaire pour l’ensemble du réseau de minage.
Les délais introduits par la faille des compact blocks, bien que moins critiques, illustrent comment un attaquant déterminé peut dégrader la performance globale sans nécessairement casser le protocole. Ces attaques de surface restent dangereuses parce qu’elles sont difficiles à détecter et encore plus difficiles à attribuer.
Ce que révèle cette série de divulgations
Trois failles publiées le même jour, découvertes à des moments différents, corrigées sur des délais variables, montrent que le processus de sécurité de Bitcoin Core fonctionne. Les chercheurs indépendants continuent de trouver des problèmes, les développeurs réagissent, les versions sont patchées, et la communauté est informée une fois le risque maîtrisé.
Pourtant, ces événements rappellent aussi que la sécurité n’est jamais acquise. Chaque nouvelle fonctionnalité, chaque optimisation, chaque intégration avec des outils tiers comme Tor introduit de nouvelles surfaces d’attaque. La vigilance collective reste le seul véritable filet de sécurité.
Les opérateurs qui ont déjà mis à jour leurs nœuds peuvent respirer un peu plus tranquillement. Ceux qui ne l’ont pas encore fait devraient considérer cette divulgation comme un signal clair. Le réseau Bitcoin reste robuste, mais sa robustesse dépend de la réactivité de ceux qui le font tourner au quotidien.
Regarder vers l’avenir
Les prochaines versions de Bitcoin Core intégreront sans doute de nouvelles protections autour de Tor et des permissions de whitelist. Des discussions sont déjà en cours pour rendre certaines configurations plus sûres par défaut. L’idée n’est pas d’interdire l’usage de Tor, mais de s’assurer que son utilisation ne crée pas de nouveaux points faibles.
La communauté de chercheurs en sécurité autour de Bitcoin reste active. Les rapports de Martin Zumsande, Antoine Poinsot, Niklas Goegge et Eugene Siegel montrent qu’il existe un écosystème de personnes qui scrutent le code en permanence. C’est une force. Tant que ce regard critique se maintient, les failles continueront d’être trouvées et corrigées avant de devenir catastrophiques.
Pour l’utilisateur final, le message est simple. Si vous faites tourner un nœud, mettez-le à jour. Si vous utilisez Tor, vérifiez vos permissions. Si vous minez, assurez-vous que votre logiciel est capable de gérer correctement les réorganisations. Ces gestes, apparemment anodins, sont ceux qui maintiennent le réseau décentralisé et résilient année après année.
La révélation de cette faille Tor n’est pas une crise. C’est un rappel utile. Bitcoin continue d’évoluer, les attaquants aussi, et la seule réponse durable reste la combinaison d’un code rigoureux, d’une divulgation responsable et d’opérateurs attentifs. Les milliers de nœuds qui ont été exposés pendant des mois l’ont été par inadvertance. L’objectif maintenant est de s’assurer que cela ne se reproduise plus.
Dans un monde où la confidentialité devient un enjeu de plus en plus sensible, chaque détail de configuration compte. Les développeurs de Bitcoin Core l’ont bien compris en corrigeant rapidement le problème. Il appartient désormais à chaque opérateur de faire sa part pour que le réseau reste aussi sûr qu’il le prétend.
