Bitcoin Core a publié en novembre 2026 les détails de trois vulnérabilités de sécurité, environ un an après la sortie des correctifs. La plus grave des trois, notée Élevé (High), pouvait empêcher les nœuds miniers de produire des modèles de blocs valides après une réorganisation de la chaîne.

Bitcoin Core est l'implémentation de référence du protocole Bitcoin. Les nœuds du réseau s'appuient sur ce logiciel open source pour valider et relayer les transactions et les blocs, tandis que les mineurs et les pools miniers l'utilisent pour assembler des modèles de blocs à partir des transactions non confirmées dans le mempool, la zone d'attente du réseau pour les transactions en attente.

Par politique, le projet ne divulgue les vulnérabilités qu'après un délai : le correctif est d'abord livré dans une version, et la description technique ne suit que lorsque les versions concernées sont devenues obsolètes. Les correctifs de ces failles sont arrivés dans les versions 30.0, 29.2 et 28.3, toutes publiées en octobre 2025. Les avis portent les identifiants CVE-2025-62861, CVE-2025-62859 et CVE-2025-62860 — les identifiants standard sous lesquels les vulnérabilités logicielles divulgées publiquement sont cataloguées. CVE-2025-62861 est notée Élevé ; les deux autres sont notées Moyen. En conséquence, le projet a publié les avis seulement 14 jours après la fin du support de la branche 29.x, la dernière série de versions vulnérable. Les textes complets sont disponibles dans la divulgation officielle et dans l'index des avis de sécurité du projet.

Comment une réorganisation pouvait bloquer les nœuds miniers

La faille de gravité élevée, CVE-2025-62861, affecte les versions 28.0 à 28.2 et 29.0 à 29.1. Niklas Goegge l'a signalée en septembre 2025. Le défaut provient de TRUC — abréviation de Topologically Restricted Until Confirmation — également connues sous le nom de transactions v3. Cette politique du mempool impose des limites strictes à la manière dont les transactions non confirmées peuvent dépendre les unes des autres, et son objectif principal est d'aider les protocoles de couche 2 tels que le Lightning Network à augmenter les frais après coup. La version 28.0 a ajouté une règle supplémentaire appelée sibling eviction : une nouvelle transaction peut tenter d'attacher un second enfant à une transaction parente TRUC et, si elle paie suffisamment de frais, elle remplace l'enfant existant.

Le bug est apparu lors d'une réorganisation (« reorg » en abrégé) — un événement au cours duquel le réseau remplace les blocs ajoutés le plus récemment par une chaîne différente. Bitcoin Core renvoie d'abord les transactions des blocs déconnectés vers le mempool avec le drapeau bypass_limits=true. La branche de sibling eviction, toutefois, ne respectait pas ce drapeau et s'exécutait quand même. En conséquence, la règle évinçait une transaction tandis que ses descendants restaient dans le mempool, laissant dans le mempool des transactions qui dépensaient des sorties qui n'existaient plus. Dès lors, chaque fois que le nœud tentait de construire de nouveaux modèles de blocs, la vérification de validité échouait.

Les mineurs concernés ne pouvaient produire à nouveau des modèles valides qu'après avoir redémarré le nœud, car un redémarrage recharge le mempool dans un état cohérent. Néanmoins, l'avis relatif à CVE-2025-62861 ne mentionne aucune solution de contournement autre que la mise à jour. Greg Sanders a fourni le correctif dans la PR #33504, que le projet a fusionnée dans la branche principale en octobre 2025 puis rétroportée vers les branches 28.x, 29.x et 30.x. La faille n'affectait que la création de modèles : TRUC étant une règle de mempool et non une règle de consensus, le bug n'a pas touché le consensus. Les règles de mempool comme TRUC sont des politiques locales que chaque nœud applique à ses propres transactions en attente, contrairement aux règles de consensus que chaque nœud fait respecter sur la chaîne partagée.

Deux failles moyennes affectent le relais de blocs et les pairs Tor

