Bitcoin Core corrige une faille des fichiers d'annulation sur 64 bits

Un mineur peut corrompre les données d'annulation d'autres nœuds

L'équipe de Bitcoin Core a rendu publique, dans une divulgation de sécurité datée du 28 octobre 2026, un bogue qui permet à un mineur de corrompre les données d'annulation d'autres nœuds. Selon Bitcoin Core, le logiciel lit ces données, rangées dans les fichiers rev*.dat, pour retrouver les sorties dépensées par un bloc lorsqu'il doit le retirer de la chaîne pendant une réorganisation.

D'après la divulgation de Bitcoin Core, un nœud touché s'arrête si une réorganisation portant précisément sur les bons blocs survient ensuite. Sous Windows et sur les systèmes 32 bits, l'arrêt se produit dès la connexion des blocs concernés, sans réorganisation.

Bitcoin Core classe le problème en gravité faible et le juge facile à découvrir. Le correctif pour les systèmes 64 bits est livré dans les versions 31.2 et 32.1, publiées le 27 octobre 2026, puis dans les versions 29.5 et 30.4, sorties le jour de la divulgation.

Les positions 32 bits des fichiers d'annulation débordent à 4 GiB

Selon Bitcoin Core, chaque fichier rev*.dat va de pair avec un fichier blk*.dat qui contient les blocs correspondants. Les positions internes des fichiers d'annulation étaient codées en entiers 32 bits. Un mineur peut produire des blocs valides dont les données d'annulation sont bien plus volumineuses que les blocs eux-mêmes.

Les seuils techniques décrits par Bitcoin Core dans sa divulgation d'octobre 2026 sont les suivants :

Donnée	Valeur	Effet décrit
Plafond d'un fichier de blocs	128 MiB	Aucune limite équivalente pour les fichiers d'annulation
Débordement d'une position 32 bits	4 GiB	Les nouvelles données d'annulation peuvent écraser les anciennes
Limite des appels de positionnement (Windows, 32 bits)	2 GiB	Échec d'écriture des données d'annulation au-delà
Taille maximale d'un fichier sur FAT32	4 GiB	Échec d'écriture une fois ce seuil atteint

Le correctif décrit par Bitcoin Core code désormais les positions des fichiers de blocs et d'annulation sur 64 bits et emploie, sous Windows, des appels de positionnement 64 bits. Les systèmes 32 bits et les nœuds dont le répertoire des blocs est sur FAT32 restent exposés.

Bitcoin Core juge l'attaque impraticable sur 64 bits

Selon la divulgation d'octobre 2026, exploiter la faille sur un système 64 bits supposerait de miner plusieurs milliers de blocs de transactions non standard, soit environ un mois de la production de blocs de tout le réseau. L'attaquant devrait ensuite placer environ 18 de ses blocs tout à la fin d'un fichier de blocs des nœuds visés, puis gagner une réorganisation de 2 blocs.

Bitcoin Core souligne que l'organisation des fichiers de blocs diffère d'un nœud à l'autre : aucun placement ne vaut pour tous les nœuds, et l'échec de la réorganisation rend la préparation inutile.

En théorie, un attaquant contrôlant encore plus finement les fichiers de chaque nœud pourrait lui faire restaurer de mauvaises pièces lors d'une réorganisation et corrompre son ensemble UTXO (les sorties de transaction non dépensées), indique Bitcoin Core.

Un scan automatisé du Project Loupe a repéré la faille en juillet

Selon la divulgation de Bitcoin Core, la faille a été mise au jour par un scan automatisé fondé sur un grand modèle de langage (LLM), conduit dans le cadre du Project Loupe d'Elias Rohrer chez Spiral. Gregory Sanders a validé ce résultat avant de le transmettre à l'équipe de Bitcoin Core.

Le calendrier publié par Bitcoin Core mentionne un premier signalement de Project Loupe le 8 juillet 2026, puis des signalements indépendants de L0rinc le 21 août 2026 et d'Andrew Dorman le 23 octobre 2026. Antoine Poinsot a proposé le correctif le 26 octobre 2026 ; intégré le même jour à la branche principale, il a aussi été reporté sur les branches 29.x à 32.x.

