Faille Coldcard : le bug RNG derrière un vol de 88,6 millions de dollars en bitcoins

Le 30 juillet 2026, une opération automatisée vide 1 083 bitcoins, environ 70,2 millions de dollars à l’époque, depuis plus d’un millier de portefeuilles, en 41 minutes. Deux vagues suivent dans les jours suivants, portant le total à 1 367 bitcoins, environ 88,6 millions de dollars, pris sur 4 585 adresses. Presque tous les portefeuilles touchés sont des Coldcard, une gamme réputée de portefeuilles matériels : des appareils physiques qui conservent hors ligne les clés privées d’un compte bitcoin, à l’écart d’un téléphone ou d’un ordinateur piratable. La cause est une faille logée dans le firmware, le logiciel embarqué qui pilote l’appareil, précisément dans le générateur de nombres aléatoires (RNG) censé produire les nombres imprévisibles dont un portefeuille a besoin pour créer une clé réellement privée. Pendant près de cinq ans, sous certaines conditions, ce composant a produit en silence des nombres qui n’avaient rien d’aléatoire. Coinkite, la société derrière Coldcard, a publié un correctif en moins d’une journée après que le vol est devenu public. Ce correctif n’efface pas ce qui s’est déjà produit, et comprendre pourquoi est la partie que la plupart des articles sur cette affaire ont laissée de côté.

Ce qui a vraiment cloché

Un bug de firmware qui passe inaperçu pendant des années se cache généralement à la vue de tous, comme DecodeStack l’a déjà observé avec les attaques de la chaîne d’approvisionnement logicielle, où le danger se loge dans du code auquel tout le monde fait déjà confiance. Le bug de Coldcard vivait dans une seule vérification de configuration.

Le firmware de Coldcard repose sur MicroPython, une version allégée du langage Python conçue pour les appareils modestes et peu gourmands en énergie. Coinkite avait configuré ce firmware pour s’appuyer sur sa propre source matérielle d’aléa, un générateur intégré à la puce qui produit des nombres à partir d’un bruit électrique trop chaotique pour être prévisible, plutôt que sur le générateur intégré de MicroPython. Pour cela, un paramètre nommé MICROPY_HW_ENABLE_RNG est censé être désactivé, ce qui indique au firmware d’ignorer complètement le générateur propre à MicroPython.

C’est là que se nichait le bug. Selon l’analyse technique de Block Engineering, l’équipe de recherche en sécurité qui a découvert la faille et coordonné sa divulgation avec Coinkite, le code chargé de vérifier ce paramètre se contentait de tester s’il existait, jamais s’il était réellement activé. Le paramètre étant présent, seulement désactivé, la vérification passait, et le firmware basculait silencieusement vers le générateur propre de MicroPython au lieu du générateur matériel dédié autour duquel Coldcard avait été conçu.

Ce générateur de secours, baptisé Yasmarang, n’a jamais été pensé pour la sécurité. C’est un algorithme simple, destiné à des tâches de programmation ordinaires, dont la sortie paraît aléatoire mais peut être reconstituée par quiconque connaît son point de départ. L’implémentation de Coldcard combinait deux instances de Yasmarang, amorcées à partir de constantes fixes et publiquement connues, ainsi que de l’identifiant de puce et de l’horloge interne de l’appareil, aucune de ces informations n’étant secrète pour un attaquant qui chercherait à les deviner.

Faible à quel point

Le dommage concret se résume à l’entropie, le terme que les cryptographes emploient pour désigner le nombre de résultats possibles que peut produire un processus aléatoire. Une clé de 128 bits réellement aléatoire possède à peu près autant de valeurs possibles qu’il y a d’atomes dans un gros rocher, bien plus de combinaisons qu’une puissance de calcul réaliste ne pourrait jamais épuiser. C’est le niveau d’imprévisibilité que la génération de clés de Coldcard était censée garantir.

Avec le bug actif, ce nombre s’effondrait. L’analyse technique de Coinkite elle-même a chiffré l’entropie effective à environ 2^40 sur les anciens appareils Mk2 et Mk3, et environ 2^72 sur les modèles plus récents Mk4, Mk5 et Q. En clair, 2^40 possibilités est une plage qu’un cluster informatique moderne peut parcourir en quelques heures. 2^72 est nettement plus grand et hors de portée d’un attaquant occasionnel, mais pas d’un acteur bien financé, équipé de matériel dédié et suffisamment motivé. Les deux chiffres marquent une chute vertigineuse par rapport aux environ 2^128 que le portefeuille était censé offrir, et c’est cet écart, entre « impossible à deviner » et « devinable avec assez de puissance de calcul », qui a transformé un bug de firmware obscur en vol effectif.

