Mis à jour le 31 octobre 2026.
Bitcoin Core a publié le 28 octobre trois avis de sécurité concernant des vulnérabilités susceptibles de perturber les nœuds. Les correctifs figurent dans les versions 29.5, 30.4, 31.2 et 32.1, mais les plateformes concernées diffèrent et des limites subsistent pour les systèmes 32 bits et le stockage FAT32.
Le cas le plus immédiat concerne Windows, macOS et BSD : un pair malveillant connecté peut épuiser la mémoire avec des données TCP urgentes. Linux n’est pas touché par cette faille précise. Cela ne l’exclut pas des deux autres avis et ne signifie pas qu’une consommation élevée de RAM prouve une attaque.
Bitcoin Core : les versions contenant les correctifs
Les trois avis désignent les mêmes quatre versions corrigées. Le projet annonce la disponibilité de Bitcoin Core 32.1 sur son site officiel. Le choix d’une mise à jour nécessite aussi la lecture des notes de version et la vérification de sa compatibilité avec l’installation réelle.
Cette liste ne recommande pas de conserver indéfiniment une ancienne branche. Elle indique où les correctifs ont été distribués, pas combien de temps chaque branche continuera à être maintenue. L’article décrit les informations disponibles au 31 octobre ; tout lancement ultérieur doit être examiné dans la documentation du projet.
| Avis | Problème | Distinction importante |
|---|---|---|
| CVE-2026-117350 | Mémoire sans limite via des données TCP urgentes | Chemin non Linux ; gravité moyenne |
| CVE-2026-117349 | Accumulation lente d’annonces vers des pairs pré-BIP31 | Distinct de la faille TCP ; gravité moyenne |
| CVE-2026-117346 | Dépassement dans les fichiers undo | Conditions extrêmes ; gravité faible, limites 32 bits/FAT32 persistantes |
La faille TCP ne touche pas Linux
L’avis TCP concerne le chemin de surveillance des sockets fondé sur select(), différent de celui utilisé sous Linux. Une condition exceptionnelle pouvait déclencher une nouvelle lecture alors que les lectures ordinaires avaient été suspendues pour limiter la file de traitement.
La consommation de mémoire pouvait alors augmenter jusqu’à l’arrêt du nœud. Le projet classe cette vulnérabilité comme moyenne et décrit un pair connecté, non un accès aux clés privées. La plateforme déterminante est celle du nœud, pas celle du téléphone utilisé par son propriétaire pour consulter son solde.
Une autre faille fait grossir lentement la file d’envoi
L’avis sur les pairs pré-BIP31 porte sur les annonces conservées pour un interlocuteur qui lit trop lentement. Un pair pouvait déclarer ne pas prendre en charge les pings avec nonce de BIP31 et éviter la déconnexion normalement associée à l’absence de réponse, tandis que des messages continuaient à s’accumuler.
L’avis indique jusqu’à 2 MB par heure et par pair entrant, et 5 MB par heure et par pair sortant. Ce sont des valeurs propres au scénario décrit, pas une prévision pour chaque nœud. Le mode -blocksonly réduit fortement l’exposition, car les annonces de transactions constituent l’essentiel de la file, sans devenir pour autant un substitut au correctif.
Fichiers undo : les limites de 32 bits et FAT32
Les données undo permettent de déconnecter des blocs lors d’une réorganisation de la chaîne. L’avis sur le dépassement décrit des conditions extrêmes dans lesquelles un volume inhabituel de données peut corrompre les informations nécessaires et arrêter le nœud. Le projet classe la gravité comme faible et juge l’exploitation impraticable sur les systèmes 64 bits dans les conditions exposées.
Le correctif utilise des positions sur 64 bits, mais l’avis maintient expressément les limites pour les systèmes 32 bits et les répertoires de blocs sur FAT32. Installer une version corrigée ne rend donc pas inutiles les vérifications de l’architecture et du système de fichiers. Les appels de positionnement sous Windows ont également été corrigés ; ce point reste distinct de l’exception des systèmes 32 bits.
Un arrêt du nœud ne prouve pas un vol de bitcoins
Ces avis n’annoncent pas l’extraction automatique de phrases de récupération ou de clés privées. Le fonctionnement d’un nœud et la conservation des clés sont deux responsabilités distinctes, comme l’explique notre article sur les wallets custodial et non custodial. Une interruption compte, mais elle ne démontre pas à elle seule qu’un solde a été dérobé.
D’autres messages ont aussi d’autres causes. L’erreur max-fee-exceeded concerne une protection sur les frais, et non ces vulnérabilités. Confondre les symptômes conduit à des interventions inutiles ou risquées. Il faut d’abord établir la version exécutée, la plateforme et le message observé.
Vérifier avant d’improviser une récupération
Pour un exploitant, les premières vérifications portent sur la version réellement active, le système d’exploitation, l’architecture et le système de fichiers du répertoire des blocs. Les mises à jour doivent provenir des canaux officiels, avec les contrôles d’authenticité du projet et la préservation des sauvegardes du wallet. Aucune mise à jour légitime ne nécessite de communiquer sa phrase de récupération à une assistance.
L’avis undo mentionne une réindexation avec une version corrigée pour réparer le dommage précis décrit. Ce n’est pas une consigne de lancer -reindex sur tout nœud lent : diagnostic, protection des données et ressources disponibles passent d’abord. Nous n’avons ni reproduit les attaques ni testé une installation ; cet article compare les correctifs publiés et leurs limites explicites.
