Bitcoin Core accélère ses correctifs de sécurité alors que 44 % des nœuds analysés sont obsolètes

Cette modification intervient alors qu’un relevé du Karlsruhe Institute of Technology (KIT) montre que 43,6 % des pairs publics Bitcoin Core échantillonnés tournent sur des versions qui ne reçoivent plus de correctifs. Le projet ne maintient actuellement que ses trois dernières grandes lignes, soit 29.x, 30.x et 31.x.

Une nouvelle catégorie pour les failles

Dans le nouveau dispositif, les développeurs peuvent classer une faille au moment du triage, en évaluant à quel point elle peut être redécouverte, y compris avec l’aide de grands modèles de langage. Antoine Poinsot, développeur Bitcoin Core, a annoncé ce changement sur la liste de diffusion bitcoindev dans le cadre de la demande d’intégration qui met à jour la politique de sécurité du projet.

Il a soutenu que l’ancien embargo « n’apporte pas grand-chose » tout en retardant la disponibilité d’une version corrigée. Le compromis évoqué est que les mesures d’atténuation disposent de moins de temps pour faire leurs preuves sur les branches de développement. Au 23 octobre, cette nouvelle catégorie n’avait encore été appliquée publiquement à aucun bug précis.

Le changement met fin à une règle qui retenait les détails des bugs de gravité moyenne et élevée jusqu’à deux semaines après la fin de vie de la dernière version concernée, une période qui pouvait s’étendre sur près d’un an. L’embargo, c’est-à-dire la période pendant laquelle les détails d’une vulnérabilité restent cachés jusqu’à la diffusion des versions corrigées, supposait que les failles soient difficiles à redécouvrir.

Des versions de plus en plus hors maintenance

L’évolution de la politique s’illustre avec CVE-2024-52911. Cette faille high-severity de type use-after-free dans la validation des blocs, qui touchait les versions postérieures à 0.14.0 et antérieures à 29.0 et permettait à un bloc invalide fabriqué sur mesure de faire planter un nœud, a été signalée en novembre 2024, corrigée dans 29.0 en avril 2025, puis divulguée le 5 mai 2026, soit environ 388 jours après le correctif.

Le scénario se répète dans les notes de version de 32.0, où il est indiqué que trois failles de gravité moyenne ou élevée corrigées dans la version 30.0 restent sous silence jusqu’à deux semaines après la sortie de la nouvelle version. Le relevé du KIT, daté du 18 octobre, a compté 3 671 des 8 422 pairs Bitcoin Core auto-déclarés sur des lignes déjà arrivées en fin de vie, contre 3 243 sur 31.x, 712 sur 30.x et 635 sur 29.x.

Ce comptage ne couvre que les pairs publics en IPv4 et IPv6, à l’exclusion des nœuds accessibles uniquement via Tor, des nœuds non écoutants et des infrastructures privées d’exchanges, de dépositaires et de mineurs. Lorsque la version 32.0 sera publiée, 29.x sortira de la fenêtre de maintenance, et la projection tirée du relevé fait état de 4 306 des 8 422 pairs, soit 51,1 %, sur des lignes non supportées si l’échantillon restait inchangé.

La page du cycle de vie du projet indiquait encore, au 24 octobre, que la date de sortie de 32.0 était TBA, avec seulement des release candidates dans le répertoire de téléchargement. La version 32.0 doit aussi modifier le format PSBT par défaut de la version 0 à la version 2, un point important pour les configurations multisig mêlant anciens et nouveaux nœuds.