Le Bitcoin Red Team achève son premier scan de l'écosystème open source et fait état de 7 958 signalements

Le 13 août, le coresponsable du Bitcoin Red Team, Calle (@callebtc), a déclaré que le groupe avait terminé une première passe sur la quasi-totalité du code open source public de Bitcoin. Dans un message publié sur X, il a indiqué que l'initiative avait pour l'essentiel achevé un scan de base de la quasi-totalité de l'open source de Bitcoin et que les problèmes les plus faciles à trouver étaient désormais épuisés. Il a résumé ce que le groupe avait constaté en des termes sans détour : « tout est cassé, Bitcoin brûle ».

Calle a précisé clairement que cette phrase ne décrit pas le protocole Bitcoin lui-même. Il visait l'écosystème logiciel plus large bâti autour de Bitcoin, qui comprend les portefeuilles matériels et logiciels, les bibliothèques cryptographiques, les implémentations Lightning, les outils de paiement et des centaines de projets open source plus petits. Le Bitcoin Red Team est un groupe de bénévoles qui utilise les modèles d'IA actuels pour examiner ce code à la recherche de failles de sécurité avant que les attaquants ne le fassent. La question plus large, celle de savoir pourquoi l'IA a déplacé aussi vite l'équilibre entre attaquants et défenseurs, fait l'objet d'une analyse distincte.

Ce que le groupe signale

Avec la mise à jour du 13 août, le groupe a fait état de 7 958 signalements potentiels sur 501 projets, dont 1 280 classés comme critiques ou de gravité élevée. Selon ce qui a été rapporté à propos de cette mise à jour, environ un quart des signalements avait été reproduit de façon dynamique et un peu moins d'un tiers avait été communiqué aux mainteneurs concernés.

Les premiers chiffres largement diffusés étaient arrivés environ une semaine plus tôt. Dans un message du 5 août, Calle a indiqué que l'équipe était passée à 16 collaborateurs répartis dans le monde entier et actifs 24 heures sur 24, et qu'elle avait déposé 4 962 signalements sur 390 projets au cours des 27,5 premières heures, dont 85 problèmes critiques et 635 de gravité élevée. Le groupe est codirigé par Calle, mainteneur de l'application Bitchat pour Android, et par Rob Hamilton, directeur général d'AnchorWatch, et il est financé par l'organisation à but non lucratif open source OpenSats. À ce stade, il avait dépensé plus de 40 000 dollars en jetons de modèles d'IA.

Le principal modèle derrière le scan est Kimi K3, un modèle à poids ouverts publié par le laboratoire chinois Moonshot AI. Calle a décrit la situation comme une collision massive entre des décennies de code open source humain bâclé et deux semaines de Kimi K3. L'équipe s'est aussi appuyée sur d'autres modèles au cours de la campagne.

Un signalement n'est pas encore un bug confirmé

Le chiffre de 7 958 n'équivaut pas à 7 958 vulnérabilités confirmées. Les modèles d'IA produisent des problèmes suspectés, et chacun doit être reproduit et trié avant de compter comme une faille réelle et exploitable. Certains problèmes suspectés se révèlent exploitables. D'autres reposent sur des hypothèses fausses, se trouvent sur des chemins de code inaccessibles ou sont tout simplement surévalués par le modèle.

Calle a indiqué que des mainteneurs de plusieurs projets avaient déjà validé un certain nombre de problèmes critiques et de gravité élevée. Combien tiendront au bout du compte reste incertain. Le groupe garde les détails techniques confidentiels jusqu'à ce que les projets concernés publient des correctifs.

Calle a désigné Lightning comme la zone la plus touchée. Il l'a décrite comme plus dégradée que la moyenne et particulièrement difficile à examiner, ce qu'il a attribué à sa complexité. Il n'a pas nommé d'implémentations précises, invoquant le risque d'orienter les attaquants vers du code non corrigé.

L'écosystème plus large réagit déjà

