Le 30 juillet 2026 à 1 h 10, heure UTC, un événement étrange s’est produit sur la blockchain Bitcoin.

1 196 adresses, en seulement 41 minutes, vidées une à une comme des épis de blé par le même attaquant inconnu. 1 082,65 bitcoins — à l’époque d’une valeur de plus de 70 millions de dollars — transférés discrètement sur la portée de 6 blocs. Aucune alerte n’a été déclenchée par un seul portefeuille matériel, aucun utilisateur n’a reçu d’avertissement.

Et à ce moment-là, il restait encore 30 heures avant que ColdCard ne publie officiellement un avertissement de sécurité.

Ce n’est pas une attaque informatique ordinaire. L’attaquant n’a ni mené d’hameçonnage, ni recouru à l’ingénierie sociale, ni effectué d’implantation dans la chaîne d’approvisionnement. Il n’a même pas besoin de toucher votre appareil. Il lui suffit d’être devant un ordinateur et, comme pour résoudre un problème de mathématiques, de « calculer » votre clé privée.

Au 2 août, selon le dernier suivi on-chain de Galaxy Research, les trois vagues d’attaque ont au total balayé 1 367,05 bitcoins, impliquant 4 585 adresses, pour une perte totale d’environ 88,6 millions de dollars.

C’est une bombe à retardement enfouie depuis 5 ans et 4 mois, qui a enfin explosé au cours de l’été 2026.

Une bombe enfouie depuis cinq ans

L’histoire commence en mars 2021.

À l’époque, le développeur de ColdCard, Coinkite, faisait une mise à niveau technique qui ressemblait à quelque chose de tout à fait ordinaire : intégrer la bibliothèque de chiffrement libsecp256k1 de Bitcoin Core dans son firmware. Dans un commit du 1er mars (commit b18723dd), ils ont transféré le chemin de génération des graines de portefeuille vers la bibliothèque libngu.

Personne n’a remarqué qu’au cours de cette migration, une erreur de configuration fatale a été enterrée.

Dans les fichiers d’en-tête au niveau carte de ColdCard, il y a une ligne de code : #define MICROPY_HW_ENABLE_RNG (0). L’intention de cette ligne est de dire à MicroPython : « N’utilise pas ton propre générateur matériel de hasard ; j’en ai un à moi. » Mais le problème vient de la manière dont libngu effectue le contrôle : il utilise un #ifndef pour vérifier si cette macro « existe », au lieu de vérifier si sa valeur est « non nulle ».

Pour faire une analogie : c’est comme une porte avec un cadenas à code. Le système ne fait que vérifier « as-tu saisi un mot de passe ? », sans se soucier de savoir si vous avez saisi « 123456 » ou une chaîne vide. Le macro est définie, mais la valeur est 0 — autrement dit, ce n’est pas verrouillé.

Ainsi, lorsque l’utilisateur génère un nouveau portefeuille sur ColdCard, l’opération qui devrait être fournie par le générateur matériel de hasard véritable (TRNG intégré au chip STM32) pour fournir l’entropie a glissé discrètement vers un générateur pseudo-aléatoire logiciel appelé Yasmarang. Alors, d’où vient la graine de Yasmarang ? Du numéro de série du chip, du minuteur système et du registre d’horloge temps réel.

En clair, votre clé privée « aléatoire » est construite à partir du numéro de série de l’appareil et d’un horodatage.

Ce n’est pas de l’information secrète. Le numéro de série est un métadonnée figée en usine, la valeur de l’horloge est un état mesurable pouvant être déduit à partir d’appareils du même modèle. Pour un attaquant disposant de suffisamment de puissance de calcul, ces informations sont la clé qui ouvre votre portefeuille.

Le 17 mars, le firmware v4.0.0 contenant ce chemin vulnérable a été publié officiellement. À partir de là, sur chaque appareil Mk3 qui génère des graines avec cette version de firmware, l’entropie du portefeuille n’est qu’environ de 40 bits — au lieu des 128 bits promis par la norme BIP-39.

Quelle est la différence entre 128 bits et 40 bits ? 128 bits signifie 2^128 possibilités. Même si on additionne tous les ordinateurs du monde jusqu’à la mort thermique de l’univers, on ne pourrait pas toutes les énumérer. 40 bits signifie environ 1 000 milliards de possibilités — que les ordinateurs modernes peuvent parcourir en quelques heures.

