Faille Bitcoin Core : la liste blanche Tor a ouvert des milliers de nœuds à des inconnus

Bitcoin Core a publié le 10 novembre 2026 trois nouvelles failles de sécurité. La plus lourde de conséquences concerne les nœuds qui font tourner Bitcoin Core avec le réseau d’anonymisation Tor : tout opérateur ayant activé l’option -whitelist pour une plage d’adresses IP traitait aussi, jusqu’aux versions 28.3, 29.2 et 30.0, chaque connexion Tor entrante comme un pair de confiance. Selon les développeurs, des milliers de nœuds accessibles sur le réseau principal étaient concernés. Les trois failles sont corrigées depuis plus d’un an, si bien que vous êtes protégé si votre nœud est à jour. Si vous utilisez encore une version antérieure à 30.0, il convient de mettre à jour dès maintenant, car la branche 29.x, la dernière concernée, n’est plus maintenue depuis le 27 octobre.

Bitcoin Core est le logiciel de référence du réseau Bitcoin. Un nœud (node en anglais) est un ordinateur qui exécute ce logiciel, vérifie lui-même chaque bloc et relaie les transactions vers d’autres nœuds. Avec votre propre nœud, vous ne dépendez pas de serveurs tiers pour connaître votre solde. Nous avons chiffré l’effort et la consommation électrique que cela représente dans notre dossier faire tourner un nœud Bitcoin.

Faille Bitcoin Core : trois divulgations le 10 novembre

Les trois avis portent les identifiants CVE-2025-62859, CVE-2025-62860 et CVE-2025-62861. Un numéro CVE (Common Vulnerabilities and Exposures) est un identifiant unique au niveau mondial attribué à une faille de sécurité rendue publique. Bitcoin Core classe deux des trois failles en gravité moyenne et une en gravité élevée. Le calendrier obéit à la règle de divulgation du projet : une faille n’est décrite publiquement que lorsque la dernière branche concernée ne bénéficie plus d’aucune maintenance.

Ce seuil est atteint depuis le 27 octobre 2026. Ce jour-là a pris fin la maintenance de Bitcoin Core 29.x, après la publication de la version 32.1 le 27 octobre. Les versions de maintenance 31.2, 30.4 et 29.5 ont suivi le 28 octobre, et le projet avait déjà divulgué le même jour trois autres failles, que nous avons présentées dans notre article sur trois failles de sécurité dans Bitcoin Core. Les nouveaux avis constituent la deuxième vague en deux semaines, mais ils touchent d’autres parties du logiciel.

Point commun aux trois cas, des développeurs externes ont découvert les failles et les ont signalées de manière confidentielle à la liste de sécurité du projet. Les correctifs ont été intégrés discrètement dans les versions 28.3, 29.2 et 30.0, publiées entre le 10 et le 20 octobre 2025. Ils ne sont décrits publiquement que maintenant, un peu plus d’un an plus tard.

Liste blanche Tor de Bitcoin Core : pourquoi les connexions Tor étaient jugées fiables

La faille référencée CVE-2025-62860 se loge dans un paramètre que de nombreux particuliers n’ont jamais configuré eux-mêmes. Avec -whitelist, un opérateur désigne certains pairs comme dignes de confiance. Pour eux, selon l’avis de sécurité du projet, Bitcoin Core lève plusieurs limites contre les attaques par saturation et assouplit des protections censées empêcher la fuite d’informations sur le nœud. La fonction est prévue pour vos propres appareils sur le réseau domestique, par exemple un second ordinateur ou un logiciel de portefeuille qui dialogue directement avec le nœud.

Le problème tient à la façon dont Tor achemine les connexions. Un ordinateur étranger qui atteint un nœud via Tor n’apparaît pas pour Bitcoin Core sous sa propre adresse. Seule l’adresse du service Tor est visible, et celui-ci tourne le plus souvent sur le même appareil ou sur le même réseau domestique. Si cette adresse se trouvait dans la plage IP que l’opérateur avait autorisée via -whitelist, chaque connexion Tor entrante atterrissait sur la liste des pairs de confiance. N’importe quel participant venu d’Internet obtenait ainsi les mêmes droits que votre propre appareil du salon.

