La politique de sécurité de Bitcoin Core compte désormais une voie rapide pour les failles faciles à trouver. Selon une modification fusionnée le jeudi 22 octobre 2026 dans le logiciel de référence pour faire tourner un nœud Bitcoin, une vulnérabilité que l’équipe classe comme « facilement détectable » sera corrigée en même temps dans toutes les versions maintenues, et ses détails seront publiés dans un avis de sécurité avec les versions corrigées, sans embargo (un délai de non-divulgation) lié à sa gravité. Le changement est passé par la pull request n° 1281 du dépôt du site du projet, ouverte le 16 octobre par Antoine Poinsot (darosior sur GitHub) et fusionnée par le mainteneur fanquake.
La nouvelle page de la politique de sécurité de Bitcoin Core donne le critère en une ligne : les vulnérabilités « qui peuvent être découvertes avec un effort minimal, par exemple au moyen d’un simple prompt adressé à un LLM ». Si un modèle de langage peut mettre un attaquant sur la piste du bug, le garder secret pendant des mois n’apporte pas grand-chose.
pool di un market maker automatico divergono, rispetto a tenere semplicemente gli stessi token. Diventa definitiva al prelievo.">Il s’agit d’un changement de procédure. Il n’annonce ni une faille, ni un exploit, ni une faiblesse de la cryptographie de Bitcoin, et aucun bitcoin n’est menacé. Rien ne change aujourd’hui pour les détenteurs de bitcoins. Pour ceux qui font tourner un nœud, c’est la manière dont les correctifs arriveront qui change.
Ce qui change dans la politique de sécurité de Bitcoin Core
Antoine Poinsot a expliqué son raisonnement dans un e-mail à la liste de diffusion bitcoin-dev le 22 octobre, jour de la fusion. Il y écrit que le projet reçoit de plus en plus de signalements de vulnérabilités faciles à trouver ou à redécouvrir, et il en attribue la cause aux modèles de langage : ils rendent certaines familles de bugs bien moins coûteuses à repérer, et facilitent aussi la détection des correctifs discrets, ces patchs intégrés sans être présentés comme du travail de sécurité. La divulgation, soutient-il, est toujours un arbitrage : publier les détails aide les défenseurs à suivre le rythme des attaquants, tandis qu’attendre laisse aux utilisateurs le temps de mettre à jour.
D’après l’e-mail, l’approche suivie jusqu’ici penchait pour un long embargo, parce que beaucoup d’opérateurs de nœuds mettent à jour lentement. L’effet secondaire : les correctifs ne pouvaient souvent pas être rétroportés vers les anciennes versions (le « backport » consiste à appliquer le même correctif à des branches plus anciennes) et n’arrivaient qu’avec la version majeure suivante. Pour les bugs que tout le monde peut trouver, Antoine Poinsot parle d’un « mauvais compromis ». Sa conclusion est sans détour : « L’embargo ne sert pas à grand-chose, sinon à retarder la disponibilité d’une version corrigée. »
Le mécanisme tient en quelques lignes. Pendant le tri des signalements, l’équipe peut marquer un bug comme facilement détectable. Un bug ainsi marqué reçoit un correctif rétroporté vers toutes les versions majeures maintenues, ces versions correctives sortent dès que possible, et un avis de sécurité donnant certains détails du problème est publié avec elles. L’e-mail cite le cas du « simple prompt adressé à un LLM » comme exemple de ce qui devrait entrer dans la catégorie, et précise qu’elle ne s’y limite pas.
Les niveaux de gravité restent inchangés
Tout le reste de la politique s’applique toujours aux bugs qui ne sont pas marqués. Les signalements sont classés en quatre niveaux, chacun avec son propre délai de divulgation. La page actuelle les présente ainsi.
| Gravité | Ce que recouvre le niveau (selon la page de la politique) | Quand les détails sont publiés |
|---|---|---|
| Faible | Difficile à exploiter, ou impact mineur | 2 semaines après la sortie de la version majeure qui contient le correctif |
| Moyenne | Dégrade nettement les performances ou le fonctionnement, nécessite souvent des réglages non standard | 2 semaines après que la dernière version concernée atteint sa fin de vie |
| Élevée | Impact important sur les nœuds ou le réseau, en général exploitable à distance sur une configuration par défaut | 2 semaines après que la dernière version concernée atteint sa fin de vie |
| Critique | Menace le réseau lui-même : vol de coins au niveau du protocole, création de coins hors du calendrier d’émission, scission permanente de la chaîne à l’échelle du réseau | Hors de la politique standard ; très probablement une procédure ad hoc |
| Tout niveau, si marqué facilement détectable (nouveau) | Peut être trouvé avec un effort minimal, par exemple par un simple prompt adressé à un LLM | Avec les versions correctives, dès que possible, sans embargo lié à la gravité |
Pour les bugs de gravité moyenne et élevée, attendre que la dernière version concernée atteigne sa fin de vie revient à environ un an après la sortie de la version majeure qui contient le correctif. Une pré-annonce, qui indique le nombre de vulnérabilités corrigées et leur gravité, intervient deux semaines avant la publication des détails sous embargo et coïncide avec une nouvelle version majeure. La page note aussi que certains problèmes signalés peuvent être graves sans nécessiter d’embargo, et que certains signalements ne sont finalement pas des vulnérabilités.
La modification fusionnée est modeste. Elle ajoute deux paragraphes à la page, au-dessus des calendriers existants, et change une expression : la pré-annonce s’applique désormais à « une vulnérabilité sous embargo » plutôt qu’à toute vulnérabilité. Les lignes qui fixent les délais des niveaux faible, moyen et élevé n’ont pas été touchées. Une version japonaise de la page a été mise à jour le 23 octobre.
Pourquoi le secret vaut moins quand une IA peut trouver le bug
Un embargo se justifie quand seuls le découvreur et les mainteneurs connaissent la faille. Il se justifie bien moins quand n’importe qui, avec un agent conversationnel et le code source public, peut trouver la même chose sans effort. C’est le cœur de l’argument qu’Antoine Poinsot a défendu dans la discussion de la pull request entre le 16 et le 22 octobre : corriger discrètement un bug facile ne sert à rien, puisqu’« un simple scan par LLM » peut le faire remonter de toute façon, et rétroporter le correctif vers d’anciennes branches le trahirait.
La ligne de base, a-t-il dit dans la discussion, reste d’éviter d’attirer l’attention inutilement sur les correctifs de sécurité, avec plus de latitude pour s’en écarter. Des correctifs publiés aussi vite bénéficient de moins de temps de test dans les branches de développement ; il s’attend donc à ce que l’équipe accepte un patch plus simple qui révèle le bug si c’est plus sûr, plutôt qu’un patch déguisé qui pourrait casser autre chose.
Les relecteurs ont discuté des détails plutôt que de l’idée. stickies-v a demandé que le texte soit intégré à la rédaction existante plutôt que greffé à la fin, ce qu’Antoine Poinsot a fait le 22 octobre. Le même relecteur craint que les attaquants puissent désormais surveiller le dépôt à peu de frais : une pull request publique de correctif pourrait alerter beaucoup d’entre eux des jours ou des semaines avant que la plupart des utilisateurs en entendent parler. Il a suggéré de divulguer au plus tard à l’ouverture de cette pull request. sedited doutait qu’une divulgation aussi précoce doive être inscrite dans la politique, préférait trancher ces cas au coup par coup, et jugeait qu’étiqueter les pull requests de correctif comme relevant de la sécurité dès leur ouverture n’aiderait pas non plus.
ariard a proposé une section « Derogatory Process » à part, une voie accélérée où un avis pourrait ou non être publié avec le correctif. Antoine Poinsot y a vu « une mauvaise idée » : une alerte sans détails pourrait pousser des utilisateurs non concernés à une mise à jour précipitée. Son exemple est un bug dans la création de modèles de blocs, où les mineurs doivent mettre à jour tout de suite alors que les commerçants peuvent procéder plus prudemment. Pour les bugs assez graves pour prévenir les utilisateurs avant tout correctif, il renvoie au niveau critique, déjà traité au cas par cas. Quatre relecteurs, stickies-v, instagibbs, murchandamus et fanquake, ont approuvé le texte final, et fanquake l’a fusionné.
Aucune réponse n’était visible sous le message d’Antoine Poinsot sur la liste de diffusion quand Coindaro l’a consulté le 23 octobre.
Failles trouvées par l’IA dans les logiciels bitcoin : un an d’épisodes
Le changement fait suite à une série d’épisodes survenus en 2026, où des outils automatisés, souvent assistés par l’IA, ont fait remonter des failles plus vite que les projets ne pouvaient les trier.
Le 6 août, un groupe de bénévoles se faisant appeler Bitcoin Red Team a fait état de 4 962 problèmes potentiels dans 390 projets lors de ses premières 29,8 heures de travail environ, selon Cointelegraph. Environ 720 étaient jugés élevés ou critiques, et 21,4 % avaient été reproduits à ce stade. Les 16 bénévoles, parmi lesquels le directeur général d’AnchorWatch Rob Hamilton et le développeur connu sous le nom de Calle, associaient des outils d’IA à une relecture humaine. Cointelegraph ne dit pas si les dépôts de Bitcoin Core figuraient parmi les projets analysés.
Core Lightning a dû y faire face directement. En août, Core Lightning a indiqué traiter un grand nombre de signalements de vulnérabilités générés par IA et a publié la version 26.06.7. La 26.06.8 a suivi le 22 septembre, avec des correctifs pour des plantages qu’un expéditeur pouvait provoquer, un épuisement de la mémoire via l’interface REST et un bug de fermeture de canal pouvant coûter des fonds par le biais d’une pénalité. Le 2 octobre, l’équipe a averti que des nœuds en 26.06.7 ou plus ancien étaient visés et a demandé aux opérateurs de passer à la dernière version, a rapporté Cointelegraph ; certains tests ont été volontairement retenus.
Les portefeuilles matériels ont aussi eu leur part. Les vols de Coldcard, qui ont commencé le 30 juillet et sont attribués à un générateur de nombres aléatoires logiciel faible dans certains appareils, font maintenant l’objet d’une action collective proposée contre Coinkite en Ontario. Aucun de ces cas ne tenait à un bug de Bitcoin Core lui-même.
Quelles versions de Bitcoin Core reçoivent les correctifs
La promesse de rétroportage ne couvre que les versions maintenues. Bitcoin Core maintient les trois dernières versions majeures, selon sa page sur le cycle de vie des versions, et les versions arrivées en fin de vie ne reçoivent en général aucun correctif de sécurité. Au 23 octobre 2026, cela donne :
| Version majeure | Première sortie | Fin de vie |
|---|---|---|
| 31.x | 19 avril 2026 | Après la sortie de la v34.0 |
| 30.x | 10 octobre 2025 | Après la sortie de la v33.0 |
| 29.x | 14 avril 2025 | Après la sortie de la v32.0 |
| 28.x | 2 octobre 2024 | Terminée le 19 avril 2026 |
Le projet vise une version majeure tous les six à sept mois, et la date de sortie de la 32.0 n’a pas été annoncée ; la page du cycle de vie indique déjà la 32.x comme prise en charge jusqu’à la sortie de la 35.0. À sa sortie, la 29.x ne sera plus maintenue et quittera la voie rapide.
Que peuvent faire dès maintenant les opérateurs de nœuds Bitcoin
Les pages du projet donnent les gestes concrets. Aucun n’est nouveau, mais le changement de politique les rend plus importants, car un bug facile pourrait désormais être public le jour même où sort son correctif.
- Faire tourner une version majeure maintenue (31.x, 30.x ou 29.x), de préférence la dernière version corrective de la plus récente que vous pouvez utiliser. Les nœuds en 28.x ou plus ancien sont en fin de vie et ne reçoivent en général aucun correctif de sécurité.
- Suivre les annonces du projet et la page des avis de sécurité, pour qu’une version corrective publiée hors calendrier ne passe pas inaperçue.
- Télécharger les versions uniquement sur bitcoincore.org et vérifier les signatures ; le projet affirme que ses binaires sont compilés de façon déterministe et signés.
- Pour mettre à jour, arrêter complètement le nœud et installer la nouvelle version par-dessus l’ancienne, comme le décrivent les notes de version.
- Les opérateurs Lightning qui utilisent Core Lightning doivent être sur la dernière version (26.06.8 ou plus récente), à la suite de l’avertissement de l’équipe du 2 octobre.
La politique ne dit pas combien de bugs entreront dans la nouvelle catégorie. Chaque bug marqué suppose une version corrective pour chaque branche maintenue : ceux qui attendent la prochaine version majeure pour mettre à jour seront les premiers exposés.
Embargo, backport et version corrective : le vocabulaire en clair
Les projets open source traitent en général les bugs de sécurité par divulgation coordonnée. Le découvreur prévient les mainteneurs en privé, le correctif est préparé, et les détails sont gardés secrets (c’est l’embargo) jusqu’à ce qu’assez d’utilisateurs aient mis à jour. Plus l’embargo est long, plus il y a de nœuds corrigés avant que les attaquants sachent quoi chercher.
Un backport est le même correctif appliqué aux branches plus anciennes qui sont encore maintenues : un utilisateur de la 29.x n’a donc pas à passer à la 31.x pour être protégé. Une version corrective (« point release »), comme la 31.1, est une petite mise à jour d’une version majeure existante. Avec la nouvelle règle, un bug facilement détectable produit une série de versions correctives sur chaque branche maintenue, et un avis qui explique ce qui a été corrigé. Notre guide sur les endroits où se produisent vraiment les piratages crypto explique pourquoi les bugs logiciels autour d’une blockchain pèsent en pratique plus lourd que les attaques contre la chaîne elle-même.
Questions ouvertes : qui décide de ce qui est facile à trouver
La politique laisse la décision à l’équipe pendant le tri, et ni la page ni l’e-mail ne définissent « facilement détectable » au-delà de l’exemple du LLM. Plusieurs points restaient inconnus le 23 octobre :
- Comment la classification sera décidée dans les cas limites, et si l’auteur du signalement pourra la contester.
- Combien de bugs signalés ont été placés dans la nouvelle catégorie jusqu’ici. Aucun avis n’a encore été publié selon cette règle.
- Si les découvertes de la Bitcoin Red Team en août ont touché les dépôts de Bitcoin Core.
- Comment la crainte des relecteurs, qu’une pull request publique de correctif alerte les attaquants, sera gérée en pratique.
La prochaine date à surveiller est la publication du premier avis selon la nouvelle règle, puis la sortie de la 32.0, qui mettra fin à la prise en charge de la 29.x. Cette semaine, la course entre analyse et correctif s’est aussi jouée autour de deux failles critiques de PHP que des attaquants sondent, même si aucune plateforme crypto n’a été montrée comme touchée.