Coldcard : une faille de firmware aurait permis le vol de 89 M$ en BTC

Une faille critique touchant Coldcard, l'un des portefeuilles matériels Bitcoin les plus populaires, a été exploitée pour dérober environ 1'367 BTC (près de 89 millions de dollars) lors de trois vagues d'attaques. Contrairement à une campagne de phishing ou à un piratage d'exchange, l'incident viserait le processus interne de génération des clés : un bug de firmware vieux de cinq ans aurait produit des "seeds" avec une entropie insuffisante, permettant à un attaquant de reconstruire des clés privées hors ligne et de vider les fonds. Chronologie des vols : trois vagues, 1'367 BTC envolés Le 30 juillet 2026, un acteur inconnu a commencé à déplacer des bitcoins depuis des portefeuilles Coldcard. Lors de la première vague, 594 BTC (environ 38 millions de dollars) ont été siphonnés en 25 minutes depuis près de 500 portefeuilles, avec un ciblage prioritaire des soldes les plus élevés. Selon Chainalysis, plus de 30 millions de dollars auraient été collectés durant les 10 premières minutes, et un portefeuille à lui seul aurait perdu environ 1,8 million de dollars. Le même jour, une deuxième vague a porté les pertes à 1'082 BTC (environ 70 millions de dollars) sur 1'196 adresses en 41 minutes. Au 2 août, le cumul atteignait 1'367 BTC (environ 89 millions de dollars) sur 4'585 adresses. L'attaquant ne semble pas avoir frappé au hasard : la sélection des cibles et l'ordre d'exécution suggèrent une préparation préalable et l'identification d'adresses lucratives. Le balayage global s'est poursuivi près de 30 heures avant la première alerte publique de Coinkite. Galaxy Research dit avoir identifié environ 600 adresses suspectées liées à l'attaque et les avoir transmises à des enquêteurs. Le cabinet observe des schémas opérationnels proches pour les vagues 1 et 2, tandis que la vague 3 présente des méthodes de collecte différentes, laissant envisager un second opérateur. Pourquoi cet incident est différent Aucun accès physique aux appareils n'aurait été nécessaire, et il ne s'agirait pas d'une compromission d'exchanges. Le cœur du problème résiderait dans la génération initiale de la seed lors de l'initialisation du portefeuille. Autrement dit, l'outil censé isoler les clés du réseau aurait produit, dans certaines conditions, des clés dérivables à partir d'une randomisation trop faible. La faille de firmware : un changement de code, cinq ans sans être détecté D'après les éléments publiés, un commit du 1er mars 2021 a modifié la fonction de génération de seed : ckcc.rng_bytes (reposant sur le générateur matériel aléatoire du microcontrôleur STM32) a été remplacée par ngu.random.bytes, un PRNG logiciel fondé sur des entrées déterministes. Les sources d'entrée citées incluent le numéro de série de l'appareil, des valeurs de temporisation internes et l'historique des appels RNG. Le firmware applique ensuite un hachage SHA256d ; or, un hachage peut mélanger des données, pas créer de l'aléa absent au départ. Si l'entrée ne propose que 2^40 possibilités, la sortie n'en propose pas davantage. Selon l'avis, les seeds générées sur Mk2/Mk3 à partir de cette période n'auraient offert qu'environ 40 bits d'entropie. Sur Mk4, Mk5 et Q, un élément sécurisé apporterait une entropie additionnelle, portant l'entropie effective autour de 72 bits. Dans les deux cas, cela reste inférieur au niveau de sécurité de 128 bits attendu pour la génération de seeds Bitcoin. Zach Herbert, PDG de Foundation Devices, indique que le bug serait apparu lors d'une réécriture majeure du firmware en mars 2021, destinée à remplacer du code GPL restant et à introduire de nouvelles bibliothèques cryptographiques ; la modification s'inscrirait ainsi dans une refonte de licence plutôt que dans un choix de sécurité. Le bug serait resté présent au fil de cinq ans de mises à jour, de revues de sécurité et d'un audit assisté par IA, sans être détecté. Mode opératoire présumé : brute force de seeds à 40 bits L'attaquant aurait pu reproduire hors ligne le flux de seeds candidates en contraignant des variables telles que l'UID de l'appareil, l'état du timer et la séquence d'appels RNG précédents. Chaque seed candidate permet de dériver des adresses Bitcoin qui peuvent ensuite être comparées aux données publiques de la blockchain. Avec ~40 bits d'entropie, l'espace de recherche est d'environ un trillion de possibilités : massif en apparence, mais atteignable avec des moyens modernes lorsque la recherche est ciblée. Pour Mk4/Mk5/Q, l'entropie annoncée autour de 72 bits demeure inférieure au standard. Block qualifie l'architecture de "dangerous fail-open structure", évoquant des conditions de démarrage pouvant réduire la recherche à 2^32 valeurs. Aucune exploitation à grande échelle de ce point précis n'a été confirmée à ce stade. Quels modèles sont concernés Le risque dépend du firmware utilisé au moment où la seed a été créée, pas du firmware actuel. Mettre à jour l'appareil protège la création de nouvelles seeds, mais ne "répare" pas une seed déjà générée. Périmètre et niveaux de risque (selon les informations communiquées) - Mk2 / Mk3 : seeds générées avec v4.0.0 / v4.0.1 à v4.1.9 ; entropie effective ~40 bits ; correctif v4.2.0+ ; risque le plus élevé, exploitation active signalée. - Mk4 / Mk5 : seeds générées avant v5.6.0 (standard) / avant v6.6.0X (Edge) ; entropie effective ~72 bits ; correctif v5.6.0+ / v6.6.0X+ ; pas de preuve d'exploitation à grande échelle, mais niveau d'entropie inférieur au standard. - Q : seeds générées avant v1.5.0Q (standard) / avant v6.6.0QX (Edge) ; entropie effective ~72 bits ; correctif v1.5.0Q+ / v6.6.0QX+ ; risque résiduel similaire à Mk4/Mk5. Un cas particulier réduit fortement l'exposition : les utilisateurs ayant ajouté au moins 50 lancers de dés indépendants et privés lors de la génération de la seed ont injecté une entropie externe authentique, neutralisant la faiblesse du PRNG. Une passphrase BIP39 robuste complique aussi l'attaque, sans renforcer la seed elle-même ; Coinkite recommande malgré tout de migrer les fonds si la seed a été créée pendant la période vulnérable. Réaction de Coinkite Coinkite a publié ses premiers avertissements de sécurité les 30 et 31 juillet, environ 30 heures après le début du balayage. L'entreprise a diffusé des firmwares corrigés pour les modèles concernés (dont v4.2.0 pour Mk3, v5.6.0 pour Mk4/Mk5 et v1.5.0Q pour Q), une analyse technique et un guide de migration. Le 1er août, l'avis a été élargi pour reconnaître une entropie réduite également sur Mk4, Mk5 et Q. Des critiques persistent : la présence du bug sur cinq ans malgré des revues et un audit récent, ainsi que le délai de communication pendant lequel des utilisateurs n'auraient pas pu agir avant d'être touchés. Le chercheur Kevin Loaec (Wizardsardine) estime en outre que les configurations multisig incluant des clés issues de seeds Coldcard affectées doivent être considérées comme exposées, point que l'avis de Coinkite ne traiterait pas complètement. Que faire si votre seed est potentiellement concernée Une simple mise à jour de firmware ne sécurise pas un portefeuille existant si la seed a été générée avec une entropie faible. La démarche recommandée consiste à créer une nouvelle seed sur firmware corrigé, puis à déplacer les fonds. Processus de migration (recommandations Coinkite / guides cités) 1) Mettre à jour le firmware vers la version corrigée correspondant à votre modèle et à votre canal de release, en le téléchargeant depuis le site officiel Coinkite. 2) Générer une nouvelle seed sur l'appareil mis à jour (ne pas restaurer l'ancienne). Ajouter, si possible, au moins 50 lancers de dés indépendants et privés. 3) Vérifier la sauvegarde de la nouvelle seed et contrôler qu'une adresse de réception affichée par le logiciel correspond à celle affichée à l'écran du Coldcard. 4) Transférer l'intégralité des BTC depuis les anciennes adresses vers des adresses dérivées de la nouvelle seed, en vérifiant l'adresse de destination et les détails sur l'appareil avant signature. 5) Confirmer on-chain la migration (explorateur fiable), s'assurer que les anciennes adresses sont à zéro et que le nouveau portefeuille reflète le solde transféré. 6) Détruire de manière sécurisée toute copie de l'ancienne seed uniquement après confirmation et vérification de l'accès à la nouvelle. Les migrations impliquent des frais on-chain ; en contexte d'urgence, éviter des frais trop faibles qui ralentiraient la confirmation. Cas multisig : chaque clé dérivée d'une seed Coldcard affectée doit être remplacée. Il faut revoir le seuil de signature, faire tourner les clés vulnérables et valider la nouvelle configuration multisig avant de déplacer des montants significatifs. Impact plus large sur la self-custody L'épisode rappelle que la sécurité de l'auto-garde repose sur deux piliers : contrôler ses clés et s'assurer que leur génération repose sur une entropie de haute qualité. Ces dernières années, plusieurs incidents liés à des PRNG défaillants ont touché l'écosystème, dont Milk Sad (2023) et Ill Bloom (2026). Dans ces scénarios, l'interface peut afficher une seed valide et produire des adresses fonctionnelles, tout en reposant sur un aléa sous-jacent insuffisant, difficile à vérifier par l'utilisateur. L'affaire relance aussi le débat sur l'open source : le code du firmware Coldcard est consultable, sans pour autant que cela ait empêché un bug de rester invisible pendant cinq ans. La transparence ne garantit pas la sécurité, mais elle reste un prérequis pour l'audit communautaire. CoinDesk indique que ce type de risque opérationnel pourrait pousser certains investisseurs vers des ETF Bitcoin, qui éliminent la gestion des clés au prix d'une dépendance à un dépositaire régulé : le risque de garde n'est pas supprimé, il est transféré. Blockaid note aussi qu'au premier semestre 2026, la majorité des pertes crypto proviendraient de clés compromises et de défaillances opérationnelles plutôt que d'exploits de smart contracts. Dans ce contexte, l'incident Coldcard s'inscrit dans une tendance où l'attaque vise la génération et la protection des clés, pas Bitcoin lui-même. Questions clés - Mon Coldcard est-il compromis ? Risque élevé si vous avez généré une seed sur Mk2/Mk3 avec les firmwares v4.0.0 à v4.1.9 sans l'apport d'au moins 50 lancers de dés. Pour Mk4/Mk5/Q, les seeds générées avant correctifs auraient ~72 bits d'entropie ; pas d'exploitation massive confirmée, mais niveau inférieur au standard. - La mise à jour du firmware suffit-elle ? Non. Elle corrige la génération future, pas une seed déjà créée. Il faut générer une nouvelle seed et migrer les fonds. - Ledger et Trezor sont-ils concernés ? Non. Ledger, Trezor et Block (Bitkey) indiquent utiliser des systèmes de génération d'entropie différents ; cette vulnérabilité spécifique ne les affecterait pas. - Combien a été volé ? Au 2 août 2026 : environ 1'367 BTC (près de 89 millions de dollars) sur trois vagues, touchant 4'585 adresses. Les chiffres pourraient évoluer au fil de l'enquête. - Qui est l'attaquant ? Non identifié. Galaxy Research estime que les vagues 1 et 2 pourraient relever du même opérateur, la vague 3 présentant un comportement on-chain différent. Environ 600 adresses suspectées ont été signalées aux enquêteurs. - Les lancers de dés protègent-ils ? Oui, à condition d'avoir utilisé au moins 50 lancers indépendants et privés lors de la génération : cette entropie externe authentique ne peut pas être réduite par le PRNG défaillant. Ce contenu est fourni à des fins d'information et d'éducation et ne constitue pas un conseil financier, d'investissement, juridique ou de sécurité. Effectuez vos propres vérifications avant toute décision liée aux cryptoactifs.