La bombe est restée là, silencieuse dans le firmware : cinq ans durant, sans bouger.

Pendant cette période, Coinkite a publié plusieurs mises à jour du firmware, sans jamais toucher à ce problème. En mars 2022, ils ont ajouté pour Mk4 une API de re-seeding de 32 bits, lisant l’entropie depuis des éléments de sécurité et « améliorant » le hasard — mais en ne conservant qu’un résumé de 4 octets. 4 octets, 32 bits : le plafond reste fixé à environ 4,29 milliards de possibilités. Un cluster de GPU ordinaire peut le parcourir par force brute en quelques jours.

En 2026, Coinkite a même utilisé « l’un des meilleurs modèles d’IA » pour effectuer une revue de code de son firmware. L’IA a dit : « Aucun problème sérieux trouvé. »

Moisson en 41 minutes

30 juillet 2026, à 1 h 10 du matin, heure UTC.

Sur la blockchain Bitcoin, un lot d’adresses dormantes depuis des années se sont soudainement mises à être actives en même temps. Les analystes on-chain de Galaxy Research ont ensuite retracé que ces adresses avaient été créées entre 2021 et 2026 — presque parfaitement aligné avec la durée de vie des firmwares vulnérables. La durée médiane d’inactivité des adresses touchées est d’environ 3,5 ans, ce qui correspond entièrement aux comportements de conservation à froid à long terme.

L’attaque suit un rythme. 1 324 sorties de bitcoins indépendantes sont dispersées et regroupées dans 500 transactions, complétées dans une fenêtre de 3 blocs. Mais au milieu, 3 blocs entiers sans aucune activité de balayage — ce qui montre que les transactions sont diffusées par lots, et non en flux continu.

Le critère le plus crucial, c’est la « signature de caractéristique » : les frais. Chaque transaction de balayage encode exactement les mêmes 30,0 sat/vB de frais. Ce chiffre représente 30 à 75 fois la médiane de la semaine (environ 0,4 à 1,0 sat/vB), et toutes les transactions n’ont aucune sortie de changement.

Qu’est-ce que cela implique ? Lors d’un transfert normal, l’utilisateur ajuste la commission en fonction de la congestion du réseau, puis le reste est renvoyé vers sa propre adresse de changement (change). Mais l’attaquant ne se soucie pas des frais : il utilise l’argent volé, payer un peu plus ne change rien. Sans sortie de changement, cela signifie qu’il ne détient même pas l’UTXO complet de ces portefeuilles : il utilise directement des clés privées calculées pour transférer l’argent.

562 bitcoins ont été fusionnés dans une seule adresse. Au moment de la publication, cet argent n’a pas bougé d’un iota.

L’ingénieur de Block, Clay Garrett, a ensuite découvert davantage d’indices : les caractéristiques de signature de 695 transactions correspondent à des transactions de vol déjà confirmées ; si tout était validé, 488 bitcoins supplémentaires seraient attribués à la même vague d’attaque. Finalement, Galaxy Research a figé le total de la première vague à 1 082,65 bitcoins, provenant de 1 196 adresses.

Tous les portefeuilles victimes étaient des portefeuilles à signature unique, avec des soldes supérieurs à 0,15 bitcoin. Aucun ne faisait de multi-signature, et aucun n’utilisait une forte phrase de passe.

25 minutes, 594 bitcoins. 41 minutes, 1 082 bitcoins.

La vitesse elle-même est une preuve. Ce n’est pas de la manipulation humaine : ce sont des scripts automatisés qui moissonnent en masse.

Officiel en retard de 30 heures

L’attaque a eu lieu dans la nuit du 30 juillet. Et le moment où Coinkite a publié l’avis de sécurité initial, c’était environ 30 heures plus tard.

D’après The Block, le 30 juillet, l’équipe Bitcoin engineering et sécurité de Block a remarqué en premier une anomalie en chaîne, puis a enquêté de manière indépendante jusqu’à la cause fondamentale. Ils ont ensuite divulgué leurs constatations à Coinkite. Le même jour, Coinkite a publié une annonce initiale ne concernant que les Mk3.