Le défaut est corrigé dans Bitcoin Core 30.0 et toutes les versions ultérieures, ainsi qu’à partir des versions de maintenance 28.3 et 29.2. Depuis, les connexions Tor entrantes qui arrivent par une adresse configurée spécialement pour Tor (onion bind) ne reçoivent jamais de droits de liste blanche. Les nœuds qui n’avaient jamais activé l’option -whitelist n’ont été concernés à aucun moment, selon les développeurs.

La faille a été découverte par les développeurs de Bitcoin Core Martin Zumsande et Antoine Poinsot, qui l’ont signalée à l’équipe de sécurité le 12 septembre 2025. Le correctif a été intégré le 17 septembre 2025 puis reporté sur les branches plus anciennes. Le même jour, selon l’avis, Antoine Poinsot a également prévenu Luke Dashjr, qui maintient le logiciel de nœud alternatif Bitcoin Knots, puis plusieurs éditeurs de logiciels concernés le 19 septembre.

Nœud Bitcoin clés en main : d’où venaient les milliers de nœuds touchés

Si la faille a eu une telle portée, c’est en raison d’une habitude du secteur. Selon l’avis de sécurité, des fournisseurs répandus livraient Bitcoin Core avec un service Tor et réglaient d’usine l’option -whitelist sur une plage IP qui englobait aussi le service Tor. S’y ajoutait le fait que des logiciels complémentaires reposant sur Bitcoin Core exigeaient ce paramètre de liste blanche pour fonctionner. Ces programmes tournent souvent à côté d’un service Tor. Les développeurs décrivent le résultat ainsi : des milliers de nœuds accessibles sur le réseau principal plaçaient chaque connexion Tor entrante sur liste blanche.

Pour de nombreux particuliers, le tableau est familier. Les solutions de nœud prêtes à l’emploi pour petits ordinateurs regroupent Bitcoin Core, Tor, un serveur pour les requêtes de portefeuille et souvent un logiciel Lightning sous une interface graphique. L’utilisateur voit rarement le fichier de configuration. L’avis ne précise pas si telle ou telle solution était concernée, les fabricants ayant été informés il y a un peu plus d’un an. Si vous utilisez une telle solution, vous trouverez en général la version de Bitcoin Core employée dans l’aperçu des applications ou dans les notes de version de l’ensemble.

La distinction entre la solution elle-même et la version de Bitcoin Core qu’elle contient est essentielle. Une solution peut avoir été mise à jour récemment et embarquer malgré tout une version plus ancienne de Bitcoin Core si l’application concernée n’a pas suivi. Pour les trois failles, seul compte le numéro de version de Bitcoin Core.

CVE-2025-62859 : les compact blocks et l’attente de dix minutes

La deuxième faille de gravité moyenne concerne la manière dont les nœuds échangent les nouveaux blocs de façon économe. Les compact blocks sont une méthode dans laquelle un nœud ne transmet pas le bloc entier, mais seulement de courts identifiants des transactions qu’il contient. Le destinataire reconstitue le bloc à partir des transactions qu’il détient déjà dans sa mémoire tampon. Cela économise de la bande passante et accélère la diffusion des nouveaux blocs sur le réseau.

Avant les versions 29.2 et 30.0, Bitcoin Core réinitialisait son état de téléchargement après avoir reconstitué un tel bloc, avant de vérifier une manipulation précise des données de signature (witness malleation). Si ce contrôle échouait, le nœud redemandait le bloc au même pair, avec un délai d’attente de dix minutes. Un attaquant qui annonçait le premier un nouveau bloc à un nœud pouvait ainsi bloquer son traitement des blocs.

L’avis cite deux conditions dans lesquelles l’attaque pouvait être répétée sans fin : lorsque l’attaquant contrôlait les trois pairs que le nœud utilise pour la transmission rapide des blocs, ou lorsque le nœud fonctionnait en mode -blocksonly, c’est-à-dire qu’il ne relayait que des blocs et aucune transaction isolée. La faille a été découverte par le développeur Eugene Siegel et signalée le 28 avril 2025. Le correctif de Gregory Sanders a été intégré le 30 juin 2025.

