Le projet Bitcoin Core a divulgué trois failles de sécurité le mardi 10 novembre 2026, toutes corrigées depuis plus d’un an. La plus grave, CVE-2025-62861, est classée « High » (gravité élevée) : après une réorganisation de la chaîne, elle pouvait empêcher un nœud de minage de construire des modèles de blocs tant qu’on ne le redémarrait pas. Une deuxième, CVE-2025-62860, accordait le statut de pair de confiance aux connexions Tor entrantes sur les nœuds qui utilisaient un réglage de liste blanche non activé par défaut, et l’avis indique que des milliers de nœuds accessibles du réseau principal étaient dans ce cas. La troisième, CVE-2025-62859, permettait à un pair hostile de bloquer le traitement des blocs. Ces deux dernières sont classées « Medium » (gravité moyenne).
Les correctifs sont arrivés avec Bitcoin Core 30.0 le 10 octobre 2025, puis avec la 29.2 le 14 octobre et, pour deux des trois failles, avec la 28.3 quelques jours plus tard. Tout nœud sous 29.2, 30.0 ou une version plus récente les a déjà. Les avis publiés sur bitcoincore.org ne signalent aucune exploitation, et Decrypt n’en a pas relevé non plus. Aucune des trois failles ne permet de déplacer ou de voler des bitcoins : au pire, elles empêchent un nœud de faire son travail pendant un temps.
Les personnes qui détiennent du bitcoin sur une plateforme d’échange ou dans un portefeuille mobile n’ont rien à faire. Le public de ces avis est plus restreint : les mineurs et les pools de minage, les entreprises qui font tourner leurs propres nœuds, et les nombreux particuliers qui exploitent chez eux un boîtier de nœud prêt à l’emploi, là où la faille Tor a fait le plus de dégâts.
Les notes de version de Bitcoin Core 32.1, publiées le 27 octobre, annonçaient que trois failles de gravité moyenne ou élevée corrigées dans la 30.0 seraient divulguées deux semaines plus tard, comme le rappelait notre article sur les premiers bugs de Bitcoin Core trouvés par une IA. Ce lot est distinct de ceux d’octobre : ces derniers avaient été détectés par un balayage automatisé et rendus publics aussitôt, selon la procédure accélérée prévue pour les défauts faciles à découvrir. Les trois failles du jour ont été signalées par des personnes entre avril et septembre 2025 et ont suivi l’embargo ordinaire.
Trois failles de Bitcoin Core, une seule date de divulgation
Les trois avis sont sortis ensemble parce qu’ils partagent la même dernière branche vulnérable, la 29.x, arrivée en fin de vie le 27 octobre 2026. Chacune est résumée ci-dessous.
| CVE | Effet | Gravité | Versions concernées | Corrigée dans | Signalée par (date) |
|---|---|---|---|---|---|
| CVE-2025-62861 | Bloque la création de modèles de blocs après une réorganisation | High | 28.0 à 28.2, 29.0 à 29.1 | 28.3, 29.2, 30.0 | Niklas Goegge (26 sept. 2025) |
| CVE-2025-62860 | Donne les droits de liste blanche aux pairs Tor entrants | Medium | Avant 28.3, 29.2 et 30.0, avec -whitelist activé | 28.3, 29.2, 30.0 | Martin Zumsande et Antoine Poinsot (12 sept. 2025) |
| CVE-2025-62859 | Bloque le traitement des blocs par malléation de témoin | Medium | Avant 29.2 et 30.0 | 29.2, 30.0 | Eugene Siegel (28 avr. 2025) |
Seule CVE-2025-62861 porte l’étiquette High. Un détail diffère d’une page à l’autre : l’avis de CVE-2025-62861 date la version 28.3 du 17 octobre 2025, celui de CVE-2025-62860 du 20 octobre.
La faille de gravité élevée : une réorganisation pouvait geler les modèles de blocs d’un mineur
CVE-2025-62861 se trouve dans la mempool, la salle d’attente où un nœud garde les transactions non confirmées, et concerne un type de transaction récent. Les transactions TRUC (Topologically Restricted Until Confirmation), définies dans le BIP 431, sont des transactions de version 3 soumises à des limites strictes sur leur « famille » non confirmée : un parent TRUC ne peut avoir qu’un seul enfant non confirmé. La version 28.0 a ajouté l’« éviction de fratrie » (sibling eviction), qui permet à un nouvel enfant payant assez de frais de remplacer l’enfant existant.
Ces limites relèvent de la politique de mempool, pas des règles de consensus. Un bloc valide peut contenir des familles de transactions que la mempool d’un nœud refuserait. Cela compte lors d’une réorganisation, quand le nœud abandonne un ou deux blocs de sa chaîne au profit d’une branche plus longue et remet les transactions des blocs abandonnés dans sa mempool. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il le fait avec un indicateur, bypass_limits, censé justement sauter les contrôles de politique.
Le code d’éviction de fratrie ignorait cet indicateur. Pendant une réorganisation, il pouvait expulser une transaction en cours de restauration tout en laissant ses descendantes dans la mempool. Ces descendantes dépensaient alors des sorties qui n’existaient plus nulle part.
L’avis porte sur les conséquences pour les mineurs. Quand le nœud assemble un modèle de bloc, la liste des transactions qu’un pool transmet à ses machines, il exécute un contrôle de validité sur le résultat. Avec des descendantes orphelines à l’intérieur, le contrôle échouait et le nœud ne pouvait plus produire de blocs avant un redémarrage, qui recharge une mempool cohérente. Des réorganisations d’un bloc se produisent bien sur bitcoin, mais il fallait en plus que les blocs concernés contiennent les bonnes transactions TRUC.
Niklas Goegge a signalé le problème à la liste de diffusion de sécurité de Bitcoin Core le 26 septembre 2025. Greg Sanders a ouvert le correctif, la pull request n° 33 504, trois jours plus tard : il fait respecter bypass_limits par les contrôles TRUC, a été fusionné le 2 octobre et rétroporté dans les branches 29.x, 30.x et 28.x entre le 3 et le 7 octobre. Seules les versions 28.0 à 28.2 et 29.0 à 29.1 étaient touchées, puisque l’éviction de fratrie n’existait pas avant la 28.0.
Un tour de passe-passe avec les blocs compacts pouvait bloquer un nœud
CVE-2025-62859 vise le relais de blocs compacts, la méthode qu’utilisent les nœuds pour diffuser rapidement les nouveaux blocs. Au lieu d’envoyer un bloc complet, un pair envoie un court résumé, et le nœud récepteur reconstruit le bloc à partir des transactions qu’il a déjà dans sa mempool. Un nœud choisit jusqu’à trois pairs « à haute bande passante » qui lui poussent les blocs compacts sans qu’il les demande.
Dans les versions touchées, le nœud effaçait son état de téléchargement d’un bloc compact juste après l’avoir reconstruit, mais avant de vérifier que les données de témoin (witness) du bloc n’avaient pas été altérées, c’est-à-dire « malléées ». Si cette vérification échouait, le nœud redemandait le bloc complet au même pair, avec un délai d’attente de 10 minutes. Un pair malveillant arrivé le premier avec l’annonce d’un bloc pouvait donc suspendre le traitement des blocs de sa victime pendant dix minutes. Selon l’avis, l’attaquant pouvait recommencer indéfiniment s’il contrôlait les trois pairs à haute bande passante de la victime, ou si celle-ci fonctionnait en mode -blocksonly.
Eugene Siegel a signalé la faille le 28 avril 2025. Gregory Sanders a ouvert le correctif, la pull request n° 32 646, le 30 mai ; il a été fusionné le 30 juin et rétroporté dans la branche 29 le 12 septembre. L’avis ne liste de correctifs que dans les versions 29.2 et 30.0 et ne cite aucune version 28.x corrigée : la lecture prudente est donc que la branche 28.x et les plus anciennes restent exposées à celle-ci.
La faille Tor et la liste blanche : un statut de confiance pour des inconnus sur des milliers de nœuds
CVE-2025-62860 est celle qui concerne le plus les particuliers qui font tourner un nœud. Bitcoin Core dispose d’une option, -whitelist, qui accorde des permissions spéciales aux pairs se connectant depuis certaines adresses IP. Les pairs de la liste blanche sont traités comme des pairs de confiance : le nœud relâche pour eux certaines limites contre les attaques par déni de service et une partie des protections qui évitent de laisser filtrer des informations à des pairs capables d’espionner les transactions. L’option est désactivée par défaut et destinée aux machines que l’opérateur contrôle.
Le problème tient à l’apparence des connexions Tor vues de l’intérieur. Un nœud joignable comme service caché Tor reçoit toutes ses connexions Tor entrantes du démon Tor local : elles semblent donc toutes venir de la même adresse, généralement sur la même machine ou le même réseau. Si la liste blanche couvrait cette adresse, chaque inconnu arrivant par Tor héritait du statut de confiance.
Selon l’avis, des fournisseurs répandus livraient Bitcoin Core avec un démon Tor intégré et réglaient -whitelist sur la plage d’adresses de ce démon, et les logiciels clients utilisés à côté de Tor exigeaient couramment l’option, eux aussi. C’est ainsi que des milliers de nœuds accessibles du réseau principal ont fini par mettre en liste blanche toutes les connexions Tor entrantes. L’avis ne nomme aucun fournisseur : les utilisateurs de nœuds domestiques préconfigurés qui embarquent Tor doivent donc vérifier plutôt que supposer.
Martin Zumsande et Antoine Poinsot ont signalé le problème le 12 septembre 2025. Le correctif, la pull request n° 33 395, ouverte le 15 septembre, a été fusionné et rétroporté le 17 septembre : dans les versions corrigées, les connexions entrantes reçues sur une adresse onion ne sont jamais mises en liste blanche, quel que soit le réglage. Le même jour, Antoine Poinsot a prévenu Luke Dashjr, mainteneur de Bitcoin Knots, un client distinct dérivé de Bitcoin Core, puis, le 19 septembre, plusieurs fournisseurs de logiciels concernés. Les versions corrigées ont suivi en octobre 2025.
Combien de nœuds affichent encore des versions touchées
Les comptages du réseau donnent une idée de la diffusion des correctifs, avec des limites. Dans l’instantané de Bitnodes du 11 novembre 2026 à 17 h 01 UTC (hauteur de bloc 975 450), 20 111 nœuds accessibles étaient recensés. Leurs versions viennent des « user agents » que les nœuds déclarent eux-mêmes, qui peuvent être modifiés ou falsifiés, et les nœuds qui n’acceptent aucune connexion entrante ne sont pas comptés du tout. D’après le décompte de Coindaro sur ce fichier, 18 048 des 20 111 annonçaient un user agent Bitcoin Core simple, 2 001 un user agent Knots et 62 autre chose.
| User agents Bitcoin Core de l’instantané | Nœuds | Part des agents Core |
|---|---|---|
| Dans les plages de CVE-2025-62861 (28.0 à 28.2, 29.0 à 29.1) | 1 850 | environ 10,3 % |
| Avant la 29.2 (CVE-2025-62859, borne haute) | 3 913 | environ 21,7 % |
| Sous les versions corrigées de CVE-2025-62860 | 3 861 | environ 21,4 % |
| Version la plus répandue, 32.1.0 | 4 567 | environ 25,3 % |
Ces parts surestiment l’exposition réelle. La faille de gravité élevée ne touche que les nœuds qui construisent des modèles de blocs, et le nombre de nœuds de minage encore sous une version touchée est invisible de l’extérieur : l’infrastructure des pools est rarement joignable. La faille Tor ne concernait que les nœuds où -whitelist était activé, une proportion qu’aucun explorateur ne mesure. Le chiffre de 1 850 est dominé par la 28.1.0 (578 agents simples et 311 de plus issus d’une version FutureBit), la 29.0.0 (463), la 28.0.0 (231) et la 29.1.0 (160).
Knots, avec 2 001 nœuds accessibles, surtout sous sa version 29.3, est un client différent, et les avis de Bitcoin Core ne disent rien de son statut. Le problème plus large des nœuds qui tournent sur des branches abandonnées a fait l’objet de notre décompte des nœuds Bitcoin Core en fin de vie, qui plaçait environ 44 % des agents Core hors des branches maintenues dans une collecte du 18 octobre.
Ce que les opérateurs de nœuds doivent vérifier maintenant
Les branches maintenues aujourd’hui sont les 30.x, 31.x et 32.x. Leurs dernières versions, la 32.1 (27 octobre) ainsi que les 30.4 et 31.2 (28 octobre), embarquent aussi les correctifs des avis d’octobre. Voici ce qu’il faut faire :
- Vérifiez la version que votre nœud déclare (bitcoin-cli getnetworkinfo l’affiche, et la plupart des tableaux de bord de nœud aussi). Tout ce qui est antérieur à la 30.0 se trouve sur une branche qui ne reçoit plus de correctifs.
- Passez à la 30.4, à la 31.2 ou à la 32.1, téléchargée depuis bitcoincore.org, et vérifiez les signatures avant d’installer.
- Si vous utilisez un nœud préconfiguré avec Tor, mettez le paquet à jour et regardez le fichier bitcoin.conf qu’il génère : une plage -whitelist incluant l’adresse du démon Tor n’a pas sa place dans les anciennes versions.
- Les pools de minage et les mineurs solo dont le nœud a cessé de produire des modèles après une réorganisation, sur une version touchée, doivent le redémarrer puis le mettre à jour.
Pour celles et ceux qui installent un nœud pour la première fois, notre guide pas à pas pour faire tourner un nœud Bitcoin couvre les téléchargements, la vérification des signatures et les mises à jour.
Pourquoi les avis ont attendu 13 mois
Selon la politique de divulgation du projet, chaque faille reçoit un niveau de gravité. Les failles de faible gravité sont divulguées deux semaines après la sortie du correctif. Celles de gravité moyenne ou élevée restent privées jusqu’à deux semaines après la fin de vie de la dernière branche contenant la faille, soit environ un an après la première sortie de la version majeure qui la corrige. Les failles critiques feraient très probablement l’objet d’une procédure ad hoc. Ce délai de 13 mois n’a rien d’inhabituel : CVE-2024-52911, un plantage de gravité élevée corrigé dans la 29.0 en avril 2025, a été divulgué le 5 mai 2026.
Le compromis saute aux yeux dans ce lot. Le correctif de la faille Tor était du code public depuis septembre 2025, lisible par quiconque ouvrait la pull request, alors que l’explication de ce qu’il fermait est restée privée jusqu’à cette semaine. Les opérateurs qui ne mettent à jour qu’à la parution d’un avis ont été couverts par le délai, mais sans jamais savoir pourquoi. Le changement d’octobre, qui publie sans attendre les bugs faciles à trouver avec leur correctif, a déplacé une partie du processus dans l’autre sens.
Le prochain lot de ce genre dépend de la branche 30.x, désormais la plus ancienne encore maintenue. La page du cycle de vie du projet place sa fin de vie après la sortie de la 33.0, et toute faille de gravité moyenne ou élevée qu’elle contiendrait encore serait divulguée deux semaines après.