Un mineur pouvait faire dépasser 4 Gio à un fichier d’annulation (undo) de Bitcoin Core : ses positions sur 32 bits repartaient alors de zéro et corrompaient les données, de sorte que les nœuds s’arrêtent si une réorganisation bien placée s’ensuit ; sous Windows et sur les systèmes 32 bits, l’échec survient dès 2 Gio, sans réorganisation. De faible gravité, CVE-2026-117346 exigerait environ un mois de la totalité des blocs du réseau. Les versions 32.1, 31.2, 30.4 et 29.5 corrigent les systèmes 64 bits ; les nœuds 32 bits et le stockage des blocs sur FAT32 restent concernés.
Plus d’écart entre poll() et select() pour la surveillance des exceptions de socket dans Bitcoin Core 29.5 (#36665), et les pairs en pause d’envoi se voient imposer un délai d’expiration (#36667). Les positions des flatfiles passent en entiers 64 bits (#36669), les nœuds présument v2transport pour les adresses issues des seeds, et un seed DNS disparaît.
En faisant mine de ne pas gérer les pings de BIP 31, un pair malveillant pouvait esquiver la déconnexion au bout de 20 minutes et lire au ralenti : la file d’envoi du nœud gonflait alors de 2 Mo par heure au maximum pour chaque pair entrant, et de 5 Mo pour chaque pair sortant. La faille CVE-2026-117349, de gravité moyenne, est corrigée par #36667 dans Bitcoin Core 32.1, 31.2, 30.4 et 29.5 ; les nœuds en -blocksonly étaient bien moins exposés.
Sous Windows, macOS et BSD, un pair connecté pouvait faire tomber un nœud en lui envoyant des données urgentes TCP : elles échappaient aux lectures en pause du backend select() et la mémoire s’accumulait sans limite (CVE-2026-117350). Les nœuds Linux, qui utilisent poll(), ne sont pas concernés. Bitcoin Core 32.1, 31.2, 30.4 et 29.5 corrigent ce bug de gravité moyenne, repéré par un LLM lors d’une analyse menée dans le cadre de Project Loupe.
Bitcoin Core 30.4 cesse de considérer les bits 5 à 28 de BIP 9 comme des signaux de soft fork, conformément à BIP 323 : les blocs qui les activent ne déclenchent plus d’alertes de déploiement inconnu (#34779). Côté réseau, un délai d’expiration s’applique désormais aux pairs en pause d’envoi (#36667), et les positions des flatfiles passent en entiers 64 bits (#36669).
La diffusion privée a désormais un plafond dans Bitcoin Core 31.2 : la file des transactions que le réseau n’a pas encore renvoyées s’arrête à 10 000 entrées et refuse tout nouvel envoi une fois pleine, à charge pour l’appelant de la vider avec abortprivatebroadcast (#35406). Conformément à BIP 323, les bits de version 5 à 28 ne comptent plus comme signaux de soft fork.
Plus de risque de voir l’adresse IP de l’expéditeur exposée par la diffusion privée dans Bitcoin Core 32.1 : la fuite pouvait survenir quand une connexion v2 ratée était retentée en v1 directement, et non via Tor. La valeur par défaut de -maxconnections passe de 125 à 200, et le débit du relais sortant des transactions est limité par une file globale plutôt que pair par pair.
Les lectures et écritures disque intensives en fonctionnement normal venaient d’un bug corrigé dans Bitcoin Core 29.4 : la base chainstate réécrivait sans cesse de grandes parties d’elle-même. Le correctif désactive la seek compaction de LevelDB et compacte le chainstate à intervalles réguliers (#35465).
Finies les réécritures incessantes du chainstate sur le disque avec Bitcoin Core 30.3, qui répare aussi un plantage de feebumper lorsque le montant combiné du bump fee n’est pas disponible (#34870) et un bug de sélection des pièces qui calculait un montant comme un booléen (#34888). Côté PSBT, les clés publiques MuSig2 sont désormais validées à la désérialisation des pubnonces et des signatures partielles (#34219).
Fuite d’adresse IP colmatée pour -privatebroadcast dans Bitcoin Core 31.1 : certaines connexions sortaient sur le clearnet au lieu de passer par le réseau de confidentialité activé. La mise à jour met aussi fin aux réécritures du chainstate à l’origine d’une activité disque excessive et rejette les listes de clés publiques vides dans l’agrégation de clés MuSig2 (#35316).
Un échec de la poignée de main v2 peut trahir l’adresse IP de l’expéditeur dans Bitcoin Core 31.0 : avec -privatebroadcast, la nouvelle tentative en v1 contourne le proxy Tor et se connecte directement au pair. Déclencheur le plus probable : un pair malveillant qui coupe volontairement la poignée de main. En attendant 31.1, on peut désactiver la fonction, régler -v2transport=0 ou faire passer le trafic sortant IPv4/IPv6 par Tor.
Les versions de Bitcoin Core postérieures à 0.14.0 et antérieures à 29.0 pouvaient lire de la mémoire libérée en validant un bloc invalide spécialement conçu, ce qui faisait planter le nœud. CVE-2024-52911 est jugée de gravité élevée, même si l’attaquant doit dépenser une preuve de travail valide en tête de chaîne, et une exécution de code à distance paraît peu probable. Cory Fields l’a signalée ; 29.0 contient le correctif.
Le cluster mempool remplace l’ancienne conception dans Bitcoin Core 31.0 : les limites d’ancêtres et de descendants cèdent la place à des clusters plafonnés à 64 transactions et 101 ko, et le CPFP carveout disparaît. Le -dbcache par défaut monte à 1024 Mio sur les machines dotées d’au moins 4096 Mio de RAM, et une nouvelle option -privatebroadcast réserve les diffusions de sendrawtransaction à Tor ou I2P.
Deux échecs liés aux portefeuilles sans nom sont corrigés dans Bitcoin Core 28.4 : la migration des portefeuilles legacy (#34156) et createfromdump, qui effaçait le répertoire wallets en cas d’erreur (#34215). Un seed DNS est par ailleurs retiré de chainparams (#33723).
Bitcoin Core 29.3 ne sanctionne plus les pairs qui envoient des transactions invalides au regard du consensus (#33050). La validation gagne un cache de midstate de sighash par entrée pour les scripts legacy, P2SH et segwit v0 (#32473) et détecte le witness stripping sans rejouer les vérifications de Script (#33105), tandis que addPackageTxs, côté mineur, perd un dépassement d’entier non signé (#33475).
Plus d’échec de migration sur les portefeuilles legacy sans nom avec Bitcoin Core 30.2 (#34156), et createfromdump n’efface plus le répertoire wallets lorsqu’il échoue sur l’un d’eux (#34215). Un Ctrl-C ne bloque plus pendant les appels d’attente IPC (#33511).
Dans de rares cas, une migration ratée de wallet.dat sous Bitcoin Core 30.0 ou 30.1 peut effacer tous les fichiers du répertoire du portefeuille et mettre les fonds en danger. Les développeurs ont retiré ces binaires et demandent de ne pas migrer via l’interface graphique ou en RPC avant 30.2. Le bug suppose un wallet.dat par défaut, sans nom, dont la migration ou le chargement échoue ; les autres utilisateurs ne sont pas touchés.
Les portefeuilles de Bitcoin Core 30.1 ne prennent plus en compte les pièces TRUC non confirmées qui ont des ancêtres (#33528). Côté IPC, les options n’exigent plus l’argument -m (#33229), la journalisation des messages pèse moins lourd (#33517) et les appels waitNext en cours peuvent être annulés (#33676).
Des transactions non standard spécialement conçues pouvaient occuper un nœud Bitcoin Core quelques secondes chacune sans que l’expéditeur soit déconnecté, de quoi retarder la propagation des blocs. Signalée par Antoine Poinsot et de faible gravité, CVE-2025-46598 a été atténuée dans v30.0 grâce à une réduction du temps de validation dans le pire des cas.
Un bloc de plus de 1 Go pouvait déborder un contrôle de taille sur les nœuds Bitcoin Core 32 bits et les faire planter à l’écriture sur le disque, mais seulement sous forme de compact block et contre une victime configurée avec un -maxmempool supérieur à 3 Go contenant 1 Go de transactions. Découverte par Pieter Wuille, CVE-2025-46597 est de faible gravité ; le plafonnement de -maxmempool sur les systèmes 32 bits l’a refermée dans 29.1 et 30.0.
