Bitcoin Core Révèle Trois Failles Déjà Corrigées

Il y a des annonces qui passent presque inaperçues et d’autres qui, même lorsqu’elles concernent des problèmes déjà résolus, rappellent à quel point la vigilance reste une nécessité permanente dans l’écosystème Bitcoin. Le 11 novembre 2026, l’équipe de développement de Bitcoin Core a choisi de rendre publiques trois failles de sécurité qui touchaient son logiciel de nœud. Toutes avaient déjà été corrigées plus d’un an auparavant. La plus préoccupante d’entre elles pouvait empêcher purement et simplement certains mineurs de construire leurs gabarits de blocs. Cette divulgation, volontairement différée, soulève des questions importantes sur la gestion des vulnérabilités, sur le fonctionnement interne du mempool et sur la responsabilité des opérateurs de nœuds.

Trois Failles Anciennes Mais Toujours Instructives

Bitcoin Core reste le logiciel de référence pour faire tourner un nœud complet sur le réseau Bitcoin. Des dizaines de milliers d’opérateurs s’appuient sur lui chaque jour pour valider les transactions, relayer les blocs et participer à la sécurisation de la chaîne. Lorsque l’équipe publie des avis de sécurité, même concernant des problèmes déjà résolus, cela attire l’attention de toute la communauté technique. Cette fois, trois identifiants CVE ont été communiqués : CVE-2025-62861, CVE-2025-62859 et CVE-2025-62860. Aucune d’entre elles n’a atteint le niveau critique réservé aux bogues capables de voler des fonds ou de provoquer une scission permanente de la chaîne. Pourtant, chacune mérite d’être examinée en détail.

Les correctifs ont été intégrés dès octobre 2025. La version 30.0 est sortie le 10 octobre, suivie de la 29.2 le 14 octobre. Pendant plus d’un an, les développeurs ont préféré laisser le temps aux utilisateurs de mettre à jour leurs installations avant de décrire précisément les failles. Cette pratique, courante dans les projets open source de grande envergure, vise à limiter les risques d’exploitation pendant la période de transition. Elle n’empêche pas, une fois les correctifs largement diffusés, de documenter publiquement ce qui s’est passé afin que la communauté puisse en tirer des leçons.

La Faille Qui Pouvait Paralyser Les Mineurs

La vulnérabilité la plus sérieuse porte le numéro CVE-2025-62861. Classée de sévérité élevée, elle concernait directement le mempool, cette salle d’attente où un nœud conserve les transactions non encore confirmées. Selon les précisions fournies dans l’avis officiel, une réorganisation de la chaîne pouvait déclencher l’éviction erronée de certaines transactions. Le mempool se retrouvait alors corrompu. Dans cet état, le nœud devenait incapable de construire un gabarit de bloc correct. Un redémarrage complet était nécessaire pour rétablir le fonctionnement normal.

Pour un mineur, l’impossibilité de produire un template de bloc valide représente un problème opérationnel majeur. Pendant le temps où le nœud reste bloqué, la puissance de calcul engagée ne produit plus de candidats valides. Dans un environnement où chaque seconde compte et où la concurrence entre pools est féroce, une telle interruption peut se traduire par une perte de revenus immédiate. Les versions touchées allaient de la 28.0 à la 28.2 ainsi que de la 29.0 à la 29.1. Le chercheur en sécurité Niklas Goegge a signalé le problème le 26 septembre 2025, soit peu de temps avant les sorties correctives d’octobre.

Une réorganisation de la chaîne pouvait déclencher l’éviction erronée de certaines transactions, corrompant le mempool d’un nœud si bien que celui-ci ne pouvait plus construire de gabarits de blocs avant un redémarrage.

Avis de sécurité Bitcoin Core

Ce type de bogue illustre parfaitement la complexité du code qui gère les réorganisations. Lorsque la chaîne principale change de branche, le nœud doit retirer certaines transactions et en réintégrer d’autres. Un simple décalage dans la logique d’éviction suffit à laisser le mempool dans un état incohérent. Les développeurs ont corrigé le comportement dès la version 30.0, mais les opérateurs qui continuent de faire tourner des versions non prises en charge restent exposés. La leçon est claire : la mise à jour régulière n’est pas une option, c’est une obligation de sécurité.

Ralentissement Du Traitement Des Blocs Compacts

