Bitcoin Core lève l’embargo : « le mauvais compromis » sur les failles faciles à trouver

Bitcoin Core a modifié les règles selon lesquelles les failles de sécurité du principal logiciel Bitcoin deviennent publiques. Qui signale une faille que l’on peut retrouver sans grand effort ne déclenche plus des mois de silence, mais une version corrective pour chaque version majeure encore maintenue et un avis de sécurité le jour même. La modification a été reprise dans la politique de divulgation sur bitcoincore.org le 22 octobre 2026 à 16 h 06.

Pour vous, détenteur de Bitcoin, ce n’est pas une note marginale venue du monde des développeurs. La politique décide de la vitesse à laquelle une erreur corrigée dans le logiciel vous parvient, et elle décide de l’avance dont dispose un attaquant entre-temps. À environ 81 400 dollars le bitcoin le 23 octobre 2026, c’est la contre-valeur de portefeuilles entiers qui dépend de cette question.

Ce que Bitcoin Core a changé dans sa politique le 22 octobre

Bitcoin Core est le logiciel de référence du réseau Bitcoin. Il vérifie les blocs, conserve la blockchain et contribue à déterminer quelles transactions sont valides. Qui exploite son propre nœud fait tourner, dans la plupart des cas, exactement ce logiciel.

Selon sa propre présentation, la politique distingue quatre classes de vulnérabilités. Ce qui s’y ajoute n’est pas une cinquième classe, mais un attribut transversal : lors du premier examen, Bitcoin Core peut classer une faille signalée comme easily discoverable, c’est-à-dire facile à trouver. Lorsque cet attribut est attaché à un signalement, le délai d’attente jusque-là en vigueur disparaît.

La démarche elle-même est documentée de façon vérifiable. Le développeur Antoine Poinsot a soumis la modification le 16 octobre 2026 sous la forme de la pull request 1281, intitulée « Update security policy for easy-to-find vulnerabilities ». Après quinze commentaires, elle a été fusionnée le 22 octobre par un autre mainteneur de Core. Un seul fichier a été modifié, avec dix lignes ajoutées et une supprimée. Il ne s’agit donc plus d’une proposition, mais de la politique en vigueur.

« Easily discoverable » : le nouvel attribut dans les termes de la politique

Easily discoverable signifie, dans la politique : une vulnérabilité que l’on peut découvrir avec un effort minimal, par exemple au moyen d’une simple requête adressée à un modèle de langage. C’est toute la définition, et elle est volontairement large. Le classement n’est expressément pas limité aux découvertes réellement faites avec un modèle de langage ; la requête simple sert d’étalon pour l’effort, non de prescription sur l’outil.

Lorsqu’un signalement porte cet attribut, la politique prévoit : Bitcoin Core publie pour chaque version majeure maintenue, aussi vite que possible, une version corrective contenant le correctif, accompagnée d’un avis de sécurité, et n’applique pas les délais d’embargo habituels, fonction de la gravité. Une annonce préalable deux semaines avant la publication des détails subsiste, mais seulement pour les failles effectivement sous embargo.

Un an d’embargo face à une version corrective le jour même

Pour mesurer l’ampleur de cette différence, il vaut la peine de regarder les délais qui continuent de s’appliquer à côté. Pour les failles dépourvues du nouvel attribut, rien ne change.

Une vulnérabilité de gravité faible est divulguée deux semaines après la publication d’une version majeure contenant le correctif. En gravité moyenne et élevée, la divulgation n’intervient que deux semaines après que la dernière version concernée a atteint la fin de sa maintenance. La politique chiffre elle-même ce point : environ un an après la première parution d’une version majeure contenant le correctif.

Il en découle la véritable dureté de l’ancienne règle, et la politique la nomme ouvertement. Parce que Bitcoin Core mise sur un long embargo, les correctifs de sécurité ne peuvent en règle générale pas être rétroportés dans des versions plus anciennes. Ils n’atteignent les utilisateurs qu’avec la prochaine grande version. Qui se trouve donc sur une version majeure maintenue, mais pas la plus récente, pouvait rester des mois sans recevoir un correctif.

Antoine Poinsot appelle l’embargo sur les trouvailles faciles le mauvais compromis

