Une option de compilation laissée dormante dans le firmware du portefeuille matériel COLDCARD pendant cinq ans a été liée au vol d'environ 116 millions de dollars en bitcoin, après qu'un paramètre de compilation mal configuré a silencieusement affaibli l'aléatoire utilisé pour générer les graines des utilisateurs. Ce qui a commencé comme un choix de configuration négligé a entraîné l'un des plus grands vols en auto-conservation enregistrés en 2026.

Selon Block Engineering, le firmware COLDCARD affecté définissait la macro MICROPY_HW_ENABLE_RNG comme zéro, tandis que la bibliothèque libngu vérifiait uniquement si la macro existait — et non sa valeur réelle. Cela a amené le système à se rabattre sur le générateur de nombres pseudo-aléatoires déterministe Yasmarang de MicroPython, qui produit des résultats prévisibles et sape fondamentalement l'entropie qu'un portefeuille matériel est censé garantir.

Comment l'option de compilation est devenue centrale dans l'exploit

Une option de compilation est un commutateur au moment de la compilation qui détermine quelles fonctionnalités sont activées lorsque le logiciel est assemblé en un binaire distribuable. Dans ce cas, l'option était destinée à activer un véritable générateur de nombres aléatoires matériel. Au lieu de cela, elle a été définie à zéro, et la logique de vérification en aval n'a jamais détecté l'écart.

Comme l'option régissait la façon dont les clés privées étaient générées, les conséquences ont été graves. Les graines servent de secret maître derrière chaque adresse qu'un portefeuille contrôle. Un aléatoire prévisible au moment de la génération de la graine signifie qu'un attaquant qui comprend la faille peut reconstituer les clés privées résultantes.

TRM Labs a rapporté que des attaquants ont drainé 1,816 BTC — d'une valeur d'environ 116 millions de dollars — provenant de plus de 5,200 adresses lors de quatre vagues distinctes. L'ampleur de la campagne indique que la vulnérabilité a affecté une large population d'appareils plutôt qu'un groupe isolé d'utilisateurs.

Block Engineering a déclaré que l'exploitation active était déjà en cours lorsqu'il a publié son analyse le 30 juillet 2026, et a dirigé les utilisateurs vers le fabricant du portefeuille, Coinkite, pour le rapport définitif.

Ce qui a échoué entre le développement, la révision des versions et les contrôles de sécurité

La survie d'une option mal configurée à travers plusieurs cycles de version pointe vers des lacunes dans le pipeline de vérification. La sécurité des portefeuilles matériels dépend de la signature stricte du code, de builds reproductibles et de contrôles d'intégrité rigoureux — précisément les garanties qui auraient dû identifier une macro RNG à valeur zéro.

Coinkite a directement quantifié le déficit d'entropie. Les graines générées sur les appareils Mk4, Q et Mk5 fonctionnant avec un firmware antérieur à la correction contenaient environ 72 bits d'entropie au lieu des 128 bits attendus — une réduction qui rend la reconstruction par force brute des clés privées réalisable. En termes cryptographiques, 72 bits représente un espace de clés environ 2^56 fois plus petit que la norme de 128 bits prévue, franchissant le seuil de l'informatiquement infaisable pour devenir pratique pour un attaquant bien équipé.

Coinkite a conseillé que les fonds générés sur le firmware affecté restent à risque à moins que la graine n'ait été créée avec au moins 50 lancés de dés indépendants et privés, ou que le portefeuille n'ait été sécurisé avec une phrase de passe BIP-39 forte et unique. La remédiation est en outre compliquée par la fragmentation entre cinq pistes de version de firmware distinctes, plutôt qu'un seul correctif universel.

La distinction entre vérifier l'existence d'une macro et vérifier sa valeur représente le type de faille logique subtile que les contrôles d'intégrité automatisés et les processus de revue de code sont conçus pour détecter. La plupart des attaques documentées de portefeuilles matériels reposaient sur la falsification physique, les techniques par canal auxiliaire ou la compromission de la chaîne d'approvisionnement ; une faille de configuration au moment de la compilation affaiblissant silencieusement l'entropie sur des années de production représente un mode de défaillance distinct que les modèles de menace existants n'avaient peut-être pas anticipé de manière adéquate. Les utilisateurs de portefeuilles matériels s'attendent à une norme de protection supérieure à celle des applications classiques précisément parce qu'une graine compromise ne peut pas être remplacée aussi facilement qu'un mot de passe.

Implications plus larges pour les utilisateurs de portefeuilles matériels et le secteur

Une perte à neuf chiffres remet directement en cause la proposition de valeur fondamentale du stockage à froid. Le timing est significatif : l'adoption de l'auto-conservation s'est accélérée après l'effondrement de FTX en novembre 2022 qui a érodé la confiance dans les échanges centralisés, rendant les vulnérabilités de portefeuilles matériels de cette ampleur particulièrement dommageables pour la crédibilité de l'écosystème. CoinDesk a rapporté le 31 juillet 2026 que l'exploit avait déjà entraîné le vol de près de 600 BTC, d'une valeur d'environ 38 millions de dollars à ce moment-là. Les analystes ont suggéré que l'incident pourrait servir de catalyseur pour l'intérêt dans les dépositaires réglementés et les ETF bitcoin au comptant.

Le sentiment du marché a reflété la perturbation. L'indice Fear & Greed s'est établi à 25, indiquant une Peur Extrême, alors que le bitcoin se négociait près de 64,766 dollars.

Pour les utilisateurs affectés, les questions pratiques immédiates sont : quelle piste de firmware s'applique à leur appareil, si leur graine répondait aux critères d'exemption de lancers de dés ou de phrase de passe, et à quelle vitesse les fonds peuvent être migrés vers un environnement sécurisé. Au 6 août 2026, Coinkite n'avait pas publié son propre chiffre de perte cumulée ni de liste d'adresses d'attaquants, laissant le décompte de TRM Labs comme référence principale.

L'incident souligne que les configurations de compilation héritées ne sont pas inertes. Une seule valeur au moment de la compilation, laissée inexaminée à travers des années de cycles de version, s'est traduite par un risque systémique pour un produit commercialisé sur la force de sa sécurité — un rappel que la rigueur opérationnelle au moment de la compilation est inséparable de la confiance placée dans les solutions d'auto-conservation.