Le vol en trois vagues

Le bug seul n’aurait rien changé sans quelqu’un pour le trouver et l’exploiter. Le reportage de BleepingComputer sur le vol crédite le groupe de recherche on-chain (directement sur la blockchain) Galaxy Research d’avoir repéré le lien entre l’aléa affaibli et la vague de portefeuilles vidés. Galaxy Research suit les mouvements de cryptomonnaies au quotidien ; ce n’est pas ce groupe qui a trouvé le bug de firmware sous-jacent, un mérite qui revient à Block Engineering.

La première vague frappe le 30 juillet 2026 : 1 083 bitcoins, environ 70,2 millions de dollars, prélevés sur 1 196 adresses en 41 minutes, à peu près 30 heures avant que le bug RNG ne devienne public. Deux vagues suivent le 1er août, portant le total cumulé à 1 367 bitcoins et 4 585 adresses, pour environ 88,6 millions de dollars.

Chaque transaction payait des frais fixes identiques et ne renvoyait aucun fonds restant vers une nouvelle adresse, à l’inverse de ce que ferait quelqu’un déplaçant son propre argent (les frais, 30 satoshis par octet virtuel, sont une unité standard de frais Bitcoin). Cette régularité sur des milliers de retraits distincts trahit un outil automatisé travaillant méthodiquement une liste d’adresses vulnérables, pas une personne cliquant portefeuille après portefeuille. Le décompte ne s’est pas arrêté là : des vagues après le 1er août ont poussé le total au-delà de 100 millions de dollars, un rappel que tout chiffre attaché à un vol actif reste un instantané, jamais un bilan final.

La réponse de Coinkite : rien nié

Coinkite n’a pas contesté le bug. Le PDG Rodolfo Novak a publié des excuses publiques sur X, se disant bouleversé par les pertes et affirmant que le bug de firmware relevait de la seule responsabilité de Coinkite, sans erreur d’utilisateur ni attaque extérieure sur la chaîne d’approvisionnement de Coldcard.

Coinkite a appuyé ses excuses par des actions concrètes. L’entreprise a publié un avis officiel sur le firmware nommant chaque version affectée, détruit son stock d’appareils non expédiés qui portaient encore le firmware vulnérable et publié un correctif d’urgence le 31 juillet 2026, moins de 24 heures après la première vague du vol.

Cette réponse a été rapide et précise, sans le flou du « nous avons subi une attaque sophistiquée » que beaucoup d’entreprises invoquent après un incident de sécurité. Elle n’efface pas le vol. Elle a donné aux propriétaires de Coldcard un compte-rendu clair de ce qui s’était passé et de ce qu’il fallait faire, plutôt qu’une déclaration tardive suivie de semaines de silence.

Le correctif que les gros titres résument mal

Voici le détail qui sépare un titre utile d’un titre trompeur : mettre à jour le firmware de Coldcard ne protège pas les bitcoins déjà présents sur une seed générée avant la mise à jour. Une seed, ou phrase de récupération, est la liste de mots qu’un portefeuille utilise pour reconstruire chacune des clés privées qu’il contrôle. Si cette seed a été générée pendant que le bug RNG était actif, la seed elle-même est faible, et aucune mise à jour ultérieure du firmware ne change les mots déjà produits.

Le correctif referme la faille pour l’avenir. Quiconque génère une seed toute neuve sur un firmware à jour bénéficie de la pleine protection que l’appareil était censé offrir depuis le départ. Mais un portefeuille qui continue d’utiliser son ancienne seed, firmware corrigé ou non, reste exposé à quiconque aurait trouvé comment reproduire cet aléa affaibli.

Deux catégories de propriétaires n’ont, elles, jamais couru de risque sérieux. Quiconque a ajouté au moins 50 lancers de dés indépendants à la génération de sa seed, une fonctionnalité intégrée qui laisse un dé physique apporter de l’aléa en plus du générateur de l’appareil, s’est retrouvé avec une seed qu’aucun bug logiciel ne pouvait affaiblir. La même protection s’applique à qui utilise une passphrase BIP-39 forte et unique, un mot ou une phrase facultative ajoutée par-dessus une seed, qui crée en pratique un portefeuille distinct qu’un attaquant ne peut pas dériver de la seule seed. Tous les autres ont généré une seed entièrement dépendante de l’appareil, et pendant près de cinq ans, dans les bonnes conditions, ce dernier a failli.

Ce que les propriétaires de Coldcard doivent vraiment faire maintenant

La recommandation de Coinkite est directe : mettez d’abord le firmware à jour, mais traitez cette mise à jour comme une première étape, pas comme le correctif complet.