CVE-2025-62859 affecte les versions antérieures à 29.2 et à 30.0. Eugene Siegel avait signalé la vulnérabilité dès avril 2025. Elle se situe dans la gestion des blocs compacts, le format abrégé que les nœuds utilisent pour se transmettre les nouveaux blocs. Les versions concernées effaçaient l'état de téléchargement d'un tel bloc avant de vérifier la malléabilité du témoin (witness malleation), terme désignant une modification après coup des données de témoin. Si cette vérification échouait, le nœud redemandait les données au même pair via GETDATA, avec un délai d'attente de 10 minutes — soit environ l'intervalle moyen entre les blocs Bitcoin. Un pair malveillant annonçant en premier un bloc compact pouvait donc retarder le traitement des blocs de la victime jusqu'à 10 minutes. De plus, l'attaquant pouvait répéter l'attaque sans limite en mode -blocksonly ou lorsqu'il contrôlait les trois pairs à haute bande passante, le petit ensemble de pairs dont un nœud dépend pour les annonces prioritaires de blocs. La PR #32646, fusionnée en juin 2025, a corrigé le bug.

La seconde faille moyenne, CVE-2025-62860, affecte les versions antérieures à 28.3, 29.2 et 30.0. Martin Zumsande et Antoine Poinsot l'ont signalée en septembre 2025, deux semaines avant que Goegge ne signale la faille élevée. Dans Bitcoin Core, les connexions Tor entrantes apparaissent sous l'adresse IP du démon Tor, le service local qui transmet le trafic provenant du réseau d'anonymat. Si cette adresse se trouvait dans une plage IP autorisée via -whitelist, tous les pairs Tor entrants recevaient les permissions de liste blanche. Ces permissions lèvent les limites anti-DoS et les protections contre les fuites de vie privée.

Selon l'avis, « des milliers » de nœuds mainnet joignables avaient accordé ces droits à toutes les connexions Tor entrantes. Souvent, des fournisseurs livrant Bitcoin Core associé à un démon Tor avaient activé cette option. En revanche, la faille n'a jamais affecté les nœuds dépourvus de ce paramètre facultatif, non activé par défaut. Depuis la PR #33395, Bitcoin Core ne prend plus en compte les pairs Tor entrants lors de l'attribution des permissions de liste blanche.

Le projet note les deux failles comme Moyen. Le retard de traitement des blocs était temporaire, et les attaquants ne pouvaient le répéter à volonté que dans des configurations spécifiques, tandis que la faille Tor exigeait une configuration s'écartant de la valeur par défaut.

Pourquoi une année s'est écoulée entre le correctif et la divulgation

Bitcoin Core sépare délibérément le correctif de la divulgation. La correction est d'abord livrée dans une version normale, et le projet ne décrit pas la vulnérabilité à ce moment ; les détails suivent plus tard, lorsque les versions concernées sont plus anciennes ou ont atteint la fin de leur support. Cela laisse aux opérateurs le temps de se mettre à jour.

Pour les trois avis actuels, les signalements sont parvenus entre avril et septembre 2025, et les correctifs sont entrés dans le code de juin à octobre 2025. Bitcoin Core 30.0, 29.2 et 28.3 ont ensuite été livrés avec les corrections en octobre 2025. La fin du support a déterminé le calendrier de la divulgation : le support de la branche 29.x, la dernière série de versions vulnérable, a pris fin le 27 octobre 2026, et les avis ont suivi le 10 novembre 2026 — soit 14 jours plus tard.

L'index des avis du projet utilise quatre niveaux de gravité : Critique, Élevé, Moyen et Faible. Les trois avis se situent aux niveaux intermédiaires. Le délai de CVE-2025-62859 se distingue : Siegel a signalé la faille en avril 2025, le projet a fusionné le correctif en juin 2025, et les détails ne sont devenus publics que près de 18 mois après le signalement.

Ce que ces failles signifient pour les mineurs et les opérateurs de nœuds

La faille élevée concernait principalement les mineurs et les pools. Seuls les nœuds ayant traversé un reorg et devant ensuite construire des modèles de blocs déclenchaient le bug. En revanche, les deux failles moyennes touchaient également les nœuds ordinaires, mais chacune exigeait une situation réseau ou une configuration spécifique.

Les versions 30.0 et 29.2 corrigent les trois failles, et la 28.3 en corrige deux. Depuis fin octobre 2026, toutefois, seules les versions à partir de 30.x bénéficient du support. Quiconque exécute la version 29.x ou antérieure utilise donc un logiciel sans support, même avec les rétroportages.

Les avis laissent plusieurs questions ouvertes. On ignore par exemple si un attaquant peut créer délibérément la topologie de reorg qui déclenche le bug élevé. Les avis ne précisent pas non plus si l'une des trois failles a déjà été exploitée, et il n'existe pas de décompte exact des nœuds touchés par la faille Tor. Le dossier montre toutefois que le projet a corrigé et livré les trois bugs un peu plus d'un an avant la divulgation.