Bitcoin Core a publié la divulgation officielle de CVE-2025-62861, une faille de gravité élevée dans la logique de relais des transactions du logiciel de nœud, qui pouvait laisser des opérations de minage hasher sur des modèles de blocs obsolètes sans aucun avertissement visible. L'avis crédite le chercheur en sécurité Niklas Goegge du signalement de la vulnérabilité et la fait remonter à une règle de relais qui s'est déclenchée au mauvais moment : pendant une réorganisation de la chaîne, alors qu'elle aurait dû rester silencieuse.

Les versions affectées vont de Bitcoin Core 28.0 à 28.2 et de 29.0 à 29.1. Le correctif est arrivé en octobre 2025, mais les détails techniques complets ont été gardés secrets jusqu'en novembre 2026 conformément à la politique de divulgation coordonnée du projet. L'avis ne mentionne aucune interruption ni aucun opérateur affecté ; l'exposition est historique. Le matériel de minage pointé vers un nœud dans cet état corrompu aurait continué à hasher, mais sur le dernier modèle reçu, de sorte que les nouvelles transactions et leurs frais seraient restés non réclamés jusqu'à ce que quelqu'un s'en aperçoive.

Comment une réorganisation peut orpheliner une transaction

Une réorganisation se produit lorsqu'un nœud abandonne sa pointe de chaîne actuelle au profit d'une branche concurrente plus lourde. Les transactions des blocs déconnectés restent valides, donc Bitcoin Core les replace dans le mempool, sa zone d'attente pour les transactions non confirmées. Comme ces transactions étaient déjà confirmées dans un bloc valide, le nœud les réajoute avec un indicateur appelé bypass_limits, qui désactive les vérifications habituelles anti-spam et de topologie. L'objectif est de restaurer fidèlement le pool, et non de réévaluer des transactions ayant déjà passé le consensus.

L'une des vérifications qui auraient dû être désactivées concerne les transactions de version trois, ou TRUC. Selon BIP 431, une transaction TRUC peut avoir au maximum un parent non confirmé et un enfant non confirmé. Il s'agit d'une politique de relais, et non d'une règle de consensus : un bloc peut légitimement contenir un parent TRUC avec plusieurs enfants, même si aucun nœud n'accepterait cette forme dans son mempool depuis le réseau. Cette même frontière entre politique et consensus a défini la limite du bug lui-même : CVE-2025-62861 pouvait corrompre le mempool d'un nœud et bloquer sa production de modèles, mais il ne pouvait pas créer de bloc invalide ni modifier les règles de la chaîne.

Depuis la version 28.0, Bitcoin Core applique la limite d'un seul enfant via un mécanisme appelé éviction des transactions voisines (sibling eviction). Lorsqu'une nouvelle transaction donnerait à un parent TRUC un second enfant non confirmé, le nœud traite l'enfant existant comme candidat au remplacement et, si le nouvel arrivant paie suffisamment de frais, l'évince selon les règles de replace-by-fee.

Le bug était que l'éviction des transactions voisines s'exécutait même lorsque bypass_limits était activé. Une réorganisation qui restaurait un parent TRUC avec plusieurs enfants — une forme parfaitement valide à l'intérieur du bloc déconnecté — pouvait déclencher l'éviction d'une transaction restaurée tout en laissant dans le pool les transactions qui dépensaient ses sorties. Le mempool contenait alors des enfants dont le parent n'existait plus nulle part : ni dans la chaîne, ni dans le pool.

Le correctif de Greg Sanders a conditionné les vérifications TRUC à bypass_limits, de sorte que l'éviction ne s'exécute plus lors de la restauration après réorganisation. La pull request associée, PR #33504, a également ajouté le scénario de test qui manquait au code d'origine : des transactions provenant de blocs déconnectés plutôt que de pairs.

À quoi ressemble un modèle bloqué du côté du minage

Un nœud transmet le travail au logiciel de minage via getblocktemplate, qui assemble un bloc candidat, le soumet à la vérification de validité propre au nœud et renvoie le hash du bloc précédent, les transactions choisies et la hauteur suivante. Avec une transaction orpheline dans le pool, le bloc candidat assemblé échouait à cette vérification, si bien que l'appel ne pouvait pas renvoyer de travail frais.

De l'extérieur, le nœud semblait sain :

• Processus en cours d'exécution
• Connexions aux pairs ouvertes
• Pointe de chaîne progressant
• Mempool acceptant de nouvelles transactions