La deuxième faille, CVE-2025-62859, a été classée de sévérité moyenne. Elle permettait à un pair malveillant de ralentir significativement le traitement des blocs en annonçant un bloc compact dont les données de témoin avaient été manipulées. Il s’agit d’une forme de malléation de transaction. Dans certains cas, le nœud ciblé pouvait attendre jusqu’à dix minutes avant de traiter correctement le bloc concerné.

Les blocs compacts ont été introduits pour réduire la bande passante nécessaire lors de la propagation. Au lieu d’envoyer l’intégralité du bloc, un nœud envoie un résumé et s’appuie sur le mempool local pour reconstruire le contenu. Cette optimisation repose sur la confiance relative dans les données déjà connues. Lorsqu’un adversaire parvient à injecter des données de témoin incorrectes, le nœud doit effectuer des vérifications supplémentaires ou attendre des informations manquantes. Le délai de dix minutes mentionné dans l’avis n’est pas anodin. Dans un réseau où la propagation rapide des blocs est un facteur de sécurité contre les attaques de type selfish mining, tout ralentissement artificiel affaiblit la résilience globale.

Les développeurs ont renforcé les contrôles de cohérence sur les données de témoin. Aujourd’hui, un nœud à jour rejette plus rapidement les annonces incohérentes. Pourtant, les opérateurs qui n’ont pas encore migré vers une version corrigée restent vulnérables à ce type de ralentissement. Dans un contexte où certains acteurs cherchent constamment des moyens de perturber la propagation, chaque millisecondes gagnée ou perdue compte.

Permissions Excessives Sur Les Connexions Tor

La troisième vulnérabilité, CVE-2025-62860, touche à la confidentialité et à la protection contre les dénis de service. Les connexions entrantes passant par le réseau Tor recevaient à tort des permissions de liste blanche. Ces permissions levaient certaines protections normalement actives contre les attaques par inondation et réduisaient également le niveau de confidentialité attendu sur les nœuds concernés.

Tor est souvent utilisé par les opérateurs qui souhaitent masquer l’adresse IP de leur nœud. Le logiciel Bitcoin Core propose des options spécifiques pour gérer ces connexions. Une erreur dans l’attribution des permissions pouvait placer un nœud Tor dans une situation où il acceptait plus facilement des connexions malveillantes. Les protections contre le déni de service, conçues pour limiter le nombre de connexions ou la vitesse d’envoi de messages, se trouvaient partiellement désactivées. De même, certaines mesures destinées à empêcher le suivi des transactions ou des blocs perdaient de leur efficacité.

Cette faille n’a jamais été exploitée de manière documentée, selon les avis publiés. Elle n’en demeure pas moins révélatrice des subtilités de configuration qui existent entre les différents types de connexions. Les développeurs ont corrigé l’attribution des permissions afin que les connexions Tor reçoivent le traitement approprié. Les utilisateurs qui font tourner un nœud derrière Tor ont donc tout intérêt à vérifier qu’ils utilisent une version postérieure à octobre 2025.

Pourquoi Aucune Faille N’a Atteint Le Niveau Critique

Bitcoin Core classe les vulnérabilités selon une échelle interne stricte. Le niveau critique est réservé aux bogues qui menacent directement les fonds des utilisateurs au niveau du protocole, qui permettraient de créer des pièces sans autorisation ou qui pourraient provoquer une scission permanente de la chaîne à l’échelle du réseau. Aucune des trois failles publiées le 11 novembre 2026 n’entre dans cette catégorie.

CVE-2025-62861 affectait la capacité d’un nœud à construire des gabarits, mais ne permettait pas de voler des bitcoins ni de valider des transactions invalides. CVE-2025-62859 ralentissait le traitement, sans compromettre l’intégrité des données. CVE-2025-62860 affaiblissait certaines protections, sans ouvrir la porte à un vol de fonds. Cette distinction est importante. Elle montre que même lorsqu’un problème de sévérité élevée est découvert, le protocole de base reste robuste. La sécurité de Bitcoin repose sur plusieurs couches. Un bogue dans la gestion du mempool n’équivaut pas à une faille dans la validation des signatures ou dans les règles de consensus.

L’équipe a également précisé qu’aucune exploitation de ces trois failles n’avait été signalée. Cette information rassure, mais elle ne doit pas conduire à un excès de confiance. L’absence de signalement ne signifie pas nécessairement l’absence d’exploitation discrète. C’est précisément pour cette raison que les correctifs ont été déployés rapidement et que la divulgation publique a été reportée.