Mais Block a choisi de publier un rapport technique avant que tout ne soit terminé chez Coinkite. La raison est simple : Block écrit dans son rapport : « Une exploitation active est en cours. »

À chaque heure de silence en plus, un autre portefeuille risque d’être vidé.

Le 31 juillet, le PDG de Coinkite, Rodolfo Novak (surnommé NVK dans le milieu), a publié une lettre d’excuses publique. « Je suis désolé, et brisé. Notre équipe est sous le choc face aux nouvelles d’hier. » Il a écrit, tout en reconnaissant que l’entreprise assume l’entière responsabilité.

Mais s’excuser ne rend pas les graines déjà générées sûres. NVK l’admet : les mises à jour du firmware ne protègent que les nouvelles graines générées à l’avenir ; pour les portefeuilles créés avec le firmware vulnérable, la mise à jour ne sert à rien. Les utilisateurs doivent régénérer des graines sur le firmware sécurisé, puis transférer l’intégralité des fonds vers un nouveau portefeuille.

Le 31 juillet, Coinkite a publié un firmware de correctif d’urgence : Mk3 vers v4.2.0 ou plus, Mk4 et Mk5 vers v5.6.0 ou plus, Q vers v1.5.0Q ou plus. L’annonce avertit aussi explicitement : ne vous précipitez pas pendant la migration ; les pertes dues à une erreur d’exécution pourraient être plus importantes que la vulnérabilité elle-même.

Mais une réalité gênante : d’après le cofondateur de Casa, Jameson Lopp, révélé sur X, Coinkite efface toutes les traces des clients après 120 jours afin d’éviter une fuite de données. Cela signifie qu’ils ne peuvent tout simplement pas contacter les utilisateurs qui ont acheté des appareils vulnérables au cours des 5 dernières années.

Ceux qui avaient déjà jeté une ColdCard dans un tiroir, persuadés que les bitcoins étaient en sécurité, ne le sauront peut-être jamais : leur portefeuille est peut-être en train d’être cassé brutalement.

Deuxième vague : moisson précise

Le 31 juillet, la deuxième vague d’attaque arrive.

Cette fois, l’attaquant a balayé 76,16 bitcoins depuis 1 478 adresses. Par rapport à la première vague, le montant est beaucoup plus faible, mais le nombre d’adresses impliquées est au final plus élevé.

Qu’est-ce que cela montre ? L’attaquant est en train de faire le « nettoyage ».

La première vague est un coup chirurgical : elle vise d’abord à vider les cibles de grande valeur, avec des soldes élevés et des temps d’inactivité longs. La deuxième vague élargit la recherche : elle récupère aussi les adresses au solde plus faible, possiblement oubliées. Le rendement moyen par bitcoin passe d’environ 0,91 bitcoin dans la première vague à environ 0,05 : et cela indique justement que l’attaquant a constitué une base de données complète des adresses vulnérables et procède à une liquidation systématique.

Ce qui inquiète encore plus, ce sont les dates. La deuxième vague a eu lieu après la publication de l’avis de sécurité de Coinkite. Autrement dit, l’attaquant savait déjà que l’incident avait été exposé, mais a continué à opérer à grande échelle.

Il n’a pas l’intention de s’arrêter.

Troisième vague : disparition

Du 31 juillet au 1er août, la troisième vague d’attaques apparaît. Environ 208 bitcoins (Galaxy Research a suivi avec précision 207,7294 bitcoins) ont été transférés depuis 1 912 adresses.

Mais cette fois, l’attaquant a changé de méthode.

Les deux premières vagues d’attaque partagent un trait : les fonds sont regroupés dans quelques adresses « collectrices ». C’est une méthode de consolidation efficace, mais elle rend aussi très facile le suivi des flux de fonds par les analystes en chaîne. Les 562 bitcoins déposés sur la même adresse — tout le monde les observe.

La troisième vague est complètement différente. Les fonds des victimes ne sont pas envoyés vers quelques adresses seulement : ils sont répartis dans 293 adresses distinctes de coffres-forts P2WSH.

P2WSH (Pay-to-Witness-Script-Hash) est un type d’adresse Bitcoin : les conditions pour dépenser sont cachées avant le mouvement des fonds. Un observateur externe ne peut pas déterminer à partir de l’adresse elle-même quelles conditions ces bitcoins doivent respecter pour être dépensés à nouveau. 293 coffres distincts signifient que la difficulté de traçage augmente de manière géométrique.