La divulgation de Bitcoin Core ne précise ni si ni quand un correctif est prévu pour les systèmes 32 bits et les nœuds sur FAT32.

Questions fréquentes

Quelle faille des fichiers d'annulation Bitcoin Core a-t-il divulguée ?

Selon la divulgation de sécurité de Bitcoin Core du 28 octobre 2026, il s'agit d'un bogue qui permet à un mineur de corrompre les données d'annulation d'autres nœuds. Ces données sont stockées dans les fichiers rev*.dat et servent à retirer un bloc de la chaîne lors d'une réorganisation. Un nœud touché s'arrête si une réorganisation portant précisément sur les bons blocs survient ensuite. Sous Windows et sur les systèmes 32 bits, l'arrêt survient dès la connexion des blocs concernés. Bitcoin Core classe le problème en gravité faible (« Low severity »), le juge facile à découvrir et estime son exploitation impraticable.

Quelles versions de Bitcoin Core corrigent la faille des fichiers d'annulation ?

D'après la divulgation de Bitcoin Core du 28 octobre 2026, le correctif pour les systèmes 64 bits figure dans les versions 29.5, 30.4, 31.2 et 32.1. Les versions 31.2 et 32.1 ont été publiées le 27 octobre 2026, les versions 29.5 et 30.4 le 28 octobre 2026, jour de la divulgation publique. Le correctif consiste à stocker les positions des fichiers de blocs et d'annulation sur 64 bits et à utiliser des appels de positionnement 64 bits sous Windows. Le format sur disque reste inchangé, car les positions sont sérialisées en entiers de longueur variable.

Les systèmes 32 bits et FAT32 sont-ils encore touchés par la faille de Bitcoin Core ?

Oui, selon la divulgation de Bitcoin Core du 28 octobre 2026, les systèmes 32 bits et les nœuds dont le répertoire des blocs est sur FAT32 restent affectés. Sur 32 bits, les nouvelles versions utilisent toujours des appels de positionnement limités à 2 GiB. Sur FAT32, les fichiers sont limités à 4 GiB : l'écriture des données d'annulation échoue une fois cette taille atteinte, et le nœud s'arrête à chaque redémarrage. Dans ce cas, il faut autant de données d'annulation que sur les autres systèmes 64 bits, mais aucune réorganisation. La divulgation ne précise ni si ni quand un correctif est prévu pour ces cas.

Pourquoi Bitcoin Core juge-t-il la faille des fichiers d'annulation impraticable à exploiter sur 64 bits ?

Selon la divulgation de Bitcoin Core du 28 octobre 2026, les transactions nécessaires sont non standard et l'attaquant devrait miner plusieurs milliers de blocs, soit environ un mois de la production de blocs de tout le réseau. Il devrait ensuite placer environ 18 de ses blocs à la toute fin d'un fichier de blocs des nœuds visés, puis gagner une réorganisation de 2 blocs. Bitcoin Core souligne que l'organisation des fichiers diffère d'un nœud à l'autre : aucun placement ne vaut pour tous, et si la réorganisation échoue, la préparation est perdue.

Comment la faille des fichiers d'annulation de Bitcoin Core a-t-elle été découverte ?

D'après la divulgation de Bitcoin Core du 28 octobre 2026, la faille a été trouvée par un scan automatisé fondé sur un grand modèle de langage, dans le cadre du Project Loupe d'Elias Rohrer chez Spiral. Gregory Sanders a validé le résultat et l'a transmis à l'équipe de Bitcoin Core. Le calendrier indique un signalement de Project Loupe le 8 juillet 2026, puis des signalements indépendants de L0rinc le 21 août 2026 et d'Andrew Dorman le 23 octobre 2026. Antoine Poinsot a ouvert la PR #36669 avec le correctif le 26 octobre 2026, fusionnée le même jour dans la branche principale.