Le projet Bitcoin Core a publié trois avis de sécurité le mercredi 28 octobre 2026, les premiers diffusés selon la règle des bugs « faciles à découvrir » qu’blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il avait ajoutée à sa politique de sécurité six jours plus tôt. Les trois bugs ont été trouvés par Project Loupe, un scan de vulnérabilités automatisé, piloté par un grand modèle de langage et exploité par Spiral, l’unité open source de Block dédiée à Bitcoin. Les correctifs arrivent d’un coup dans quatre versions : 29.5, 30.4, 31.2 et 32.1.
La plus sérieuse des trois failles Bitcoin Core, classée Medium (gravité moyenne), permet à un pair malveillant d’épuiser la mémoire d’un nœud tournant sous Windows, macOS ou BSD jusqu’au plantage du programme. Les nœuds Linux ne sont pas concernés par celle-là. Selon l’avis publié sur bitcoincore.org, un tel pair peut « faire planter trivialement » tout nœud Windows, macOS ou BSD auquel il est connecté.
Aucun bitcoin n’est menacé. Ces bugs peuvent arrêter un nœud, pas déplacer ni voler les fonds de quiconque, et ni les avis ni les médias qui les ont relayés, dont CoinDesk et Journal du Coin, ne signalent la moindre exploitation à ce jour. Ceux qui doivent agir sont ceux qui font tourner un nœud : particuliers passionnés, entreprises et services qui gardent leur propre copie de la blockchain. Qui détient simplement des bitcoins sur une plateforme d’échange ou dans une application de portefeuille n’a rien à faire.
La règle elle-même, fusionnée le 22 octobre, est détaillée dans notre article sur l’abandon par Bitcoin Core de son embargo d’un an pour les bugs que l’IA peut trouver. En bref : quand un bug est jugé facile à trouver, par exemple en interrogeant un modèle de langage, le correctif est reporté sur toutes les versions maintenues et l’avis sort avec les versions, sans le délai d’attente habituel. C’est la première fois cette semaine que la règle est appliquée.
Données TCP urgentes : la faille Bitcoin Core qui fait planter les nœuds Windows, macOS et BSD
Le bug principal se trouve dans le code qui lit les données envoyées par les pairs. Bitcoin Core surveille ses connexions réseau avec une fonction appelée poll() sous Linux et une plus ancienne, select(), sur les autres systèmes. Seul le chemin select() était touché, ce qui explique que les machines Linux soient épargnées.
Lorsqu’un pair envoie des données plus vite que le nœud ne peut les traiter, Bitcoin Core suspend la lecture de ce pair. C’est une forme de contre-pression, et chaque pair dispose d’une limite sur la quantité de données pouvant attendre dans sa file. Le défaut : sur le chemin select(), le nœud continuait de surveiller les sockets suspendus pour détecter des « conditions exceptionnelles ». Un pair pouvait en déclencher une en envoyant des données TCP urgentes, dites aussi hors bande, une fonction rarement utilisée du protocole de transport d’internet. Le traitement de cet événement poussait le nœud à lire malgré tout, et les données ainsi lues étaient mises en file sans aucune limite.
En répétant l’astuce, la file grossit jusqu’à ce que l’ordinateur manque de mémoire. Bitcoin Core classe le bug Medium et le qualifie de « facile à découvrir ». L’avis ne donne pas de plage explicite de versions touchées et, comme les deux autres, n’indique aucun identifiant CVE.
Loupe a signalé le problème le 23 octobre. Gregory Sanders, contributeur de Bitcoin Core, l’a validé et a alerté l’équipe de sécurité du projet le jour même. Antoine Poinsot a écrit le correctif, la pull request n° 36665, ouverte, fusionnée et reportée sur les versions maintenues le 26 octobre. Les versions 31.2 et 32.1 ont suivi le 27 octobre, puis 29.5 et 30.4 le 28 octobre, avec l’avis public.
Deux bugs plus lents : une file qui gonfle chez les pairs suspendus et un fichier d’annulation qui boucle après 4 GiB
Une file qui grossit de quelques mégaoctets par heure
Le second bug Medium, décrit dans un avis distinct sur les pairs pré-BIP31 suspendus, aboutit lui aussi à un épuisement de la mémoire, mais bien plus lentement. Quand un pair lit trop lentement, Bitcoin Core le marque comme suspendu à l’envoi, mais continue d’ajouter certaines annonces à sa file sortante, surtout les annonces fréquentes de nouvelles transactions. Normalement, un pair qui ne répond pas à un ping dans les 20 minutes est déconnecté. Mais un pair qui prétend ne pas gérer BIP 31, la modification du protocole qui a ajouté un nonce aléatoire aux pings et une réponse « pong » correspondante, n’est pas coupé pour absence de réponse. Un pair malveillant peut donc se déclarer ancien, lire lentement exprès et laisser sa file enfler.
L’avis chiffre le phénomène : « La consommation de mémoire pourrait croître jusqu’à 2 Mo par heure et par pair entrant, et 5 Mo par heure et par pair sortant. » Les nœuds lancés avec l’option -blocksonly, qui ne relaient pas les transactions, sont bien moins touchés, puisque les annonces de transactions forment l’essentiel de la file.
Loupe a signalé ce bug à Sanders le 15 septembre, et celui-ci en a informé l’équipe de sécurité le jour même. Le 21 septembre, un développeur connu sous le nom de L0rinc l’a retrouvé de son côté et l’a signalé en privé à Sanders, pour apprendre qu’il était déjà connu. Le correctif, la pull request n° 36667, a été fusionné et reporté le 26 octobre.
Fichiers d’annulation, réorganisations et compteur 32 bits
Le troisième bug, classé Low (gravité faible), touche le stockage. Un nœud conserve des « données d’annulation » dans des fichiers nommés rev*.dat : les informations dont il a besoin pour défaire un bloc si la chaîne se réorganise et qu’un bloc est remplacé. Ces fichiers n’avaient aucune limite de taille, et les positions à l’intérieur étaient stockées sous forme de nombres de 32 bits.
Selon l’avis sur les fichiers d’annulation, un mineur pouvait publier des blocs valides contenant assez de données d’annulation pour pousser un seul fichier au-delà de 4 GiB. Le compteur de position repart alors à zéro et les données récentes écrasent les anciennes. Si une réorganisation déconnecte ensuite le bloc concerné, le nœud s’arrête, et le redémarrer n’y change rien : la récupération exige un -reindex avec une version corrigée. Sous Windows et sur les systèmes 32 bits, la limite est de 2 GiB, le nœud n’arrive plus à écrire de données d’annulation au-delà et s’arrête à chaque redémarrage. Cette variante demande environ moitié moins de données et aucune réorganisation.
L’avis juge l’exploitation sur les systèmes 64 bits peu réaliste. Un attaquant devrait miner plusieurs milliers de blocs de transactions non standard, soit environ un mois de production de blocs de l’ensemble du réseau. Environ 18 de ses blocs devraient ensuite tomber tout à la fin d’un fichier de blocs chez les nœuds visés, et il lui faudrait gagner une réorganisation de deux blocs. La disposition des fichiers de blocs diffère d’un nœud à l’autre, si bien qu’aucun placement ne fonctionne partout. La page évoque aussi une voie théorique vers la corruption de l’ensemble des sorties non dépensées du nœud (le UTXO set), qui exigerait un contrôle encore plus poussé des fichiers.
Loupe a signalé ce bug en premier, le 8 juillet. L0rinc l’a retrouvé de manière indépendante le 21 août, et Andrew Dorman le 23 octobre. Le correctif de Poinsot, la pull request n° 36669, a été fusionné le 26 octobre avec un report pour chaque ligne maintenue : n° 36658 pour 32.x, n° 36661 pour 31.x, n° 36664 pour 30.x et n° 36666 pour 29.x. Les positions dans les fichiers de blocs et d’annulation sont désormais stockées sur 64 bits, et les versions Windows utilisent un positionnement de fichier 64 bits. Le format sur disque ne change pas.
Du signalement à l’avis public en cinq jours
Le premier bug est le test le plus net de la nouvelle règle : il est passé d’un signalement automatique à un avis public en cinq jours. Le tableau résume les trois chronologies telles que les avis les donnent.
| Avis | Gravité | Premier signalement | Correctif fusionné et reporté | Versions corrigées | Divulgation |
|---|---|---|---|---|---|
| Données TCP urgentes, nœuds non Linux | Medium | 23 oct. 2026 (Loupe) | 26 oct. (n° 36665) | 31.2 et 32.1 le 27 oct. ; 29.5 et 30.4 le 28 oct. | 28 oct. |
| Pairs pré-BIP31 suspendus | Medium | 15 sept. 2026 (Loupe) | 26 oct. (n° 36667) | Les mêmes quatre versions | 28 oct. |
| Dépassement du fichier d’annulation | Low | 8 juil. 2026 (Loupe) | 26 oct. (n° 36669 et quatre reports) | Les mêmes quatre versions | 28 oct. |
Sous l’ancien régime, un bug Medium ou High pouvait rester sous embargo jusqu’à un an après son correctif. Le cas récent le mieux connu est CVE-2024-52911, un plantage à distance de gravité élevée dans l’interpréteur de scripts : corrigé dans la version 29.0 en avril 2025, il n’a été rendu public qu’en mai 2026. En octobre 2025, quatre avis de gravité faible corrigés dans la 30.0 ont été publiés avec des numéros CVE selon ce même processus plus ancien. L’argument de Poinsot en faveur du changement, dans son e-mail à la liste bitcoin-dev, était sans détour : « La période d’embargo n’apporte pas grand-chose, mais elle retarde la disponibilité d’une version corrigée. »
Les deux signalements plus anciens soulèvent une question à laquelle les avis ne répondent pas. Loupe a repéré le bug du fichier d’annulation en juillet et la croissance lente de la mémoire en septembre, pourtant les deux correctifs sont arrivés le même jour que celui du bug de cinq jours, le 26 octobre. Les pages donnent les dates, pas la raison de cet écart.
Qui a trouvé les bugs : Project Loupe de Spiral, une IA qui traque les failles de Bitcoin
Spiral a lancé Loupe le 12 mai 2026, présenté par Elias Rohrer, Jordan Mecom et Thomas Kilbride. L’outil est proposé gratuitement, en « scanning-as-a-service », aux projets Bitcoin open source. Ses premiers essais ont couvert Bitcoin Core, BDK, LDK, rust-bitcoin, Cashu, Blockstream Jade, bitcoinj et la Stratum Reference Implementation. Les projets apportent leur propre accès à un modèle, et Spiral et Block financent les scans qu’ils lancent eux-mêmes. Spiral décrit l’outil comme indépendant du modèle et ne précise pas quel modèle d’IA ni quel fournisseur il utilise.
Selon Spiral, Loupe « ne signalera que des vulnérabilités appuyées par un cas de test démontrable ». Dans ce lot, un humain a vérifié chaque découverte avant qu’elle n’atteigne l’équipe de sécurité : Sanders a validé les trois, d’après les avis et la couverture de CoinDesk et de Journal du Coin. Les crédits citent Rohrer pour Loupe. L’objectif à long terme annoncé par Spiral est de confier le scan aux mainteneurs de chaque projet.
Les redécouvertes indépendantes comptent autant que le scan lui-même. Deux des trois bugs ont été retrouvés par des humains, L0rinc à deux reprises et Dorman une fois, ce qui correspond au cas pour lequel l’étiquette « facile à découvrir » a été écrite : des bugs que d’autres personnes, ou d’autres scans, risquent de trouver seuls pendant qu’un embargo court.
Ces avis s’inscrivent dans une série plus large de découvertes de bugs assistées par IA dans les logiciels Bitcoin depuis août. Ils n’ont aucun rapport avec les deux failles de bitcoinjs-lib signalées cette semaine, qui concernent bitcoinjs-lib, une bibliothèque JavaScript distincte de Bitcoin Core ; voir notre article sur les bugs de frais de bitcoinjs-lib.
Mise à jour de Bitcoin Core 32.1 : que doivent faire les nœuds Windows, macOS et BSD
Les consignes des avis et de l’annonce de la version 32.1 tiennent en peu de lignes. Elles valent pour quiconque fait tourner Bitcoin Core, avec une urgence maximale sur les machines non Linux.
- Les nœuds Windows, macOS et BSD doivent passer à la version corrigée de leur branche : 29.5, 30.4, 31.2 ou 32.1.
- Les nœuds Linux ne sont pas exposés au bug des données TCP urgentes, mais les deux autres avis valent pour toutes les plateformes : la mise à jour reste donc le remède.
- Pour mettre à jour, arrêter complètement l’ancienne version, puis installer la nouvelle par-dessus, comme le décrit l’annonce de la 32.1.
- Un nœud déjà arrêté par le bug du fichier d’annulation ne repartira pas d’un simple redémarrage : il faut le lancer avec
-reindexsur une version corrigée. - Ne télécharger que sur bitcoincore.org et vérifier les signatures des versions avant l’installation.
Quelle version choisir, et pourquoi la 32.0 est ignorée
| Votre ligne de version | Version corrigée | Publication |
|---|---|---|
| 32.x | 32.1 | 27 octobre 2026 |
| 31.x | 31.2 | 27 octobre 2026 |
| 30.x | 30.4 | 28 octobre 2026 |
| 29.x | 29.5 | 28 octobre 2026 |
| 28.x ou antérieure | Aucune | Pas de correctif : passer à une ligne maintenue |
La version 32.0 a été étiquetée mais, selon les termes de l’annonce de la 32.1 publiée par fanquake sur le forum des développeurs, elle n’a « jamais été pleinement annoncée ni publiée » à cause de problèmes de dernière minute ; la 32.1 est donc la version à utiliser pour cette ligne. Elle corrige aussi un problème distinct sur les portefeuilles : hors Windows, un appelant RPC authentifié autorisé à créer des portefeuilles pouvait exécuter des commandes lorsque l’option -walletnotify était activée ; les noms de portefeuille sont désormais traités littéralement. L’annonce indique comme plateformes minimales le noyau Linux 3.17, macOS 14 et Windows 10 (version 1903), et précise que la prochaine version majeure prévoit d’abandonner les builds réalisés avec le compilateur MSVC de Microsoft.
Les opérateurs en 29.x ont reçu une version corrigée cette semaine. Pendant combien de temps cette ligne continuera de recevoir des correctifs est une autre question : l’annonce de la 32.1 et la page de cycle de vie du projet ne la formulent pas de la même façon, et cet article ne se prononce pas.
Encore exposés après le correctif : machines 32 bits, disques FAT32 et nœuds en fin de vie
La mise à jour ne referme pas tout. Le bug du fichier d’annulation reste exploitable, avec une gravité faible, sur les systèmes 32 bits et sur les nœuds qui stockent leurs blocs sur un disque FAT32, un système de fichiers qui plafonne chaque fichier à 4 GiB. L’avis cite les deux cas. Pour le bug de mémoire lent, -blocksonly réduit l’exposition.
La brèche la plus large vient des vieux logiciels. Seules les lignes maintenues reçoivent des correctifs reportés, et une grande part du réseau public n’en fait pas partie. Dans un recensement de l’Institut de technologie de Karlsruhe (KIT) du 18 octobre, portant sur 9 691 pairs joignables en IPv4 et IPv6, Coindaro a dénombré 8 418 agents utilisateurs Bitcoin Core simples, répartis comme suit (détail dans notre décompte des nœuds Bitcoin Core sur des versions en fin de vie).
| Ligne de version dans le recensement KIT (18 oct.) | Nœuds | Part des 8 418 | Correctif disponible cette semaine |
|---|---|---|---|
| 28.x ou antérieure | 3 742 | 44,5 % | Non |
| 29.x | 640 | 7,6 % | 29.5 |
| 30.x | 721 | 8,6 % | 30.4 |
| 31.x | 3 278 | 38,9 % | 31.2 |
| Versions candidates de la 32 | 37 | 0,4 % | 32.1 |
Pour les 3 742 nœuds en 28.x ou antérieure, aucun correctif n’existe. Sous Windows, macOS ou BSD, la seule protection contre le bug TCP est de passer à une version maintenue, ou à un hôte Linux. L’échantillon exclut les nœuds uniquement sur Tor, ceux qui n’acceptent pas de connexions entrantes et les infrastructures privées d’entreprise, et les versions sont déclarées par les nœuds eux-mêmes.
Deux chiffres sont inconnus, et Coindaro ne les estime pas. Aucune source ne donne la part des nœuds tournant sous Windows, macOS ou BSD : les outils de suivi enregistrent des agents utilisateurs, pas des systèmes d’exploitation. Et la part déjà passée aux versions corrigées est proche de zéro par définition, puisqu’elles ont un ou deux jours. L’instantané de btcnodes.io du 29 octobre comptait 18 092 nœuds validés, mais nous n’avons pas pu en extraire de répartition par version.
Pourquoi le plantage d’un nœud n’est pas un vol
Un nœud Bitcoin vérifie chaque bloc et chaque transaction au regard des règles et les relaie à ses pairs. S’il plante, il cesse de le faire jusqu’à ce que quelqu’un le relance, comme l’a rappelé Journal du Coin ; les pièces inscrites sur la blockchain ne bougent pas. Le risque pour une entreprise est l’interruption de service : un prestataire de paiement ou une plateforme d’échange dont le nœud tombe ne voit plus les nouvelles transactions tant qu’il n’est pas revenu. Notre guide sur les endroits où se produisent vraiment les piratages crypto explique pourquoi les attaques contre les logiciels autour d’une blockchain diffèrent des attaques contre la chaîne elle-même.
Les niveaux de gravité suivent l’échelle propre à Bitcoin Core. Le bug TCP est classé Medium alors que le plantage est facile à provoquer ; l’avis n’explique pas le raisonnement derrière cette note, et aucune des trois pages ne relie les bugs à une perte de fonds.
Prochaine échéance : trois autres avis attendus vers le 11 novembre
Le flux n’est pas terminé. L’annonce de la 32.1 indique que la divulgation d’autres correctifs suivra la politique du projet, et que trois problèmes de gravité Medium ou High corrigés dans la version 30.0 seront divulgués « dans deux semaines », ce que CoinDesk lit comme autour du 11 novembre. Ceux-là relèvent des règles d’embargo ordinaires, pas de la voie rapide.
Plusieurs points restent ouverts : les identifiants CVE des trois avis de cette semaine (aucun n’apparaît sur les pages pour l’instant, alors que des avis plus anciens du même index en portent un), une plage explicite de versions touchées, et la part des nœuds qui feront la mise à jour.