Dans son analyse, Galaxy Research indique deux possibilités : premièrement, l’attaquant initial aurait reconstruit une stratégie de regroupement des fonds après que les opérations de la première vague aient été exposées, afin de réduire le risque d’être suivi ; deuxièmement, un autre attaquant indépendant aurait découvert le même lot d’adresses vulnérables et aurait lancé sa propre campagne de balayage.

À partir uniquement des données on-chain, il est impossible de distinguer ces deux possibilités.

Mais quelle que soit la situation, la conclusion est la même : l’attaque n’est pas encore terminée.

D’ici le 2 août, Galaxy Research a publié les données cumulées des trois vagues d’attaque : 1 367,05 bitcoins, 4 585 adresses, soit environ 88,6 millions de dollars de perte.

Quant à un autre panneau de surveillance, « Coldcard Sweep Watch », le chiffre donné le samedi à 17 h (heure de l’Est des États-Unis) est de 1 158,848 bitcoins — légèrement inférieur aux statistiques de Galaxy. L’écart entre ces deux sources de données montre à lui seul que le tableau complet de cette attaque continue d’évoluer.

Le hasard n’est pas aléatoire

Pour aider des lecteurs non techniques à comprendre à quel point cette faille est grave, il faut expliquer un concept central : le hasard.

Dans le monde de la cryptographie, « le hasard » est la base de tout. Votre clé privée Bitcoin, la graine de votre portefeuille, vos phrases mnémoniques — tout provient de nombres aléatoires. Si ces nombres sont suffisamment « aléatoires », la probabilité de deviner votre clé privée est proche de zéro. Mais si les nombres aléatoires peuvent être prédits ou reproduits, alors votre portefeuille n’est qu’une porte entrouverte.

Le problème de ColdCard se situe précisément ici.

Le rapport technique détaillé de l’équipe engineering de Block révèle toute la chaîne d’échecs complète :

Première couche en échec : le générateur de nombres aléatoires matériel a été désactivé. Le chip STM32 de ColdCard contient un générateur de hasard véritable (TRNG) intégré, initialement destiné à créer la « mine d’or » des clés privées. Mais une erreur de configuration de compilation a fait contourner ce TRNG : le système a alors basculé vers un générateur pseudo-aléatoire logiciel de MicroPython, Yasmarang.

Deuxième couche en échec : la graine de Yasmarang n’est pas sûre. Les paramètres d’initialisation de Yasmarang proviennent de trois sources : l’UID 96 bits du MCU (identifiant unique du chip, seuls les 32 bits les moins significatifs sont utilisés), le minuteur SysTick (un compteur décrémentant périodiquement, environ 80 000 valeurs possibles pour les Mk2/Mk3) et le registre d’horloge temps réel RTC. Aucune de ces trois valeurs n’est une clé au sens cryptographique. Le numéro de série est écrit en usine, le minuteur est déductible, l’horloge est mesurable.

Échec de la troisième couche : l’opération XOR ne crée pas d’entropie. La bibliothèque libngu maintient un deuxième état Yasmarang, initialisé à l’aide de constantes publiques : chaque sortie est ensuite calculée par XOR avec la sortie de MicroPython. Mais les principes fondamentaux de la cryptographie nous disent que si deux entrées peuvent toutes deux être reproduites, alors le résultat XOR de ces deux entrées peut aussi être reproduit. Le XOR ne crée aucune incertitude « de nulle part ».

Quatrième couche en échec : la fonction de hachage n’ajoute pas non plus d’entropie. ColdCard applique un double hachage SHA256d au seed généré. Une fonction de hachage rend la sortie plus uniforme en apparence, mais elle n’augmente pas le nombre de combinaisons possibles des entrées. Si l’entrée ne contient que 2^32 graines possibles, alors la sortie ne contient aussi que 2^32 possibilités — juste « plus brouillée ».

Pour les appareils Mk4, Q et Mk5, bien que le mécanisme de re-seeding des éléments de sécurité ait été ajouté, seuls 4 octets (32 bits) de résumé sont conservés. Le plafond est fixé à environ 4,3 milliards de possibilités. Et pour Mk2 et Mk3 sur les firmwares v4.0.0 à v4.1.9, si l’attaquant connaît l’UID de l’appareil et l’état du minuteur, les candidats tombent directement à 2^0 — complètement déterministe.