Le Contexte Des Divulgations Différées

La pratique de la divulgation différée n’est pas nouvelle dans l’univers Bitcoin Core. Lorsque les développeurs découvrent ou reçoivent un rapport de vulnérabilité, ils évaluent d’abord la gravité, préparent un correctif, le testent, puis le intègrent dans une version stable. Une fois que suffisamment d’opérateurs ont mis à jour, ils publient les détails. Cette approche limite la fenêtre pendant laquelle un attaquant pourrait utiliser les informations pour cibler des nœuds non corrigés.

Dans le cas présent, plus de treize mois se sont écoulés entre la correction et la publication. Ce délai peut paraître long, mais il s’explique par la volonté de laisser le maximum de temps aux utilisateurs. Les versions 30.0 et 29.2 ont eu le temps de se diffuser largement. Les opérateurs les plus attentifs ont déjà basculé depuis longtemps. Ceux qui restent sur des versions plus anciennes le font en connaissance de cause ou par négligence. La publication des avis sert alors de rappel public.

Bitcoin Core a déjà rendu public d’autres bogues sensibles par le passé, dont une faille liée aux PSBT qui pouvait, dans certaines conditions, rediriger des fonds sans nécessiter le vol des clés privées. Chaque divulgation enrichit la base de connaissances collective et permet aux chercheurs indépendants de mieux comprendre les zones sensibles du code.

L’Importance Cruciale Des Mises À Jour

Les opérateurs qui font tourner un nœud sous une version non prise en charge restent les plus exposés. Seule la mise à jour du logiciel apporte les correctifs. Cette évidence mérite d’être répétée. Beaucoup d’utilisateurs installent Bitcoin Core, le configurent, puis l’oublient pendant des mois ou des années. Tant que le nœud continue de synchroniser la chaîne, ils estiment que tout va bien. Or un nœud qui fonctionne n’est pas forcément un nœud sécurisé.

Les versions 28.x et 29.0-29.1 mentionnées dans les avis ne reçoivent plus de correctifs de sécurité. Continuer à les utiliser expose l’opérateur non seulement aux trois failles désormais publiques, mais aussi à d’éventuelles autres vulnérabilités non encore divulguées. Dans un réseau décentralisé, la sécurité collective dépend de la sécurité individuelle de chaque nœud. Un grand nombre de nœuds obsolètes affaiblit la résilience globale, même si le protocole de consensus reste intact.

La mise à jour n’est pas toujours anodine. Certains opérateurs utilisent des configurations particulières, des scripts d’automatisation ou des interfaces graphiques tierces. Une migration peut nécessiter des ajustements. Pourtant, le coût d’une mise à jour reste infiniment inférieur au risque d’exploiter une faille connue, surtout lorsque celle-ci a déjà été documentée publiquement.

Le Rôle Du Mempool Dans La Sécurité Quotidienne

La faille CVE-2025-62861 met en lumière le rôle central du mempool. Cet espace mémoire stocke les transactions qui attendent d’être incluses dans un bloc. Sa gestion influence directement la capacité d’un nœud à proposer des blocs valides et à relayer efficacement les nouvelles transactions. Une corruption du mempool ne compromet pas les fonds déjà confirmés, mais elle peut paralyser temporairement une partie des fonctions du nœud.

Les réorganisations de chaîne, bien que rares en profondeur, font partie du fonctionnement normal de Bitcoin. Lorsqu’un bloc plus long apparaît, le nœud doit revenir en arrière, retirer les transactions du bloc orphelin et éventuellement les réintégrer dans le mempool. La logique qui décide quelles transactions conserver et lesquelles évacuer doit être parfaitement robuste. Un simple décalage dans les conditions de nettoyage a suffi, dans ce cas, à laisser le mempool dans un état inutilisable pour la construction de gabarits.

Les développeurs ont renforcé les contrôles et corrigé le comportement d’éviction. Aujourd’hui, un nœud à jour gère ces situations de manière plus fiable. Pourtant, l’incident rappelle que même les composants apparemment stables peuvent cacher des cas limites. La complexité du code Bitcoin Core, fruit de plus de quinze années d’évolution, exige une attention constante.

Propagation Des Blocs Et Résilience Du Réseau

