L’utilisation de Kimi K3 pour trouver la faille dans le serveur HTTP n’est pas un cas isolé. La Bitcoin Red Team utilise la même IA pour rechercher des vulnérabilités dans le logiciel Bitcoin, bien que bon nombre de ces rapports nécessitent ensuite une vérification humaine pour être considérés comme des vulnérabilités confirmées.
Voici l'article complet avec le correctif appliqué :
Le compte à rebours jusqu'au prochain grand événement Mise à jour du noyau Bitcoin cela a officiellement commencé le 14 septembre 2026, lorsque les développeurs ont marqué la première version candidate de la version 32.0. Depuis lors, le logiciel qui exécute la grande majorité des nœuds Bitcoin est entré dans la phase finale de tests, avec l'objectif déclaré d'arriver à une version stable d'ici le 10 octobre 2026. Il ne s'agit pas d'un changement cosmétique : à l'intérieur, il y a de nouveaux critères de calcul des frais, une vérification de bloc plus rapide et deux correctifs de sécurité que les développeurs ont considérés comme prioritaires avant la version finale.
Bitcoin Core 32.0 entre dans la phase de test des versions candidates
La version candidate v32.0rc1 correspond au commit d0231bb, signé numériquement par un mainteneur vérifié le 14 septembre à 12h58 UTC. Le lendemain, le 15 septembre, le projet ouvrait un fil de discussion dédié sur GitHub pour recueillir les retours des testeurs avant de passer à la version finale. Au 16 septembre, aucun binaire stable de la v32.0 n'avait encore été publié.
Les développeurs sont entrés gel des fonctionnalités le 20 août, bloquant les nouvelles fonctionnalités et se concentrant uniquement sur les correctifs nécessaires. Le calendrier officiel du projet confirme le 10 octobre comme date cible pour la balise finale, même si – comme cela arrive souvent avec Bitcoin Core – le résultat des tests pourrait faire glisser la date limite.
Un détail à retenir : Bitcoin Core ne se met pas à jour automatiquement. Les opérateurs de nœuds décident quand installer les nouvelles versions, ce qui signifie que les anciens logiciels peuvent rester actifs longtemps après la publication des nouvelles versions. Ce modèle a déjà eu des conséquences concrètes : en mai, Bitcoin Core a rendu public CVE-2024-52911 seulement après que la branche vulnérable 28.x ait atteint la fin du support, alors que le bug avait déjà été corrigé dans la version 29.0.
Nouvel estimateur de commissions : moins de rigidité, plus de réactivité
À ce jour, Bitcoin Core calcule la commission suggérée en examinant principalement l'historique des transactions confirmées dans les blocs précédents. La version 32 ajoute un deuxième estimateur, basé sur les transactions toujours en attente dans le mempool du nœud.
Le nouveau système produit des estimations à la fois économiques et conservatrices à partir des conditions actuelles du réseau, mais est automatiquement rejeté si le pool de mémoire est trop clairsemé ou peu fiable. Lorsque les deux méthodes renvoient un résultat valide, la fonctionestimatesmartfee choisit l'estimation la plus basse entre les deux : en pratique, le nouvel estimateur ne peut que baisser la recommandation, jamais l'augmenter par rapport à la méthode classique basée sur les blocs.
Pourquoi ce détail est-il important ? Car jusqu’à présent, après un pic de congestion, les estimations ont eu tendance à rester élevées pendant un certain temps, tout simplement parce qu’elles continuaient à refléter des transactions coûteuses confirmées lors des blocs récents. Avec le système double, les contribuables pourraient voir leurs estimations baisser plus rapidement à mesure que le pool de mémoire se dégonfle, même si le bloc précédent était encore « cher ». Cependant, les développeurs ont laissé une issue de secours à ceux qui préfèrent l'ancien comportement : un paramètre fee_rate_estimator permet de demander explicitement block_policy, mempool_policy ou le mode combiné par défaut.
Vérification plus rapide des blocs grâce à la lecture parallèle de la base de données
L’un des changements les plus techniques, mais avec des effets concrets pour ceux qui gèrent un nœud, concerne la manière dont Bitcoin Core récupère les données de transaction lors de la validation du bloc. Le logiciel peut désormais lire ce que l'on appelle les prévouts – des informations sur les pièces dépensées à partir des entrées d'une transaction – à partir de la base de données chainstate en utilisant plusieurs threads de travail à la fois, au lieu d'un seul séquentiellement.
La valeur par défaut est huit threads de prélecturemais l'opérateur peut l'augmenter à 16 ou désactiver complètement la récupération parallèle en définissant le paramètre sur zéro via l'option -prevoutfetchthreads=. L'objectif est de réduire le temps perdu à attendre les lectures sur le disque, en particulier lorsqu'un nœud rattrape son retard sur la blockchain et doit traiter des blocs dont les entrées ne sont pas encore disponibles dans des caches plus rapides. Il est important de souligner que cette accélération concerne uniquement la vérification des blocs : la vitesse à laquelle Bitcoin produit de nouveaux blocs reste inchangée, et les règles de consensus du réseau ne sont en aucun cas affectées par la version 32.
PSBT version 2 comme nouveau standard pour quatre commandes de portefeuille
Quatre commandes utilisées pour créer des transactions partiellement signées — createpsbt, walletcreatepsbt, converttopsbt et psbtbumpfee — adopteront par défaut le format PSBT version 2. Il s'agit du format dans lequel les portefeuilles, les applications et les périphériques de signature échangent des informations sur les transactions avant qu'elles ne soient transmises sur le réseau.
La compatibilité ascendante demeure : les développeurs ont ajouté un paramètre facultatif psbt_version qui permet aux applications de demander explicitement l'ancien format. Ceux qui ont construit des services autour de ces commandes devront encore vérifier qu'elles supportent correctement la version 2, peut-être en testant la compatibilité au préalable avant le changement définitif.
Entre autres nouvelles fonctionnalités côté portefeuille, une nouvelle commande exportwatchonlywallet crée un fichier de descripteur de portefeuille contenant des descripteurs publics, l'historique des transactions et le carnet d'adresses, sans inclure les clés privées — utile pour ceux qui souhaitent configurer un portefeuille en lecture seule en ligne. Nous ajoutons également derivehdkey et addhdkey, conçus pour dériver ou ajouter des clés étendues selon la norme BIP32.
La solution la plus délicate : le bug du nouveau serveur HTTP
Nous arrivons ici au cœur de Correctif de sécurité Bitcoin Core le plus pertinent de cette version. La version 32 remplace le serveur HTTP existant basé sur Libevent par un tout nouveau, qui gère les requêtes des applications connectées à un nœud. Lors de l'audit de ce nouveau composant – réalisé à l'aide du modèle Kimi K3 de Moonshot AI, le même outil utilisé par la Bitcoin Red Team pour rechercher des vulnérabilités dans le logiciel Bitcoin – un problème grave est apparu.
Le serveur peut continuer à accepter les données d'un client tout en traitant une demande précédente, sans limite de taille effective. Ces données s'accumulent en mémoire plus rapidement que le serveur ne peut les éliminer, créant ainsi un moyen d'épuiser progressivement la mémoire disponible de l'ordinateur, une condition connue sous le nom de « MOO » (manque de mémoire).
Le développeur Matthew Zipkin, qui a soumis le correctif avec la pull request n° 36123, a initialement limité le risque aux seuls clients authentifiés capables de maintenir une demande occupée. Mais en examinant le correctif, jeanpablojp, utilisateur de GitHub, a découvert que même les requêtes sans informations d'identification pouvaient provoquer la même croissance de mémoire lorsque l'interface REST du nœud était active.
Les chiffres parlent d'eux-mêmes : seize connexions REST non authentifiées ont poussé un nœud de test de 46 Mo à environ 3 Go d'occupation mémoire en un peu plus d'une minute. Un test de 90 secondes a enregistré 3,2 Go de mémoire consommée avant le correctif, contre environ 3 Mo après le correctif. Le patch a été fusionné dans le code le 5 septembre, avant même la balise release candidate : comme le nouveau serveur HTTP n'était jamais apparu dans une version stable de Bitcoin Core, le Vulnérabilités des nœuds Bitcoin il a été intercepté avant de pouvoir atteindre les utilisateurs en production.
La faille dans les noms de portefeuille et la sécurité du portefeuille Bitcoin
La deuxième intervention de sécurité concerne une faille présente depuis Bitcoin Core 24.0 sur les systèmes non Windows. Un utilisateur RPC authentifié, autorisé à créer des portefeuilles, peut attribuer un nom de portefeuille contenant des caractères de substitution spéciaux. Si le nœud était configuré avec l'option -walletnotify – une fonction qui exécute automatiquement une commande choisie à chaque fois qu'une transaction de portefeuille se produit – ce nom pourrait déclencher l'exécution de commandes arbitraires avec les privilèges de processus Bitcoin Core.
La version 32 résout le problème en traitant les noms de portefeuille comme du texte littéral, et n'en interprétant plus certaines parties comme des commandes. La version renforce également les règles sur les noms de portefeuille, en rejetant ceux contenant des chemins relatifs avec des éléments tels que « ». ou « .. ». Il faut dire que l’attaque nécessitait tout de même des conditions particulières – accès authentifié et activation de walletnotify – et ne concernait donc pas toute personne gérant un nœud, mais uniquement des configurations particulières.
Un contexte plus large : la sécurité de l’écosystème Bitcoin à travers le prisme de l’IA
L’utilisation de Kimi K3 pour trouver la faille dans le serveur HTTP n’est pas un cas isolé. La Bitcoin Red Team utilise la même IA pour rechercher des vulnérabilités dans le logiciel Bitcoin, bien que bon nombre de ces rapports nécessitent ensuite une vérification humaine pour être considérés comme des vulnérabilités confirmées.
D'autres logiciels de l'écosystème ont également été confrontés à des problèmes similaires ces dernières semaines. Le fabricant de portefeuilles matériels BitBox a corrigé deux vulnérabilités du micrologiciel jugées graves en août, sans trouver de preuve d'exploitation active. Les développeurs de Éclair de basele logiciel de paiement Lightning, ont plutôt alerté les opérateurs des nœuds de vulnérabilité confirmés – apparus après l'analyse des rapports générés avec l'intelligence artificielle – les invitant à mettre à jour ou à passer temporairement en mode hors ligne.
L’image qui se dessine est celle d’un examen de sécurité de plus en plus assisté par des modèles d’IA, capables d’identifier des modèles anormaux dans le code plus rapidement que les seuls audits manuels. Il reste à voir dans quelle mesure ces outils peuvent évoluer sans générer une charge excessive de faux positifs à vérifier, mais dans le cas du serveur HTTP Bitcoin Core, le résultat a été une grave faille qui a été corrigée avant de pouvoir apparaître dans une version stable.
À quoi s'attendre d'ici le 10 octobre
Le fil de commentaires ouvert le 15 septembre reste actif, les développeurs invitant ceux qui identifient des défauts concrets à ouvrir des rapports séparés sur GitHub avant la version finale. Là nouvelle version Bitcoin Core cela ne change pas les règles selon lesquelles le réseau considère les transactions et les blocages valides, mais il introduit quand même des changements qui nécessiteront l'attention de ceux qui gèrent les services construits sur l'API Core – en particulier pour ceux qui s'appuient sur les commandes PSBT ou l'estimateur de frais.
La date du 10 octobre reste l'objectif officiel, mais le projet l'a déjà indiqué comme sujet à changement en fonction des résultats des tests en cours.
FAQ
Quand est attendue la version finale de Bitcoin Core 32.0 ?
Les développeurs visent à publier la version finale de Bitcoin Core 32.0 vers le 10 octobre 2026, bien que le calendrier puisse changer en fonction des résultats des tests en cours de la version candidate.
Quelles améliorations Bitcoin Core 32.0 apporte-t-il à la vérification du blocage ?
La mise à jour accélère la vérification des blocs en lisant les informations de la base de données en parallèle sur plusieurs threads de travail (huit par défaut), sans affecter la vitesse à laquelle Bitcoin produit de nouveaux blocs.
Quels problèmes de sécurité Bitcoin Core 32.0 résout-il ?
Corrige une vulnérabilité dans laquelle des noms de portefeuille spécialement conçus pouvaient déclencher des commandes indésirables sur des nœuds non Windows et corrige un bogue d'épuisement de la mémoire dans le nouveau serveur HTTP qui affectait à la fois les clients authentifiés et non authentifiés.
Quels changements dans les commandes du portefeuille avec Bitcoin Core 32.0 ?
Quatre commandes de portefeuille sont par défaut au format PSBT version 2 pour les transactions partiellement signées, conservant ainsi une compatibilité ascendante avec un paramètre facultatif qui vous permet de toujours exiger l'ancien format.
Contenu créé avec l’aide de l’intelligence artificielle et de la révision éditoriale humaine.
Voir l’article original en italien
