Bitcoin Core a détaillé mardi 10 novembre trois vulnérabilités corrigées en 2025. L'une d'elles est jugée de gravité élevée, car elle pouvait empêcher un nœud de minage de produire des blocs après une réorganisation de la chaîne. La divulgation intervient deux semaines après que la dernière version concernée, la 29.x, a atteint sa fin de vie, le 27 octobre 2026.
Les trois vulnérabilités
Les avis ont été ajoutés au site officiel via une pull request GitHub ouverte par darosior et fusionnée le même jour par fanquake. Selon la description de la PR, les bugs avaient été préannoncés deux semaines plus tôt, avec la sortie de la version 32.1.
- CVE-2025-62859 - le traitement des blocs pouvait être bloqué par un pair annonçant un compact block avec un témoin malléable
- CVE-2025-62860 - des connexions Tor entrantes recevaient à tort les autorisations -whitelist, ce qui levait les protections contre les attaques DoS et pour la confidentialité
- CVE-2025-62861 - la création de modèles de blocs était interrompue par l'éviction de transactions TRUC (v3) sœurs lors d'une réorg
La CVE-2025-62861 est classée en gravité élevée dans l'avis publié.
Le fonctionnement du bug de gravité élevée
Les transactions TRUC (version 3, définies dans le BIP 431) ne peuvent avoir dans le mempool qu'un seul ancêtre non confirmé et un seul descendant non confirmé. Lorsqu'une nouvelle transaction donnerait à un parent TRUC un second enfant non confirmé, la logique d'éviction des transactions sœurs, introduite dans la v28.0, évince l'enfant existant selon les règles du replace-by-fee si la nouvelle transaction paie assez.
Il s'agit de règles de politique du mempool, et non de règles de consensus : un bloc valide peut donc contenir n'importe quelle topologie. Lors d'une réorg, les transactions des blocs déconnectés sont réintégrées au mempool avec bypass_limits=true, mais le contrôle TRUC n'était pas conditionné à cet indicateur et s'exécutait quand même.
Résultat : une transaction restaurée pouvait être évincée alors que ses descendantes restaient dans le mempool, en dépensant des sorties qui n'existaient plus. Le modèle de bloc assemblé par un mineur échouait alors au contrôle de validité, et le nœud ne pouvait plus produire de blocs tant qu'un redémarrage ne rechargeait pas le mempool dans un état cohérent.
Qui était concerné et quand le correctif est arrivé
Le correctif figure dans la PR #33504, ouverte par Greg Sanders, qui conditionne les contrôles TRUC à bypass_limits. Le bug a été découvert et divulgué de manière responsable par Niklas Goegge.
Date | Événement |
|---|---|
26 sept. 2025 | Niklas Goegge signale le bug à la liste de diffusion dédiée à la sécurité |
2 oct. 2025 | La PR #33504 est fusionnée dans master |
10 oct. 2025 | Sortie de Bitcoin Core 30.0 avec le correctif |
14 oct. 2025 | Sortie de Bitcoin Core 29.2 avec le correctif |
17 oct. 2025 | Sortie de Bitcoin Core 28.3 avec le correctif |
27 oct. 2026 | La dernière version vulnérable (29.x) atteint sa fin de vie |
10 nov. 2026 | Divulgation publique |
Politique de divulgation
Selon la politique de sécurité de Bitcoin Core, les vulnérabilités de gravité moyenne et élevée sont divulguées deux semaines après la fin de vie de la dernière version concernée, soit environ un an après la première sortie de la version majeure contenant le correctif.
Une préannonce est publiée deux semaines avant, en même temps qu'une nouvelle version majeure, et indique le nombre de vulnérabilités corrigées ainsi que leur niveau de gravité. Si vous faites encore tourner un nœud en 28.0-28.2 ou 29.0-29.1, il est concerné ; les dernières versions de maintenance, 29.5 et 30.4, sont sorties le 28 octobre 2026.