La deuxième faille, liée aux blocs compacts, touche un autre aspect crucial : la vitesse de propagation. Plus un bloc se diffuse rapidement, plus il devient difficile pour un mineur malveillant de conserver secrètement une chaîne alternative. Les optimisations introduites au fil des ans, dont les compact blocks, ont considérablement réduit la bande passante nécessaire. Elles reposent toutefois sur des hypothèses de cohérence des données déjà présentes dans le mempool local.

Lorsqu’un adversaire parvient à introduire des données de témoin manipulées, le nœud doit résoudre l’incohérence. Le délai de dix minutes évoqué dans l’avis représente un scénario extrême, mais même des ralentissements plus modestes peuvent s’accumuler. Dans un réseau où des milliers de nœuds échangent en permanence, la robustesse face à ce type de perturbation contribue à la sécurité globale.

Les correctifs ont renforcé la validation des données de témoin avant de les utiliser pour reconstruire un bloc. Cette mesure réduit la surface d’attaque sans compromettre les gains de performance apportés par les blocs compacts. L’équilibre entre efficacité et sécurité reste un défi permanent pour les développeurs.

Confidentialité Et Connexions Anonymisées

L’utilisation de Tor avec Bitcoin Core répond à un besoin réel de confidentialité. Certains opérateurs ne souhaitent pas que leur adresse IP soit associée à un nœud Bitcoin. D’autres cherchent à se protéger contre des attaques ciblées ou des pressions extérieures. Le logiciel offre des options pour écouter sur des adresses onion et pour se connecter exclusivement via Tor.

La faille CVE-2025-62860 montrait qu’une erreur d’attribution de permissions pouvait affaiblir à la fois la protection contre les dénis de service et certaines mesures de confidentialité. Les listes blanches de permissions existent pour permettre à des pairs de confiance d’envoyer plus de messages ou de se connecter plus facilement. Les appliquer par erreur à des connexions Tor ouvrait une brèche.

Les développeurs ont corrigé la logique d’attribution. Désormais, les connexions entrantes via Tor reçoivent le traitement prévu pour ce type de pair. Les opérateurs qui valorisent la confidentialité doivent s’assurer qu’ils utilisent une version corrigée et vérifier régulièrement la configuration de leur nœud. La confidentialité n’est jamais acquise une fois pour toutes ; elle dépend de la qualité du code et de la rigueur de la configuration.

Historique Récent Des Avis De Sécurité

Bitcoin Core publie régulièrement des avis de sécurité. Certains concernent des problèmes mineurs, d’autres des failles plus sérieuses. La divulgation d’une vulnérabilité PSBT capable, dans certaines conditions, de rediriger des fonds avait déjà marqué les esprits. Ces publications rappellent que le logiciel, malgré sa maturité, continue d’évoluer et de faire face à de nouveaux cas d’usage ou à de nouvelles techniques d’analyse.

Chaque avis enrichit la documentation disponible. Les chercheurs indépendants, les opérateurs de pools de minage et les entreprises qui s’appuient sur Bitcoin Core peuvent étudier les descriptions, comprendre les scénarios d’attaque et renforcer leurs propres pratiques. La transparence, même différée, reste un pilier de la confiance placée dans le projet.

Le fait qu’aucune exploitation des trois failles de 2025 n’ait été signalée constitue un point positif. Il suggère soit que les attaquants n’ont pas découvert les problèmes avant les correctifs, soit qu’ils n’ont pas jugé rentable de les exploiter, soit que les victimes n’ont pas identifié la cause de dysfonctionnements ponctuels. Dans tous les cas, la publication des détails permet désormais à chacun de vérifier si son nœud a pu être affecté par le passé.

Impact Sur Les Différents Types D’Opérateurs

Tous les utilisateurs de Bitcoin Core ne sont pas égaux face à ces failles. Un particulier qui fait tourner un nœud pour valider ses propres transactions et contribuer à la décentralisation du réseau subit un impact limité. Un redémarrage suffit à rétablir le fonctionnement après une corruption de mempool. En revanche, un pool de minage ou un opérateur professionnel qui dépend de la construction continue de gabarits de blocs peut subir des pertes financières immédiates.

Les services qui s’appuient sur des nœuds Bitcoin pour offrir des API, des explorateurs de blocs ou des portefeuilles en ligne doivent également rester particulièrement vigilants. Un ralentissement du traitement des blocs ou une faiblesse dans la gestion des connexions Tor peut se répercuter sur la qualité de service perçue par les clients. Dans un marché concurrentiel, la fiabilité technique constitue un argument différenciant.