Poinsot justifie la démarche par un arbitrage présent dans toute politique de sécurité. Transparence et temps pour mettre à jour tirent dans des directions opposées : l’ouverture place attaquants et défenseurs sur un pied d’égalité, mais elle peut rendre une faille publique avant que les utilisateurs n’aient mis à jour. En raison de la nature du projet et d’une culture de mise à jour lente, Bitcoin Core aurait opté pour l’embargo le plus long.

Pour les erreurs faciles à trouver, cet arbitrage ne tient plus. Poinsot écrit littéralement qu’il s’agit du « wrong tradeoff », du mauvais compromis, et ajoute : « The embargo period achieves little but it delays the availability of a fixed release. » L’embargo n’obtiendrait donc pas grand-chose, mais retarderait la disponibilité d’une version corrigée. Comme motif, il cite une hausse des signalements portant sur des failles aisément redécouvrables, et l’attribue au fait que les modèles de langage abaissent nettement la barre pour trouver certaines catégories d’erreurs ou pour repérer des correctifs dissimulés.

La seconde partie de cette phrase est la plus gênante. Un correctif glissé en silence dans du code ouvert était autrefois difficile à reconnaître comme tel. Si cela se repère de façon automatisée, l’embargo trahit la faille qu’il cherche à masquer.

Les modèles de langage abaissent la barre, et la campagne du red team le montre en chiffres

L’ampleur du déplacement apparaît dans une campagne rapportée par CoinDesk le 23 octobre 2026. Un groupe de bénévoles nommé Bitcoin Red Team, seize développeurs selon ce compte rendu, a fait passer des modèles d’intelligence artificielle sur 390 projets Bitcoin fin juillet 2026, en une journée environ d’après le récit. 4 962 trouvailles ont été consignées, dont 85 classées comme critiques.

Ces chiffres sont des constats bruts et non des failles confirmées, et les comptes rendus de cette campagne divergent ; une version n’évoque qu’un cinquième environ de trouvailles confirmées. Comme ordre de grandeur, le point tient malgré tout : ce qui coûtait autrefois des semaines de travail manuel à un spécialiste tourne aujourd’hui en une nuit et à grande échelle.

Que des dommages en résultent est établi par le même compte rendu. Une vulnérabilité de BTCPay Server, que le groupe avait auparavant signalée de façon confidentielle, aurait été exploitée en quelques jours sur des serveurs marchands en service et a vidé des nœuds Lightning. Core Lightning a demandé à ses exploitants, en août 2026, de couper les connexions, après que des signalements produits par intelligence artificielle adressés à la petite équipe se furent révélés authentiques. L’examen humain reste nécessaire, car une partie des signalements produits par la machine ne décrit finalement aucune vulnérabilité.

Qu’une faille n’ait pas besoin d’être trouvée par un modèle de langage pour coûter cher, un cas du même été le montre. Dans le micrologiciel du portefeuille matériel Coldcard dormait, selon le compte rendu, une erreur présente depuis 2021, par laquelle 594 bitcoins ont été retirés en 25 minutes le 30 juillet ; sur quatre retraits, la perte a atteint près de 114 millions de dollars. Qui veut comparer les modèles des différents fournisseurs et leurs canaux de mise à jour trouvera le panorama dans le comparatif des portefeuilles matériels.

Trois versions majeures sont considérées comme maintenues : 29.x, 30.x et 31.x

« Chaque version majeure maintenue » est le membre de phrase décisif de la nouvelle règle, car il vous dit si une version corrective vous atteint. Bitcoin Core s’en tient ici à un engagement bref : les trois dernières versions majeures sont toujours maintenues, comme l’indique le plan de cycle de vie du projet sur bitcoincore.org.

Il s’agit actuellement de trois états. La version 31.x est parue le 19 avril 2026 et constitue l’édition courante. La version 30.x date du 10 octobre 2025, la version 29.x du 14 avril 2025. La fin de la maintenance est à chaque fois liée aux versions majeures à venir, et non à une date fixe. La version 28.x est sortie de la maintenance le 19 avril 2026 et ne reçoit donc pas non plus de version corrective au titre de la nouvelle règle.

Comment vérifier quelle version de Core fait tourner votre propre nœud

