Le 22 octobre, Bitcoin Core a fusionné une modification de ses règles qui ouvre une voie accélérée pour corriger les vulnérabilités : une faille jugée facile à retrouver pour des attaquants peut désormais être corrigée simultanément dans toutes les branches de versions encore maintenues, avec la publication d’un avis à mesure que chaque correctif est déployé. Cette modification intervient alors qu’un instantané du réseau réalisé par l’Institut de technologie de Karlsruhe (KIT) montre que 43,6 % des pairs Bitcoin Core publics échantillonnés utilisent des versions qui ne reçoivent plus de correctifs.
Selon la nouvelle règle, les développeurs peuvent classer une faille lors du triage en évaluant la facilité avec laquelle elle peut être retrouvée, y compris avec l’aide de grands modèles de langage. Le développeur de Bitcoin Core Antoine Poinsot a annoncé ce changement sur la liste de diffusion bitcoindev, dans la demande de fusion qui met à jour la politique de sécurité du projet. Il a fait valoir que l’ancien embargo apporte peu, tout en retardant la disponibilité d’une version corrigée. Le compromis qu’il a souligné est que les mesures d’atténuation disposent de moins de temps pour faire leurs preuves dans les branches de développement. Au 23 octobre, cette nouvelle catégorie n’avait pas encore été appliquée publiquement à un bug précis.
Ce changement met fin à une politique qui retenait les détails des bogues de gravité moyenne et élevée jusqu’à deux semaines après la fin de vie de la dernière version concernée, un délai pouvant approcher un an. L’embargo — la période pendant laquelle les détails d’une vulnérabilité restent confidentiels, jusqu’à ce que les versions corrigées soient largement déployées — reposait sur le fait que les bogues étaient difficiles à redécouvrir. Les outils d’IA fragilisent cette hypothèse : les longues périodes de silence retardent désormais davantage les correctifs qu’elles ne protègent les opérateurs.
Conséquences de l’ancienne politique
La pratique du projet est illustrée par la divulgation de CVE-2024-52911. Cette vulnérabilité de gravité élevée de type use-after-free dans la validation des blocs, qui touchait les versions postérieures à la 0.14.0 et antérieures à la 29.0 et permettait à un bloc invalide spécialement conçu de faire planter un nœud, a été signalée en novembre 2024, corrigée dans la version 29.0 en avril 2025, puis divulguée le 5 mai 2026, environ 388 jours après la correction. Le même schéma se poursuit : les notes de version de la 32.0 indiquent que trois failles de gravité moyenne ou élevée corrigées dans la version 30.0 resteront confidentielles jusqu’à deux semaines après la sortie de la nouvelle version.
La part des versions non prises en charge
Bitcoin Core ne maintient que ses trois branches majeures les plus récentes, actuellement les 29.x, 30.x et 31.x. Le relevé du KIT daté du 18 oct. recensait 3 671 pairs Bitcoin Core sur 8 422 ayant déclaré eux-mêmes utiliser des branches en fin de vie ; les autres utilisaient la 31.x (3 243), la 30.x (712) et la 29.x (635). Ce décompte ne concerne que les pairs publics IPv4 et IPv6 : les nœuds accessibles uniquement par Tor, ceux qui n’écoutent pas les connexions ainsi que les infrastructures privées exploitées par des plateformes d’échange, des dépositaires et des mineurs n’y figurent pas. Pour en savoir plus sur les notions de base, les lecteurs peuvent commencer par découvrir ce que sont les nœuds crypto et comment ils fonctionnent.
Cette part devrait augmenter. À la sortie de la version 32.0, la branche 29.x sortira de la fenêtre de maintenance. Selon une projection fondée sur le relevé, 4 306 des 8 422 pairs, soit 51,1 %, utiliseraient des branches non prises en charge si l’échantillon restait inchangé. Au 24 oct., la page du projet consacrée au cycle de vie indiquait toujours que la date de sortie de la 32.0 était à déterminer ; seul des versions candidates figuraient dans le répertoire de téléchargement.
Core 32.0 remplace également le format par défaut des transactions Bitcoin partiellement signées, passant de la version 0 à la version 2, ce qui est important pour les configurations multisignatures combinant d’anciens et de nouveaux nœuds. Bitcoin ne disposant d’aucune autorité centrale capable d’imposer les mises à niveau, la sécurité du réseau dépend des opérateurs qui choisissent de mettre à jour leurs systèmes.