Pour un nœud domestique, un tel blocage signifie surtout qu’il prend du retard sur les nouveaux blocs. Le portefeuille qui y est relié affiche alors plus tardivement les paiements entrants. Si vous recevez des bitcoins et confirmez leur arrivée via votre propre nœud, vous voyez dans le pire des cas un état périmé.

CVE-2025-62861 : les transactions TRUC paralysent les mineurs après une réorganisation

La seule faille classée en gravité élevée touche avant tout les mineurs. TRUC signifie Topologically Restricted Until Confirmation et désigne les transactions de version 3 selon le BIP 431. Des règles plus strictes s’y appliquent jusqu’à leur confirmation : au plus un parent non confirmé et au plus un enfant non confirmé. Ces règles ne valent que pour la mémoire tampon d’un nœud (mempool), et non pour les règles de consensus. Un bloc valide peut donc tout à fait être structuré autrement.

Depuis la version 28.0, Bitcoin Core applique à ces transactions une règle de remplacement appelée sibling eviction. Lorsqu’une transaction TRUC reçoit un second enfant non confirmé, le nouvel enfant évince l’ancien s’il paie suffisamment de frais. Lors d’une réorganisation, c’est-à-dire lorsqu’un nœud bascule vers une suite de blocs concurrente plus longue, Bitcoin Core replace dans le mempool les transactions des blocs abandonnés. La règle d’éviction continuait alors à s’appliquer à tort.

Conséquence selon l’avis : il restait dans le mempool des transactions qui dépensaient des sorties n’y figurant plus. Un mineur dont le nœud subissait une telle réorganisation ne pouvait plus produire de modèle de bloc valide avant d’avoir redémarré le nœud. Les versions 28.0 à 28.2 et 29.0 à 29.1 sont concernées, et la faille est corrigée dans Bitcoin Core 30.0 du 10 octobre 2025. Elle a été signalée par Niklas Gögge le 26 septembre 2025.

Gravité élevée et moyenne : le classement des trois failles Bitcoin Core

Bitcoin Core range chaque faille signalée dans l’une des quatre catégories que le projet décrit sur sa page consacrée aux avis de sécurité. Sont considérées comme critiques les failles qui menacent la sécurité de l’ensemble du réseau, par exemple le vol de coins au niveau du protocole, la création de coins en dehors du calendrier d’émission fixé ou une scission durable du réseau. Aucune des trois nouvelles failles ne relève de cette catégorie.

La gravité élevée (High) couvre les failles ayant un effet important sur les nœuds concernés ou sur le réseau, généralement exploitables à distance et avec les paramètres par défaut. La gravité moyenne (Medium) couvre les failles qui dégradent sensiblement les performances ou le fonctionnement, mais dont la portée ou l’exploitabilité est limitée. Pour la faille Tor, cela signifie que le défaut n’opérait qu’avec une liste blanche activée, mais touchait alors un très grand nombre de nœuds à la fois.

Ce classement aide à mesurer l’urgence d’une mise à jour. Un nœud domestique qui ne produit pas de blocs n’est pratiquement pas concerné par la faille TRUC de gravité élevée, puisqu’elle touche la création de modèles de bloc. Pour les particuliers, les deux failles de gravité moyenne sont les plus importantes, car elles touchent la confidentialité et la disponibilité de leur propre nœud.

Bitcoin Core 29.x en fin de maintenance : plus de correctifs de sécurité depuis le 27 octobre

Selon sa propre règle de cycle de vie, le projet maintient toujours les trois versions majeures les plus récentes. Depuis la version 32.0, il s’agit de 32.x, 31.x et 30.x. Les versions majeures qui sortent de cette fenêtre ne reçoivent en principe plus de correctifs de sécurité. Les versions actuelles sont 32.1 du 27 octobre ainsi que 31.2 et 30.4 du 28 octobre 2026.

Si vous utilisez encore une version 29, vous disposez certes avec 29.5 d’une version corrigée pour les trois nouvelles failles, mais vous ne recevrez plus de correctifs à l’avenir. Passer à une version majeure maintenue est donc la voie la plus propre. Avant un saut de version important, il est utile de lire les notes de version, car les paramètres par défaut peuvent changer.

