Quand l'IA trouve la faille la première : Bitcoin Core réécrit ses règles de divulgation
Bitcoin Core, le logiciel qui fait tourner la plupart des nœuds du réseau Bitcoin, change sa manière de traiter les vulnérabilités. Avec une modification de sa politique de sécurité adoptée le jeudi 22 octobre 2026, les failles qui peuvent être trouvées avec un effort minimal – par exemple au moyen d'une simple requête à un grand modèle de langage – ne resteront plus sous embargo pendant des mois. Les correctifs seront rétroportés dans toutes les versions maintenues et publiés le plus vite possible, accompagnés d'un avis de sécurité.
Comment fonctionnait la divulgation jusqu'ici
Bitcoin Core classe les vulnérabilités signalées selon leur gravité et cale leur publication sur ce classement. Les failles de faible gravité étaient rendues publiques deux semaines après la version majeure suivante. Celles de gravité moyenne ou élevée restaient sous embargo jusqu'à deux semaines après la fin de support de la dernière version concernée – un délai pouvant atteindre environ un an. L'idée : livrer discrètement le correctif, laisser aux opérateurs de nœuds le temps de mettre à jour, puis n'expliquer le problème qu'une fois la majeure partie du réseau protégée.
Ce qui change
Lors du tri initial, les mainteneurs peuvent désormais classer une vulnérabilité comme « facilement découvrable ». Le critère est l'effort nécessaire pour trouver la faille, et non l'identité de celui qui l'a trouvée : la catégorie couvre donc aussi des signalements sans lien avec l'IA. Pour ces failles, le projet va :
- rétroporter le correctif dans chaque version majeure maintenue,
- publier des versions correctives le plus rapidement possible,
- diffuser, en même temps que le logiciel corrigé, un avis de sécurité contenant certains détails.
Toutes les autres vulnérabilités conservent le calendrier existant, fondé sur la gravité. Les failles critiques – celles qui pourraient permettre le vol de bitcoins au niveau du protocole, gonfler la masse monétaire ou provoquer une scission permanente de la chaîne – restent en dehors de la règle standard et seront traitées au cas par cas.
Pourquoi l'IA a imposé ce changement
Antoine Poinsot, de Chaincode Labs, auteur de la proposition, explique que le projet a reçu de plus en plus de signalements de failles faciles à trouver ou à redécouvrir, principalement parce que les modèles de langage abaissent fortement la barrière pour détecter certaines catégories de bugs ou repérer des correctifs publiés discrètement. Pour ce type de faille, un long embargo ne protège personne : un attaquant disposant des mêmes outils peut trouver la brèche pendant que les utilisateurs attendent encore le correctif.
L'été 2026 a montré à quelle vitesse cela peut arriver. Fin juillet, un groupe bénévole de 16 développeurs, le Bitcoin Red Team, a passé 390 dépôts liés à Bitcoin au crible de modèles d'IA en une journée environ et relevé 4 962 résultats, dont 85 jugés critiques. Quelques jours plus tard, une faille de BTCPay Server signalée en privé par le groupe était exploitée sur des serveurs marchands en production, vidant des nœuds Lightning. En août, les développeurs de Core Lightning ont demandé aux opérateurs de mettre à jour ou de se déconnecter, après que des rapports de bugs générés par IA se sont révélés exacts.
Ironie du sort, la plus grosse perte de l'année provient d'une faille pour laquelle aucune IA n'était nécessaire : un défaut dans le firmware du portefeuille matériel Coldcard, présent depuis 2021, a permis à des attaquants de siphonner 594 BTC en 25 minutes le 30 juillet, les pertes approchant 114 millions de dollars sur quatre vagues. En publiant son correctif, Coldcard a indiqué que l'IA l'avait aidé à repérer d'autres bugs.
Le compromis
Des correctifs plus rapides ont un prix. Antoine Poinsot reconnaît que les mises à jour publiées de cette façon seront moins longtemps testées avant d'arriver chez les utilisateurs. Les détails n'ont pas fait l'unanimité : le chercheur en sécurité Antoine Riard souhaitait conserver la possibilité de livrer un correctif discrètement, sans avis de sécurité. Poinsot a refusé, estimant qu'alerter les utilisateurs sans aucun détail pourrait provoquer des migrations précipitées et inutiles chez des personnes qui ne sont même pas concernées. À ce jour, aucune faille n'a encore été classée selon la nouvelle règle.
Ce que les opérateurs de nœuds devraient faire
- Suivre les avis de sécurité officiels sur bitcoincore.org et la Bitcoin Development Mailing List.
- Installer rapidement les versions correctives : avec la nouvelle règle, une mise à jour peut combler une faille que des attaquants trouveraient tout aussi facilement.
- Télécharger Bitcoin Core uniquement depuis les sources officielles et vérifier signatures et sommes de contrôle.
- Pour Lightning ou BTCPay Server, surveiller aussi les avis propres à ces projets – ce sont eux qui ont été touchés en premier cet été.
Il y a quelques jours à peine, une faille activement exploitée dans le portefeuille Electrum a encore montré à quelle vitesse un bug logiciel peut se traduire par des pertes réelles. Pour les utilisateurs de Bitcoin, mettre ses logiciels à jour n'est plus une corvée : cela fait partie de l'auto-conservation.
Sources
