Un scan par IA trouve trois bugs dans Bitcoin Core / des nœuds Windows et Mac plantent à distance

Points clés

  • Un scan LLM trouve trois bugs dans Bitcoin Core, corrigés dans les versions 29.5, 30.4, 31.2 et 32.1
  • Un pair malveillant peut planter tout nœud Windows, macOS ou BSD via des données urgentes TCP
  • Divulgation sans embargo : les bugs de gravité moyenne restent d'ordinaire privés environ un an
Alex Numeris
Alex Numeris•
Partager

Bitcoin Core a publié le 28 octobre trois avis de sécurité sur des bugs détectés par un scan automatisé de modèle de langage, tous corrigés dans les versions 29.5, 30.4, 31.2 et 32.1. Deux d'entre eux permettent à un pair malveillant de remplir la mémoire d'un nœud jusqu'à son arrêt. Le troisième permet de faire planter très facilement n'importe quel nœud qui ne tourne pas sous Linux.

Bug 1 : données urgentes TCP sur Windows, macOS et BSD

Hors Linux, Bitcoin Core surveille les sockets avec un backend fondé sur select(). Selon l'avis de Bitcoin Core, ce backend guettait les conditions exceptionnelles même lorsque la lecture des données d'un pair était suspendue.

Un pair pouvait envoyer des données urgentes TCP (hors bande) pour contourner le mécanisme de contre-pression et mettre en file d'attente une quantité illimitée de données. En pratique, un pair malveillant peut faire planter sans effort tout nœud Windows, macOS ou BSD auquel il est connecté.

  • Gravité : moyenne, classée comme facilement découvrable
  • Les nœuds Linux ne sont pas touchés, car ils utilisent poll()
  • Identifié le 23 octobre, PR #36665 ouverte par Antoine Poinsot le 26 octobre

Bug 2 : croissance lente de la mémoire via des pairs pré-BIP31

Bitcoin Core met en file d'attente les annonces, surtout des INV de transactions, pour tous les pairs, y compris ceux dont la lecture est suspendue. Les pairs qui ne répondent pas à un ping avec nonce sous 20 minutes sont déconnectés, mais cette règle ne s'applique pas aux pairs qui ne gèrent pas BIP 31, indique le deuxième avis.

Un attaquant peut faire semblant de ne pas gérer BIP 31 et retarder stratégiquement la lecture des messages, ce qui laisse la file grossir sans limite.

  • Croissance de la mémoire : jusqu'à 2 Mo par heure et par pair entrant, et 5 Mo par heure et par pair sortant
  • Les nœuds lancés avec -blocksonly sont bien moins touchés
  • Gravité moyenne ; trouvé par Loupe le 15 septembre, puis redécouvert indépendamment par L0rinc le 21 septembre

Bug 3 : dépassement du fichier d'annulation

Un mineur peut produire des blocs valides dont les données d'annulation (undo) sont bien plus volumineuses que les blocs eux-mêmes, au point de dépasser 4 Gio dans un seul fichier rev*.dat. Les positions étaient stockées sous forme d'entiers 32 bits : les nouvelles données d'annulation écrasent donc les anciennes. Si une réorganisation touche ensuite un bloc concerné, le nœud ne peut pas le lire et s'arrête, explique le troisième avis. Un redémarrage 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 Gio et aucune réorganisation n'est nécessaire : le nœud n'arrive pas à écrire les données d'annulation et s'arrête à chaque redémarrage.

  • Gravité : faible ; l'exploiter sur des systèmes 64 bits n'est pas réaliste
  • Un attaquant devrait miner plusieurs milliers de blocs, soit environ un mois de production de l'ensemble du réseau
  • Les systèmes 32 bits et les nœuds qui stockent les blocs sur FAT32 restent touchés après le correctif
  • Signalé par Loupe le 8 juillet, puis indépendamment par L0rinc (21 août) et Andrew Dorman (23 octobre)

Qui les a trouvés et pourquoi ils sont déjà publics

Les trois bugs ont été découverts par un scan automatisé par LLM dans le cadre du Project Loupe, mené par Elias Rohrer chez Spiral. Gregory Sanders a validé les résultats et les a transmis à l'équipe de sécurité de Bitcoin Core.

La politique de Bitcoin Core définit les vulnérabilités facilement découvrables comme celles trouvées avec un effort minimal, par exemple avec un simple prompt LLM. Pour celles-ci, l'équipe publie une version corrective pour chaque version majeure maintenue, ainsi qu'un avis, sans la période d'embargo habituelle.

Dans le calendrier normal, les bugs de gravité moyenne et élevée sont divulgués deux semaines après la fin de vie de la dernière version concernée, soit environ un an après la première version majeure contenant le correctif.

Versions corrigées

Date de publication

31.2 et 32.1

27 octobre 2026

29.5 et 30.4

28 octobre 2026

Partager l'article