CVE-2026-117346 : un dépassement du fichier undo survient dans des conditions extrêmes
Bitcoin Core a publié le 28 octobre 2026 les détails d'une faille permettant à un mineur de corrompre les données d'undo d'autres nœuds, au point de les faire s'arrêter dans certains cas de reorg, c'est-à-dire quand la chaîne doit revenir en arrière pour adopter une autre version valide. Le problème est jugé de sévérité Low et "easily discoverable", mais son exploitation est décrite comme impraticable. Un correctif a été intégré dans Bitcoin Core 29.5,30.4,31.2 et 32.1 pour les systèmes 64 bits.
Le mécanisme de la faille
Pour déconnecter un bloc lors d'un reorg, Bitcoin Core lit dans ses données d'undo les sorties dépensées par ce bloc. Ces données sont stockées dans des fichiers rev*.dat, associés aux fichiers blk*.dat qui contiennent les blocs correspondants. Les fichiers de blocs sont limités à 128 MiB, mais les fichiers d'undo n'ont pas de limite de taille, et leurs positions internes étaient enregistrées comme des entiers sur 32 bits.
Un mineur pouvait produire des blocs valides dont les données d'undo sont bien plus volumineuses que les blocs eux-mêmes, jusqu'à faire dépasser 4 GiB à un seul fichier d'undo. À ce seuil, la position sur 32 bits déborde : de nouvelles données peuvent écraser d'anciennes données, puis le fichier est tronqué à la longueur résultante lorsque son fichier de blocs est finalisé. Si un reorg déconnecte ensuite un bloc touché, le nœud ne peut plus lire ses données d'undo et s'arrête. Le redémarrage ne règle rien, et la reprise nécessite un -reindex avec une version corrigée.
Sur Windows et les systèmes 32 bits, les appels de positionnement de fichier sont limités à 2 GiB. Le nœud échoue alors à écrire les données d'undo dès qu'un fichier d'undo dépasse 2 GiB, puis s'arrête à chaque redémarrage. Dans ce cas, il faut environ deux fois moins de données d'undo et aucun reorg.
Correctif et cas encore exposés
Le correctif consiste à stocker les positions des fichiers de blocs et d'undo sur 64 bits, et à utiliser sur Windows des appels de positionnement de fichier 64 bits. Les positions étant sérialisées sous forme d'entiers à longueur variable, le format sur disque reste inchangé.
Le document précise toutefois que les systèmes 32 bits restent concernés par la limite de 2 GiB. De même, les nœuds dont le répertoire de blocs se trouve sur un système de fichiers FAT32 restent affectés : FAT32 limite les fichiers à 4 GiB, ce qui fait échouer l'écriture des données d'undo une fois ce seuil atteint, avec un arrêt du nœud à chaque redémarrage.
La faille a été découverte via une analyse automatisée par LLM, dans le cadre du projet Loupe d'Elias Rohrer chez Spiral. Le signalement a ensuite été validé et transmis à l'équipe Bitcoin Core par Gregory Sanders. Selon la chronologie publiée, Project Loupe a signalé le problème le 2026-07-08, L0rinc l'a rapporté indépendamment le 2026-08-21, puis Andrew Dorman le 2026-10-23. Antoine Poinsot a ouvert la PR #36669 le 2026-10-26, fusionnée le même jour, avant les rétroportages sur les branches 32.x, 31.x, 30.x et 29.x.