Si vous exploitez votre propre nœud, le numéro de version est la seule indication qui décide de votre situation. Il figure dans l’interface de Bitcoin Core sous la rubrique d’information sur le programme, et en ligne de commande l’appel bitcoin-cli -version le fournit. Si le premier chiffre est inférieur à 29, vous êtes hors maintenance, et aucun des correctifs décrits ici ne vous atteindra.

Deux autres points sont désormais plus importants qu’avant. Premièrement, il vaut la peine de suivre les avis de sécurité du projet, car avis et version corrigée paraîtront désormais le même jour et le délai de préparation manque. Deuxièmement, le temps de réaction s’est raccourci à votre détriment : dès la publication, les détails sont publics, et qui ne met pas à jour continue avec une faille connue. Le même principe vaut pour le portefeuille logiciel installé sur votre ordinateur ou votre téléphone, dont les canaux de mise à jour sont présentés côte à côte dans le comparatif des portefeuilles logiciels.

Pour les détenteurs sans nœud propre, la responsabilité se déplace

La grande majorité des investisseurs en Allemagne n’exploite pas de nœud. Pour eux, la modification agit indirectement, par l’intermédiaire des services qui font tourner Bitcoin Core en arrière-plan. En font partie les plateformes d’échange, les conservateurs, les prestataires de paiement et les serveurs qui se tiennent derrière certaines applications de portefeuille.

Là, la nouvelle règle est d’abord une bonne nouvelle. Un exploitant qui devait jusqu’ici attendre une grande version reçoit maintenant le correctif sous forme de version corrective pour l’état qu’il fait tourner de toute façon. Cela abaisse la barrière à la mise à jour. En même temps, la pression pour le faire vite augmente, puisque les détails de la faille deviennent publics au même moment.

Portefeuilles matériels et plateformes dépendent de la même divulgation

Une réserve s’impose, pour que la portée de cette modification ne soit pas surestimée. Elle concerne Bitcoin Core, pas l’ensemble de la boîte à outils Bitcoin. Portefeuilles matériels, applications de portefeuille, serveurs de paiement et mises en œuvre de Lightning ont chacun leurs propres politiques, et les cas de cet été proviennent pour la plus grande part précisément de ces projets. La question de la rapidité avec laquelle un fournisseur met à jour micrologiciel et application reste une question à poser au fournisseur.

Pour vous, cela signifie : décider si vous conservez vous-même ou faites conserver déplace seulement la charge de la mise à jour. Cela ne supprime pas la tâche. Qui conserve lui-même porte l’entretien des versions du nœud et du portefeuille. Qui laisse ses avoirs chez un conservateur s’en remet à sa technique pour installer rapidement les versions correctives, et troque le contrôle contre la responsabilité d’un tiers.

Un point reste ouvert. Jusqu’au 23 octobre 2026, selon le compte rendu de CoinDesk, aucune faille n’avait été classée au titre de la nouvelle règle. La brièveté réelle de l’expression « aussi vite que possible » n’apparaîtra qu’au premier cas véritable. Poinsot concède lui aussi que de tels correctifs ont moins de temps pour mûrir avant d’atteindre les utilisateurs. Il a en revanche rejeté une proposition visant à renoncer entièrement à l’avis de sécurité : informer les utilisateurs d’une faille sans en nommer les détails pourrait créer un risque supplémentaire inutile.

Bitcoin Core : version corrective et avis arrivent le même jour

1. Relever le numéro de version. Sur un nœud personnel, vérifiez si le premier chiffre est 29, 30 ou 31. S’il est inférieur, passez à un état maintenu. Côté portefeuille, le comparatif des portefeuilles logiciels aide à savoir comment le fournisseur livre ses mises à jour.
2. Mettre à jour le micrologiciel du portefeuille matériel. La faille Coldcard est restée quatre ans dans le micrologiciel selon le compte rendu. Vérifiez quand vous avez mis à jour pour la dernière fois, et comment votre modèle reçoit les mises à jour ; le comparatif des portefeuilles matériels place les fournisseurs côte à côte.
3. Clarifier qui s’en charge. Décidez qui, chez vous, assure la mise à jour. Si une partie de vos avoirs se trouve chez un conservateur, examinez ses indications techniques ; un classement des prestataires figure dans le comparatif des plateformes.

(Au 23 octobre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)