Les chercheurs en sécurité et les auditeurs profitent quant à eux de ces publications pour affiner leurs méthodes d’analyse. Chaque faille documentée devient un cas d’étude. La communauté open source dans son ensemble progresse grâce à ces partages d’expérience.

La Culture De La Sécurité Dans L’écosystème Bitcoin

Bitcoin a bâti sa réputation en partie sur la robustesse de son protocole et sur la prudence de ses développeurs principaux. Les changements de consensus font l’objet de discussions longues et approfondies. Les modifications du code de référence passent par des revues de pairs rigoureuses. Pourtant, des bogues continuent d’apparaître. Cette réalité n’est pas un échec ; elle est inhérente à tout logiciel complexe maintenu sur le long terme.

La différence réside dans la manière dont ces bogues sont gérés. La procédure de divulgation responsable, le délai laissé pour les mises à jour et la publication détaillée une fois les risques maîtrisés constituent des pratiques saines. Elles contrastent avec d’autres projets qui choisissent parfois de minimiser les problèmes ou de les corriger en silence sans jamais informer la communauté.

Les utilisateurs ont aussi un rôle à jouer. Lire les avis de sécurité, comprendre les versions concernées et appliquer les correctifs fait partie des responsabilités d’un opérateur de nœud. La décentralisation ne se limite pas à la répartition géographique des machines ; elle inclut la capacité de chacun à maintenir son logiciel à jour.

Perspectives Pour Les Prochaines Versions

Les versions actuelles de Bitcoin Core intègrent déjà les correctifs des trois failles. Les développements futurs continueront d’améliorer la gestion du mempool, la validation des blocs compacts et le traitement des connexions anonymisées. Les contributeurs travaillent en permanence sur des optimisations et sur le renforcement de la robustesse face à des scénarios d’attaque de plus en plus sophistiqués.

La communauté peut s’attendre à de nouvelles divulgations dans les mois et les années à venir. Certaines concerneront des problèmes découverts récemment, d’autres des failles corrigées il y a longtemps. Chaque publication nourrit la culture de transparence qui caractérise le projet. Elle rappelle aussi que la sécurité est un processus continu plutôt qu’un état définitif.

Les opérateurs avertis suivent déjà les canaux officiels, les listes de diffusion et les dépôts de code. Pour les autres, la publication de novembre 2026 constitue un signal d’alarme utile. Vérifier sa version, planifier une mise à jour et rester informé des prochains avis représente le minimum syndical pour quiconque souhaite contribuer sérieusement au réseau.

Ce Que Cette Divulgation Révèle Sur La Maturité Du Projet

Plus de quinze ans après la naissance de Bitcoin, le logiciel de référence continue d’évoluer et de faire face à des défis techniques. La découverte de failles dans la gestion du mempool ou dans le traitement des blocs compacts ne remet pas en cause les fondations du protocole. Elle montre simplement que même un code largement audité et utilisé par des dizaines de milliers de nœuds peut encore contenir des cas limites.

La capacité de l’équipe à corriger rapidement, à laisser le temps aux utilisateurs de migrer et à documenter ensuite les problèmes témoigne d’une maturité organisationnelle. Dans un domaine où la confiance se construit lentement et se perd rapidement, ces pratiques comptent autant que la qualité technique du code lui-même.

Les trois failles de 2025, désormais publiques, s’ajoutent à la longue liste des enseignements tirés de l’expérience. Elles rappellent aux mineurs l’importance d’un nœud fiable, aux opérateurs Tor la nécessité de configurations correctes, et à l’ensemble de la communauté que la vigilance reste le prix de la décentralisation.

En définitive, cette divulgation du 11 novembre 2026 ne constitue pas une crise. Elle représente plutôt un exercice de transparence et un rappel utile. Les correctifs existent depuis plus d’un an. Les versions à jour protègent déjà les nœuds qui les exécutent. Il ne reste plus qu’à ceux qui trainent encore sur des versions obsolètes de franchir le pas. La sécurité du réseau Bitcoin dépend, une fois de plus, de la responsabilité individuelle de chacun de ses participants.

Les prochains mois diront si cette publication incite un plus grand nombre d’opérateurs à moderniser leurs installations. Dans un écosystème où chaque nœud compte, chaque mise à jour renforce un peu plus la résilience collective. Bitcoin Core continue de prouver qu’il sait gérer ses faiblesses avec méthode. À charge pour les utilisateurs de faire de même de leur côté.