La commande bitcoin-cli --version affiche votre version, tout comme la sortie de bitcoin-cli getnetworkinfo dans le champ subversion, où figure par exemple /Satoshi:30.4.0/. Dans l’interface graphique Bitcoin-Qt, vous trouverez l’information sous Aide puis À propos. Pour les solutions clés en main, elle apparaît généralement dans l’aperçu des applications installées.

Liste blanche dans bitcoin.conf : les lignes qui doivent attirer l’attention

Quelle que soit la version, un coup d’œil au fichier de configuration bitcoin.conf est utile. Les lignes commençant par whitelist= accordent des droits particuliers à des pairs. Si une plage IP entière y figure, par exemple le réseau du routeur domestique ou un réseau interne de conteneurs, vous devez savoir quels appareils s’y trouvent et si un service Tor en fait partie. Si vous n’avez pas créé le fichier vous-même, vous n’y accéderez souvent, avec les solutions clés en main, que par un accès avancé à la machine.

À partir de Bitcoin Core 30.0, 29.2 et 28.3, le logiciel ne considère de toute façon plus comme fiables les connexions Tor entrantes qui arrivent par l’adresse configurée à cet effet. Avec une version à jour, le cœur de la faille est donc refermé, même si la ligne de liste blanche reste inchangée. Une liste blanche resserrée demeure néanmoins une bonne pratique, car chaque exception lève des barrières de protection.

Avoirs en bitcoin et portefeuille : pourquoi les failles ne coûtent aucun coin

Bonne nouvelle pour les investisseurs : selon le classement du projet, aucune des trois failles ne permettait de voler des coins ou d’en créer de nouveaux. Chez la plupart des particuliers, les clés privées se trouvent de toute façon dans un portefeuille séparé et non dans le nœud lui-même. Si vous conservez vos avoirs sur un portefeuille matériel et n’utilisez le nœud que comme instance de vérification personnelle, vous séparez proprement clés et logiciel réseau. Notre comparatif des portefeuilles matériels présente les appareils adaptés.

Les risques portaient sur la disponibilité et la confidentialité. Un pair disposant de droits de liste blanche est soumis à moins de limites contre la saturation et reçoit des informations que le nœud refuse d’ordinaire aux inconnus. Pour les utilisateurs qui recourent à Tor justement pour l’anonymat, c’est le point le plus sensible. Un nœud qui prend du retard sur les nouveaux blocs affiche en outre les paiements entrants avec retard.

Si vous n’exploitez pas votre propre nœud, les trois failles ne vous concernent pas directement. Les portefeuilles logiciels sur smartphone interrogent généralement des serveurs tiers exploités par le fournisseur, et les plateformes d’échange conservent les coins de leurs clients sur leur propre infrastructure. Notre comparatif des portefeuilles logiciels donne un aperçu des portefeuilles qui fonctionnent sans nœud personnel.

Failles Bitcoin Core : toutes trois refermées depuis la version 30

Les trois divulgations du 10 novembre décrivent des failles corrigées depuis octobre 2025. Est exposé celui qui exploite un nœud sous une version plus ancienne et repousse la mise à jour depuis un an. Trois étapes suffisent :

1. Vérifier la version et mettre à jour : si votre nœud est en dessous de 30.0, passez à une version majeure maintenue comme 30.4, 31.2 ou 32.1. Si vous détenez vos coins uniquement sur une plateforme d’échange, vous n’avez pas besoin de nœud personnel ; vous trouverez des prestataires sérieux dans notre comparatif des plateformes d’échange crypto.
2. Réduire la liste blanche : passez en revue chaque ligne commençant par whitelist= dans bitcoin.conf et limitez-la aux appareils que vous connaissez réellement. Pour les requêtes de portefeuille sans nœud personnel, notre comparatif des portefeuilles logiciels vous aidera.
3. Séparer les clés du nœud : conservez les avoirs importants sur un portefeuille matériel et n’utilisez le nœud que pour la vérification. Le comparatif des portefeuilles matériels présente les appareils adaptés.

(Au 11 novembre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)