Bitcoin Core a adopté jeudi 22 octobre 2026 une révision de sa politique de divulgation des vulnérabilités. Le changement répond à la hausse des signalements de failles qui peuvent être redécouvertes rapidement grâce aux grands modèles de langage (LLM). Le projet réduit l’embargo pour ces failles faciles à trouver, au prix d’un temps de test plus court.
🔑 En bref
- Les failles classées « facilement découvrables » donneront lieu à un correctif rétroporté vers toutes les versions majeures encore maintenues, avec un avis de sécurité.
- Une campagne d’audit assistée par IA a enregistré 4 962 constatations, dont 85 qualifiées de critiques.
- Une faille du firmware Coldcard, sans lien avec l’IA, a permis de vider 594 BTC en 25 minutes, soit environ 114 millions de dollars.
- Le compromis principal : des correctifs disponibles plus vite, mais soumis à moins de temps de test.
Une campagne d’audit assistée par l’IA
Le point de départ de la révision est une série d’analyses menées à la fin juillet 2026. Un groupe bénévole de seize développeurs, la Bitcoin Red Team, a fait tourner des modèles d’IA sur environ 390 projets de l’écosystème Bitcoin en un peu plus d’une journée. Le bilan est volumineux : 4 962 constatations, dont 85 qualifiées de critiques.
Toutes ces constatations n’ont toutefois pas été vérifiées. Selon FXStreet, seul environ un cinquième d’entre elles avait été reproduit à ce stade. Les sources disponibles ne précisent pas si les 85 problèmes critiques avaient tous été confirmés. Cette nuance est essentielle : elle sépare un signal d’alerte d’une liste de failles réellement exploitables.
Des incidents concrets
La campagne a été suivie de plusieurs incidents qui ont donné au sujet une dimension très pratique. Le groupe a signalé en privé une faille du serveur BTCPay, ensuite exploitée sur des serveurs marchands en production. Les attaques ont vidé des nœuds Lightning utilisés par des commerçants pour accepter de petits paiements en bitcoin.
Core Lightning, l’une des principales implémentations de Lightning, a demandé à ses opérateurs de se déconnecter après que des rapports de vulnérabilités générés par l’IA, adressés à sa petite équipe, se sont révélés exacts. L’équipe avait alors retenu les détails techniques pendant deux semaines.
| Incident | Date | Impact | Lien avec l’IA |
|---|---|---|---|
| Serveur BTCPay | Juillet 2026 | Nœuds Lightning de marchands vidés | Faille signalée en privé puis exploitée |
| Firmware Coldcard | 30 juillet 2026 | 594 BTC vidés en 25 minutes, environ 114 M$ sur quatre balayages | Non, la faille n’a pas nécessité l’IA ; le fabricant indique qu’elle a aidé à détecter d’autres bugs |
| Core Lightning | Non précisée | Demande de déconnexion des opérateurs | Rapports générés par l’IA, jugés exacts |
Jusqu’ici, Bitcoin Core appliquait une période d’embargo afin de laisser aux opérateurs le temps de mettre à jour leurs logiciels avant la publication des détails techniques. Le correctif pouvait être déployé discrètement, mais la faille elle-même ne devenait publique qu’après la publication de ces détails. Le problème apparaissait lorsque les versions corrigées ne pouvaient pas être rétroportées vers les versions antérieures : les utilisateurs devaient alors attendre la prochaine version majeure, publiée environ tous les six mois.
« La période d’embargo n’apporte que peu de choses, mais elle retarde la disponibilité d’une version corrigée. »
Antoine Poinsot, développeur de Bitcoin Core et Chaincode Labs
Une catégorie « facilement découvrable » et quatre classes de gravité
Antoine Poinsot a proposé la révision après une hausse des signalements de failles faciles à redécouvrir. Selon lui, les LLM réduisent fortement la difficulté de détecter certaines catégories de problèmes, ou d’identifier des corrections cachées dans le code. La nouvelle politique introduit donc une catégorie intitulée « facilement découvrable », qui vise les failles pouvant être trouvées avec un effort minimal, par exemple au moyen d’une simple requête adressée à un LLM.
Le critère retenu porte sur le niveau de difficulté de découverte, et non sur l’outil utilisé. Une faille relève donc de cette catégorie même si elle n’a pas encore été trouvée par une IA. Lorsqu’une vulnérabilité y est classée, Bitcoin Core doit publier, pour chaque version majeure encore maintenue, une version de correction contenant le correctif, dès que possible, ainsi qu’un avis de sécurité. Les correctifs sont donc rétroportés vers toutes les versions actives, sans attendre la prochaine version majeure. L’avis précise certains détails, mais pas nécessairement l’intégralité des informations techniques.
Pour les autres failles, la politique repose toujours sur quatre classes de gravité, dont les délais sont résumés ci-dessous.
| Classe | Périmètre | Exemples cités | Délai de divulgation |
|---|---|---|---|
| Facilement découvrable | Failles trouvables avec un effort minimal | Aucune classée au moment de l’adoption | Correctif et avis dès que possible |
| Critique | Vol de pièces, création hors calendrier, scission permanente | CVE-2018-17144 (déni de service et inflation) | Procédure ad hoc |
| Élevée | Impact significatif, souvent exploitable à distance | CVE-2024-35202, CVE-2024-52914, CVE-2019-25220 | Jusqu’à deux semaines après la fin de vie de la dernière version affectée |
| Moyenne | Dégradation des performances, portée limitée | CVE-2015-20111, CVE-2024-52921, CVE-2024-52922 | Jusqu’à deux semaines après la fin de vie de la dernière version affectée |
| Faible | Difficile à exploiter ou impact limité | CVE-2024-52920, CVE-2024-52917 | Deux semaines après une version majeure contenant le correctif |
La classe critique couvre les menaces pesant sur la sécurité et l’intégrité fondamentales du réseau. Elle ne relève pas du processus standard, car elle nécessite probablement une procédure ad hoc. La classe élevée vise des failles capables de provoquer une interruption généralisée, comme un plantage distant déclenchable ou un blocage de nœud pendant une longue période. La classe moyenne regroupe des failles qui dégradent sensiblement les performances, par exemple une potentielle exécution de code sur le réseau local lorsque la fonctionnalité UPnP est activée, ou des retards de propagation des blocs. Ces derniers pouvaient faire attendre un nœud jusqu’à dix minutes avant de récupérer un bloc auprès d’un autre pair.
Les failles de gravité faible sont difficiles à exploiter ou ont un impact limité. Elles peuvent nécessiter des configurations non standard ou provenir du réseau local. Un message « getdata » mal formé peut, par exemple, provoquer une boucle consommant du CPU sans empêcher le nœud de traiter les blocs.
Les avis historiques montrent que ces sujets ne sont pas nouveaux. Les versions 30.0 (10 octobre 2025) ont corrigé notamment CVE-2025-46597, un plantage distant très improbable sur systèmes 32 bits, et CVE-2025-54604 et CVE-2025-54605, qui permettaient de remplir le disque, respectivement via de fausses connexions à soi-même et via des blocs invalides. D’autres correctifs ont été publiés dans les versions 29.0, 22.0, 0.21.0 et 0.20.0, ainsi que dans des versions plus anciennes.
Compromis et réactions de la communauté
Le principal compromis identifié par les mainteneurs est la réduction des délais de test. Les correctifs destinés aux failles facilement découvrables auront « moins de temps de cuisson » avant d’atteindre les utilisateurs. Antoine Riard, chercheur en sécurité Bitcoin de longue date, souhaitait conserver la possibilité de publier un correctif sans avis officiel et de retenir les détails au cas par cas.
Poinsot a rejeté cette option, en soulignant le risque d’une migration précipitée par des utilisateurs qui ne seraient pas affectés autrement. Alerter sans aucun détail, selon lui, pourrait créer un risque supplémentaire inutilement. Luke de Wolf, animateur du Bitcoin Infinity Show et auteur de « Defending Bitcoin », a résumé l’avis de plusieurs observateurs.
« J’ai désapprouvé l’approche d’Antoine en matière de sécurité dans le passé, mais c’est une bonne mise à jour. »
Luke de Wolf, animateur du Bitcoin Infinity Show
Aucune vulnérabilité n’avait encore été classée dans la nouvelle catégorie au moment de l’adoption. Les sources ne mentionnent aucune variation du cours du bitcoin ni autre réaction de marché liée à cette modification. L’effet attendu porte donc avant tout sur les opérateurs de nœuds, qui recevront plus rapidement un correctif et un avis, y compris lorsqu’ils n’utilisent pas encore la version majeure la plus récente.
Perspectives : une application qui reste à mesurer
La première application concrète de la règle permettra de vérifier comment Bitcoin Core fixe, dans les faits, le seuil de « découverte facile ». Ce point déterminera la portée réelle de la politique : un seuil trop large augmentera le volume de correctifs publiés en urgence, tandis qu’un seuil trop strict laissera certaines failles suivre le processus d’embargo habituel.
Trois scénarios se dessinent. Dans le scénario de base, la rétroportation rapide réduit la fenêtre de vulnérabilité des nœuds qui tardent à migrer, sans accroître fortement les incidents. Dans le scénario défavorable, des acteurs malveillants exploitent des failles trouvées par IA avant que les opérateurs n’aient appliqué les correctifs, surtout si les avis donnent trop d’indices. Dans le scénario favorable, la communauté adapte ses tests et ses outils de revue au nouveau rythme, ce qui compense le temps de cuisson réduit.
Sources
- Cryptoast : Bitcoin Core modifie sa politique de sécurité
- FXStreet : Bitcoin Core changes security policy as AI makes bugs easier to find
- Binance Square : publication sur la politique de sécurité de Bitcoin Core
- Bitcoin Core : security advisories
- Crypto Briefing : Bitcoin Core AI bug disclosure policy
- CoinDesk : Bitcoin will now stop hiding bugs an AI can find in one prompt
Cet article est publié à titre informatif et éducatif. Il ne constitue en aucun cas un conseil en investissement. Faites vos propres recherches (DYOR) avant toute décision.