Cela signifie que tant que l’attaquant peut obtenir votre numéro de série d’appareil et l’heure approximative de génération, il peut reproduire hors ligne tout le flux de hasard de votre portefeuille, puis en déduire votre clé privée.

Et obtenir le numéro de série de l’appareil, c’est à quel point difficile ? Le firmware de ColdCard est open source, le code est sur GitHub. Toute personne disposant d’un appareil du même modèle peut mesurer les schémas de comportement du minuteur et de l’horloge. Pour le numéro de série — si vous achetez une ColdCard d’occasion sur une plateforme, il est collé sur l’emballage.

Le mensonge des 40 bits

La norme BIP-39 vous dit : 12 mots d’aide correspondent à une entropie de 128 bits, et 24 mots d’aide correspondent à une entropie de 256 bits. C’est une garantie mathématique « incassable ».

Sur l’écran de ColdCard, le processus de génération de graines semble normal. Il vous invite même à lancer des dés pour augmenter le hasard. Si vous ne faites pas cette étape, il « génère aussi » automatiquement une graine. Vous pensez obtenir une sécurité de 128 bits, mais en réalité ce n’est que 40 bits.

Que signifie 40 bits ? Pour comprendre avec une analogie du quotidien : l’espace de recherche de 128 bits revient à numéroter tous les grains de sable sur Terre et à vous demander d’en deviner un seul. L’espace de recherche de 40 bits revient à vous faire deviner un mot de passe numérique de 12 chiffres — quelque chose que les ordinateurs modernes peuvent parcourir en quelques heures.

Et plus cruel encore : cette limite de « 40 bits » est la valeur théorique maximale si l’attaquant ne connaît aucune information sur l’appareil. Si l’attaquant connaît votre UID d’appareil (par exemple, si vous avez déjà affiché une photo de votre appareil sur les réseaux sociaux), l’espace de recherche se rétrécit davantage. S’il connaît en plus l’heure de génération approximative, l’espace de recherche peut tomber à presque zéro.

Ce n’est pas une vulnérabilité théorique « potentiellement exploitable ». C’est une attaque réelle, déjà exploitée, qui a déjà causé des pertes de 88,6 millions de dollars.

Et surtout, le même générateur pseudo-aléatoire vulnérable n’est pas utilisé uniquement pour les graines du portefeuille. Le rapport de Block indique que les clés privées de papier de ColdCard, les masques XOR de séparation des graines, les clés de clonage d’appareil, les clés de transmission Key Teleport, la clé partagée TOTP de Web 2FA — tout utilise la même construction ngu.random. La surface d’attaque est bien plus large que ces adresses déjà « vidées ».

Excuses du PDG et ombre de l’IA

Il y a plusieurs détails notables dans la lettre d’excuses de NVK.

D’abord, il reconnaît que le processus de revue de Coinkite n’a pas réussi à détecter cette vulnérabilité. Ce qui est encore plus inquiétant, c’est que Coinkite avait, avant l’attaque, passé son firmware en revue avec « l’un des meilleurs modèles d’IA » ; le rapport de l’IA était « aucun problème grave trouvé ». Et l’attaquant aurait, semble-t-il, utilisé l’IA pour analyser le code open source du firmware et y retrouver cette faille enfouie depuis 5 ans.

« C’est une réalité glaciale apportée par un nouveau paradigme d’IA. » a écrit NVK. Les attaquants et les défenseurs utilisent les mêmes outils d’IA, mais l’attaquant n’a besoin de trouver qu’une seule faille, tandis que le défenseur doit en trouver toutes. Cette asymétrie met l’efficacité des audits de sécurité open source face à un défi sans précédent.

Deuxièmement, au début, Coinkite n’a averti que les utilisateurs de Mk3, affirmant que les Mk4, Q et Mk5 « ne sont pas affectés par l’analyse préliminaire ». Mais ensuite il a fallu étendre l’avertissement : ces modèles souffrent aussi d’un manque d’entropie, seulement avec une gravité un peu moindre (72 bits vs 40 bits).