Plusieurs services liés à Lightning se sont heurtés à des attaques assistées par IA ces derniers jours. Le 3 août, le fournisseur de swaps non custodial Boltz a suspendu son service de swaps pour une durée indéterminée, affirmant que les attaquants itèrent désormais plus vite qu'une équipe de sa taille ne peut détecter et corriger. Boltz a souligné qu'aucun fonds d'utilisateur n'était en danger, car ses swaps sont protégés par des contrats hashed timelock, et que les pertes n'étaient que les siennes. Ses fondateurs se retirent et un groupe non identifié a accepté de reprendre le service. Le 10 août, Blockstream a lancé une bêta publique de son propre service de swaps, Blockstream Swaps.

Le logiciel de paiement auto-hébergé a lui aussi été touché. Le 8 août, BTCPay Server a publié une version d'urgence 2.4.2 pour combler une faille de contournement d'authentification activement exploitée qui servait à vider les nœuds Lightning connectés, en invitant les opérateurs à mettre à jour ou à éteindre. Une version candidate 2.4.3 ultérieure a traité d'autres problèmes signalés par les chercheurs du Bitcoin Red Team et leurs collaborateurs.

L'exploit Coldcard a préparé le terrain

La campagne a pris forme après l'exploit du portefeuille matériel Coldcard, fin juillet. Une faiblesse dans la manière dont certains firmwares Coldcard généraient des nombres aléatoires a laissé certains portefeuilles avec bien moins d'entropie qu'annoncé dans la graine qu'ils produisent, ce qui a permis à un attaquant de reconstituer les clés privées. Le vol a commencé le 30 juillet et a d'abord vidé environ 1 083 bitcoins, valant à l'époque près de 70 millions de dollars. Au 10 août, le total signalé avait grimpé à plus de 2 000 bitcoins. Coinkite, le fabricant de Coldcard, a reconnu qu'un attaquant avait pu utiliser l'IA pour inspecter son firmware open source.

Le secteur demande aux laboratoires d'IA un accès plus précoce

Le 10 août, le Bitcoin Policy Institute a publié une lettre ouverte, signée par plus de 40 organisations, qui demande aux principaux développeurs d'IA d'accorder à des chercheurs en sécurité open source vérifiés un accès précoce à leurs modèles les plus performants, ainsi qu'une puissance de calcul suffisante, des environnements de recherche sécurisés et des liens directs avec les équipes de sécurité des laboratoires. Parmi les signataires figurent Block, Coinbase, Strategy, MARA, Galaxy, BitGo, Brink, OpenSats, Chaincode Labs, Spiral, Trezor, Unchained, Btrust et Fedi. « Les dernières semaines en ont rendu la nécessité parfaitement claire », a écrit l'institut.

Calle s'est aussi adressé directement aux chercheurs en sécurité. Il a soutenu que quiconque trouve une faille devrait la signaler en privé et laisser aux mainteneurs assez de temps pour la corriger, et il a qualifié d'irresponsable le fait de se vanter publiquement de signalements non corrigés ou d'identifier les projets concernés sur X. Il a également dit que les projets sans mainteneurs joignables devraient être considérés comme non sûrs et que les utilisateurs devraient cesser de se fier à des logiciels abandonnés.

Bitcoin Core lui-même n'est pas en cause

Rien de tout cela ne pointe vers une faille dans le protocole Bitcoin ni dans Bitcoin Core, le logiciel de référence qui fait tourner le réseau. En novembre 2025, la société de sécurité Quarkslab a réalisé le premier audit public par un tiers de Bitcoin Core, commandé par l'organisation à but non lucratif Brink, et n'a trouvé aucun problème critique ou de gravité élevée dans les domaines examinés, qui comprenaient la communication pair-à-pair, la mempool et des parties de la gestion du consensus. Cela ne prouve pas que le logiciel est sans défaut, mais cela trace une ligne nette entre Bitcoin Core et les centaines de projets indépendants que le Red Team examine, qui vont d'équipes vastes et bien dotées à des outils entretenus par une ou deux personnes sur leur temps libre.

Calle a dit que le premier scan large est désormais en grande partie terminé. Le travail à venir, selon lui, consiste à vérifier les problèmes signalés, à les corriger et, à terme, à en publier les détails une fois les correctifs en place.