• Mettez à jour le firmware vers une version corrigée immédiatement : 4.2.0 pour le Mk3 ; 5.6.0 (ou 6.6.0X sur le firmware Edge) pour les Mk4 et Mk5 ; et 1.5.0Q (ou 6.6.0QX sur Edge) pour le Coldcard Q.
• Vérifiez si une seed existante reposait uniquement sur l’aléa propre de l’appareil. Si elle n’a pas été générée avec au moins 50 lancers de dés indépendants ou une passphrase forte, considérez-la comme potentiellement exposée.
• Générez une nouvelle seed sur le firmware mis à jour et déplacez-y les fonds, plutôt que de supposer que la mise à jour seule a suffi à sécuriser une ancienne seed.
• Déplacez les fonds avec prudence, en vérifiant chaque adresse de réception directement sur l’écran de l’appareil, puisque le risque ici tient à une seed affaiblie et non à une intrusion active ciblant un compte précis.

Rien de tout cela n’appelle à la panique. Cela demande de traiter un correctif logiciel et une seed compromise comme deux problèmes distincts : un correctif répare le code, seule une nouvelle seed répare une clé déjà affaiblie. C’est le même réflexe qui sous-tend la conception de sécurité zero trust : ne jamais supposer qu’un seul correctif couvre tout ce qui en dépend en aval.

Ce qu’il faut retenir

L’incident Coldcard restera probablement dans les mémoires comme un vol de bitcoins dépassant largement les 100 millions de dollars, une fois le décompte stabilisé. Ce chiffre compte moins que ce qui reste vrai quel que soit le total final : la défaillance d’un générateur de nombres aléatoires ne se répare pas avec une simple mise à jour logicielle, parce que les nombres déjà produits sont toujours là, enfermés dans des seeds qui ne changent pas parce que le code qui les a créées a changé. N’importe quel portefeuille matériel, de n’importe quel fabricant, pourrait cacher la même catégorie de bug dans une seule ligne de logique de configuration. La leçon n’est pas de se méfier des portefeuilles matériels. C’est de savoir que lorsque l’un d’eux corrige un bug d’aléa, le correctif protège ce qui vient après, pas ce qui existe déjà.

Questions fréquentes

Qu’est-ce que la faille RNG de Coldcard ?

La faille RNG de Coldcard est un bug de firmware sur les portefeuilles matériels Coldcard, où une vérification mal configurée laissait l’appareil basculer silencieusement vers un générateur de nombres logiciel prévisible, Yasmarang, au lieu de sa source matérielle d’aléa dédiée. Elle a affaibli la génération de clés sur les appareils concernés pendant près de cinq ans, avant sa découverte coordonnée en 2026.

Quels appareils Coldcard sont concernés par la faille RNG ?

Les appareils Coldcard Mk2 et Mk3 exécutant les firmwares 4.0.1 à 4.1.9 ; les Mk4 et Mk5 sur un firmware antérieur à 5.6.0 (ou 6.6.0X sur les versions Edge) ; et les Coldcard Q antérieurs à 1.5.0Q (ou 6.6.0QX sur Edge) sont tous concernés. Le correctif de Coinkite du 31 juillet 2026 a réglé le problème sous-jacent sur les trois gammes d’appareils.

La mise à jour du firmware Coldcard corrige-t-elle une seed générée avant le correctif ?

Non, mettre à jour le firmware de Coldcard empêche que de nouvelles seeds soient générées avec un aléa affaibli, mais cela ne change rien à une phrase de récupération déjà créée sur un firmware vulnérable. Quiconque s’est reposé uniquement sur le générateur intégré de l’appareil avant le correctif doit générer une nouvelle seed et y déplacer ses fonds, pas seulement mettre à jour.

Qui a découvert le bug RNG de Coldcard ?

Block Engineering, une équipe de recherche en sécurité, a trouvé la faille RNG et coordonné sa divulgation directement avec Coinkite avant la sortie du correctif. Séparément, les analystes on-chain de Galaxy Research ont identifié le lien entre l’aléa affaibli et la vague de portefeuilles Coldcard vidés, un rôle distinct de la découverte du bug lui-même.

Une seed Coldcard générée avec des lancers de dés ou une passphrase est-elle sûre ?

Oui, une seed Coldcard générée avec au moins 50 lancers de dés physiques indépendants ajoutés au processus, ou protégée par une passphrase BIP-39 forte et unique, n’a jamais dépendu du seul aléa matériel défaillant et n’a pas été affaiblie par ce bug. Les propriétaires ne disposant d’aucune de ces deux protections doivent considérer leurs seeds antérieures au correctif comme potentiellement exposées.