72 bits semblent bien meilleurs que 40 bits, mais en pratique cryptographique, 72 bits sont loin en dessous des 128 bits, le standard minimal de sécurité. Dans le cadre d’attaques continues et ciblées, 72 bits ne sont pas incassables. Coinkite décrit cela comme « pas aussi grave, mais encore grave » — une formule bien pâle face à des pertes de 88,6 millions de dollars.

Troisièmement, NVK s’est engagé à aider les utilisateurs touchés à porter plainte auprès de la police, à demander une indemnisation d’assurance ou à lancer une enquête indépendante. Mais Coinkite ne dispose pas des informations de contact des clients (les enregistrements sont effacés après 120 jours) et ne sait pas non plus combien d’appareils vulnérables sont encore en circulation.

Dans un post sur X, le CEO de Casa Nick Neuman a pointé le cœur du problème : « Vous ne pouvez pas demander aux gens de lancer des dés pour garantir la sécurité de l’autogestion. Pour 99 % des gens, c’est tout simplement impossible. »

Des échanges se ruent sur des dizaines de milliers de BTC

L’impact de l’attaque ne se limite pas aux victimes directes.

Le 31 juillet, une hausse anormale a été enregistrée en flux nets entrants de bitcoins sur les bourses centralisées. D’après les données de Timechainindex.com, le flux net entrant des bourses ce jour-là était d’environ 11 163 bitcoins. Parmi eux, River a reçu environ 3 679 bitcoins, Binance environ 3 224, Kraken environ 2 848 et OKX environ 1 291.

Ces entrées ne viennent pas forcément toutes des utilisateurs de ColdCard ou des attaquants. Les opérations quotidiennes des plateformes d’échange, les réajustements de portefeuille des institutions, ainsi que les dépôts et retraits des clients génèrent aussi des flux. Mais un événement de panique de sécurité survenant en même temps que des entrées d’échange aussi massives, et avec une coïncidence temporelle aussi frappante, suffit à attirer l’attention.

Il y a peut-être deux explications : d’une part, les utilisateurs de ColdCard, pris de panique, auraient transféré d’urgence des bitcoins vers des plateformes d’échange une fois le bug connu ; d’autre part, les attaquants tenteraient de monétiser une partie du butin via des échanges. Il se peut aussi que les deux soient vrais.

Pendant ce temps, un autre jeu de données est encore plus intrigant. Entre le 30 juillet et le 1er août, un lot d’adresses dormantes créées entre 2010 et 2017 commence à bouger des bitcoins, pour un total d’environ 306. Parmi elles, une adresse créée le 2 juillet 2010 a déplacé plus de 50 bitcoins de la sortie de transaction coinbase. Trois portefeuilles créés le 29 juillet 2017 ont chacun déplacé 37,5 bitcoins et deux autres sorties de 30 bitcoins dans le même bloc.

Le lien entre le mouvement de ces bitcoins très anciens et l’attaque ColdCard n’a pas encore été confirmé. Mais pendant l’incident de sécurité, de nombreux fonds en sommeil se sont réveillés en même temps — en soi, c’est un signal à ne pas ignorer.

Fêlure du mythe de la conservation à froid

Jusqu’à présent, ColdCard est considéré par la communauté Bitcoin comme l’un des « portefeuilles matériels les plus sûrs ». Il se concentre sur le Bitcoin, sur un fonctionnement totalement hors ligne, sur un firmware open source, et sur la prise en charge des multi-signatures — il coche presque toutes les recommandations de « bonne » autogestion.

C’est précisément pour cela que l’impact de cette attaque est particulièrement lourd.

Le commentateur de Bitcoin Guy Swann a écrit sur X : « C’est la pire attaque jamais subie par un détenteur de Bitcoin, parmi les mieux informés et ceux qui ont “les meilleures mesures de sécurité”. Ce n’est pas une plateforme d’échange victime d’un piratage de hot wallets. Ce sont des milliers d’utilisateurs individuels, et leurs clés privées ont été arrachées sous leurs pieds. »