Ce qui était réellement défaillant :

• La demande de modèle renvoie une erreur
• Les hashers continuent de travailler sur du travail obsolète
• Aucun bloc ne peut être trouvé sur la pointe actuelle
• L'état persiste jusqu'au redémarrage du nœud

Tout ce qu'un tableau de bord de supervision générique surveille serait resté au vert. Le réseau n'a renvoyé aucun signal non plus : la pointe de chaîne continuait d'avancer — des blocs étaient toujours trouvés, juste pas par cette opération — de sorte que le coût retombait sur le seul mineur bloqué, en hachage incapable de produire un bloc sur la pointe actuelle et en frais qu'il aurait autrement réclamés. La seule chose dont un mineur a besoin du nœud — un modèle à jour — était la seule chose qu'il avait cessé de produire.

Redémarrage, correctif et fin de vie

Redémarrer le nœud recharge le mempool depuis le disque dans un état cohérent, ce qui élimine le symptôme. Cela ne fait rien pour la cause : la prochaine réorganisation présentant la même forme de transaction pourrait à nouveau bloquer le nœud.

La faille sous-jacente a été supprimée en trois versions. La version 30.0 est livrée avec le correctif le 10 octobre 2025, suivie des rétroportages en 29.2 et 28.3. Du signalement privé à la dernière de ces versions, il s'est écoulé trois semaines :

Les deux branches de rétroportage ont depuis quitté le support. La politique de maintenance de Bitcoin Core couvre les trois versions majeures les plus récentes — actuellement 30.x, 31.x et 32.x — et la branche 29.x est arrivée en fin de vie le 27 octobre 2026. Un opérateur qui a répondu à la panne d'origine par un simple redémarrage exécute désormais du code non supporté, avec une description publique précise de la forme de transaction qui la déclenche.

Pourquoi l'avis a attendu 396 jours

De la première version corrigée à l'avis détaillé, il s'est écoulé 396 jours, et la divulgation est tombée exactement deux semaines après la fin de vie de 29.x. Aucun de ces chiffres n'est une coïncidence. La politique de divulgation de Bitcoin Core retient les détails de gravité moyenne et élevée jusqu'à deux semaines après que la dernière version affectée n'est plus supportée, avec une pré-annonce deux semaines avant, calée sur une nouvelle version majeure.

L'embargo couvrait l'explication, et non le code. La pull request est publique depuis le 29 septembre 2025, et les notes de version de 28.3 et 29.2 mentionnaient à l'époque un correctif du mempool. Ce qui est resté privé pendant un an, c'est le document reliant le correctif à un blocage du minage reproductible.

La politique prévoit toutefois une voie plus rapide. Les bugs classés comme facilement découvrables — ce que le projet définit comme trouvables avec un effort minimal — font l'objet d'une publication ponctuelle et d'un avis immédiats, sans embargo. Celui-ci a suivi le calendrier standard, si bien que les mainteneurs ne le considéraient pas comme trivial à trouver. Il a été publié le même jour que deux autres avis de gravité élevée et moyenne, concernant un blocage du traitement des blocs et une erreur de permissions Tor ; les trois ont été corrigés dans le même cycle de publication d'octobre 2025. Toute version assez récente pour contenir le correctif du mempool contient donc également les deux autres correctifs.

La voie lente incarne sa propre hypothèse : que les opérateurs mettent à jour dans la fenêtre d'un an, de sorte qu'au moment où le déclencheur est décrit publiquement, plus personne de vulnérable n'est à l'écoute.

Ce qu'il faut surveiller plutôt que la disponibilité

Pour une opération de minage, la vérification utile n'est pas de savoir si le nœud est vivant, mais quel est l'âge de son dernier modèle obtenu avec succès. Un processus en cours d'exécution, connecté et synchronisé peut avoir cessé de livrer du travail, et ce bug était l'un des moyens pour que cela se produise silencieusement. La version du build doit figurer dans la même vérification, car un nœud à jour sur les modèles aujourd'hui peut être un nœud hors support demain.

Les sources de modèles de secours exigent la même question. Un nœud de basculement sur la même version et avec la même politique de mempool aurait subi la même réorganisation et le même blocage ; deux processus en cours d'exécution ne constituent pas deux sources indépendantes de travail. Seul un nœud sur une version différente et corrigée aurait permis à l'opération de continuer à miner, et seul un opérateur qui l'aurait testé lors d'une réorganisation simulée l'aurait su à l'avance.