La directrice de la recherche sur les actifs numériques d’ARK Invest, Lorenzo Valente, l’a exprimé encore plus directement : « Dans le domaine des portefeuilles matériels d’autogestion, c’est actuellement une catastrophe. En réalité, les consommateurs échangent un risque contre un autre risque : le risque de l’adversaire contre le risque logiciel, le risque matériel, le risque de chaîne d’approvisionnement, le risque de phishing, le risque de sauvegarde — et la possibilité de tout perdre à cause d’une seule erreur. Pour être franc : aujourd’hui, avoir votre argent réparti entre plusieurs bourses cotées ou ETF est au final plus sûr. »

Le développeur Taproot Udi Wertheimer a également pointé une transformation plus profonde : « L’idée que vos bitcoins dorment tranquillement quelque part, que vous pouvez vaquer sereinement sans vous inquiéter, n’est plus réaliste aujourd’hui. Si vous ne voulez pas vous en occuper vous-même, vous devez payer quelqu’un pour s’en occuper à votre place. »

Le fondateur de Binance, Zhao Changpeng (CZ), a publié un message le 1er août pour avertir : « Rien n’est 100 % sûr. » Il appelle les utilisateurs à répartir leurs fonds sur plusieurs portefeuilles et à ne pas mettre tous ses œufs dans le même panier.

Les fabricants concurrents ont rapidement tracé une ligne de démarcation. Ledger a déclaré que ses dispositifs utilisent des générateurs de hasard véritable intégrés dans un Secure Element certifié, générant une entropie complète de 256 bits, et qu’ils ne sont pas affectés. Trezor confirme que ses appareils mélangent plusieurs sources indépendantes de hasard, ce qui les rend sûrs.

Mais le débat fondamental déclenché par cette crise dépasse largement une seule entreprise, ColdCard.

Les données de Blockaid montrent que, au premier semestre 2026, la majorité des pertes dans le secteur de la cryptographie ne proviennent pas de failles dans des smart contracts, mais de fuites de clés et d’échecs en matière de sécurité opérationnelle. L’incident ColdCard illustre parfaitement cette tendance : la faille n’est pas au niveau du protocole, mais au niveau de la génération des clés.

La sécurité d’un portefeuille matériel dépend finalement du code du firmware, que l’utilisateur ne voit ni ne touche jamais. Quand ce code se trompe, toute l’isolation matérielle, les opérations hors ligne et la revue open source deviennent des remparts en papier.

Les clés de qui sont-elles restées à nu ?

Au moment de la publication, l’attaque continue.

Galaxy Research surveille environ 300 adresses d’attaquants, en attente du premier décaissement vers l’extérieur. Le rendement moyen des fonds volés diminue : la première vague rapporte en moyenne environ 0,91 bitcoin par adresse, et la troisième vague tombe à environ 0,11. Les gains baissent, mais la recherche ne s’arrête pas : cela indique que le pool d’adresses vulnérables n’est pas encore vidé.

Le problème le plus crucial est le suivant : combien de graines vulnérables n’ont pas encore été découvertes par les attaquants et n’ont pas encore été migrées par les utilisateurs ?

Le nombre d’appareils vendus par ColdCard entre mars 2021 et juillet 2026 n’a jamais été rendu public. La politique de Coinkite consistant à effacer les enregistrements clients rend impossible une notification précise. Et les utilisateurs ayant généré des graines sur un firmware vulnérable, puis importé ces graines dans d’autres portefeuilles, restent eux aussi exposés : des graines non sûres ne deviennent pas sûres simplement parce qu’on change de logiciel.

L’ingénieur de Block, Max Guise, a appelé sur X : « Toute personne disposant d’une ColdCard affectée doit transférer ses fonds vers un endroit sûr dès que possible. »

Peter Todd — ingénieur en cybersécurité, suspecté d’avoir été Satoshi Nakamoto — a soulevé un risque plus discret : même en utilisant des multi-signatures, si 2/3 des dispositifs de signature sont des ColdCard affectées, l’attaquant peut obtenir suffisamment d’informations au moment où l’utilisateur initie la transaction et révèle le script de multi-signature pour détourner les actifs.

Chaque minute, un nouveau portefeuille peut être vidé. Chaque ColdCard encore utilisée avec des graines vulnérables est une bombe en attente d’exploser.

Quant à l’identité de l’attaquant, elle reste inconnue à ce jour. Les 562 bitcoins, eux, reposent toujours tranquillement dans l’adresse agrégée — comme une bête en embuscade, prête à s’éveiller à tout moment.