Guide d’urgence pour la sécurité du portefeuille
Vulnérabilité COLDCARD 2026 : vérifiez votre seed, pas seulement le firmware
Une mise à jour du firmware corrige la génération des nouvelles seeds, mais ne renforce pas une seed déjà créée avec une faible entropie. Si votre seed actuelle provient d’un firmware COLDCARD concerné, suivez attentivement les étapes ci-dessous pour migrer.
À lire avant toute modification
Mettre à jour l’appareil ne corrige pas le portefeuille déjà utilisé
Le correctif firmware modifie la création des futures seeds. Il ne change pas les mots, clés privées ou adresses issus d’une seed déjà vulnérable. Sauf exception officielle des dés, créez une nouvelle seed et transférez-y vos fonds.
Table des matières
Modèles et versions concernés
Comparez le firmware qui a généré la seed
La version installée aujourd’hui ne suffit pas. Il faut connaître le modèle, la branche et le firmware utilisé lors de la création de la seed actuelle.
| Modèle et branche | Génération de seed vulnérable | Version minimale corrigée pour nouvelle seed |
|---|---|---|
| Mk2 / Mk3 | Seeds créées avec le firmware 4.0.1 à 4.1.9 | 4.2.0+ |
| Mk4 / Mk5 standard | Seeds créées avant la version standard corrigée | 5.6.0+ |
| Q standard | Seeds créées avant la version standard corrigée | 1.5.0Q+ |
| Mk4 / Mk5 Edge | Seeds créées avant la version Edge corrigée | 6.6.0X+ |
| Q Edge | Seeds créées avant la version Edge corrigée | 6.6.0QX+ |
Standard et Edge sont des branches distinctes
Une version Edge 6.x plus ancienne n’est pas forcément sûre parce que son numéro est supérieur à une version standard 5.x. Vérifiez bien le modèle et la branche.
Certains produits Coinkite utilisent un autre code
Coinkite précise que TAPSIGNER, OPENDIME et SATSCARD ne sont pas concernés par ce défaut de génération de seed, car ils reposent sur d’autres bases de code.
Vérifier l’appareil
Comment vérifier le firmware installé
Selon la documentation COLDCARD, déverrouillez l’appareil, ouvrez Advanced/Tools, Upgrade Firmware puis Show Version. Comparez le modèle, la branche et la version affichés avec la page d’état de sécurité actuelle.
Voir l’état de sécurité officielLa question à laquelle le menu ne répond pas
Quel firmware a généré cette seed à l’origine ?Utilisez la date d’initialisation, d’achat, l’historique des versions ou vos propres archives pour préciser. Si la seed a pu être créée sur une version vulnérable et que vous ne pouvez pas prouver le contraire, suivez la migration conservatrice.
Parcours décisionnel simple
Faut-il migrer ?
- 01
La seed actuelle a-t-elle été générée sur un COLDCARD ?
Si non, ce défaut de génération de seed COLDCARD n’est pas en cause. Si oui ou incertain, poursuivez.
- 02
A-t-elle été créée sur un modèle et une version concernés ?
Comparez la période d’initialisation avec la matrice des versions concernées. Le firmware installé aujourd’hui ne suffit pas.
- 03
Au moins 50 lancers de dés équitables, indépendants et privés ont-ils été ajoutés lors de la création de la seed ?
Coinkite indique qu’une seed remplissant toutes ces conditions n’est pas exposée à ce problème de RNG. Si vous avez lancé moins de dés, si la séquence a été exposée ou si vous avez un doute, poursuivez la migration.
- 04
Une phrase secrète BIP-39 forte et unique a-t-elle été utilisée ?
Cela peut ralentir un attaquant, mais ne corrige pas la seed. Sauf exception des dés, prévoyez une migration prudente dès que possible.
Une phrase secrète BIP-39 forte et unique ajoute une barrière supplémentaire et limite l’exposition immédiate. Cela ne corrige toutefois pas la seed d’origine. Coinkite recommande aux utilisateurs de phrase secrète de migrer dès que possible, sauf si l’exception des dés indépendants s’applique.
Ce qui a échoué
Une cryptographie forte avec une base faible
Bitcoin et ECDSA n’ont pas été compromis. Le problème vient d’avant : certaines seeds ont été générées à partir d’un espace de possibilités bien plus restreint que promis.
Chemin attendu
Le générateur matériel dédié doit fournir l’aléa utilisé pour créer la seed.
Chemin affecté
rng_get()→ngu.random.bytes()→Seed du portefeuilleUne erreur d’intégration lors de la compilation a relié la génération de seed au générateur logiciel MicroPython au lieu du générateur matériel prévu.
La leçon d’ingénierie
Le code source peut contenir le bon composant de sécurité alors que le binaire final utilise le mauvais.L’open source, les revues et les builds reproductibles facilitent la vérification, mais ne remplacent pas les tests de bout en bout du chemin d’appel réel et du binaire lié. La correction inclut désormais des vérifications pour rejeter le mauvais symbole RNG à la compilation.
Pourquoi ces chiffres sont importants
128 bits, environ 72 bits et environ 40 bits : des écarts majeurs
Chaque bit manquant divise par deux le nombre de possibilités à tester pour un attaquant. Perdre des dizaines de bits transforme une recherche impossible en un vrai risque de sécurité.
Niveau de sécurité minimal visé pour la seed générée.
L’ajout d’entropie du composant sécurisé a aidé, mais le résultat restait très insuffisant.
Un espace de possibilités considérablement réduit, créant un risque immédiat pour les portefeuilles contenant des fonds.
Ce sont des estimations issues de l’analyse de l’incident, pas une garantie que chaque appareil ou seed a exactement le même espace de recherche. La recommandation reste : traitez toute seed potentiellement concernée avec prudence.
Un incident réel, pas un simple avertissement théorique
Les vols signalés ont révélé la faille
Bitcoin Optech estimait déjà les pertes à plus de 1 000 BTC le 31 juillet 2026. Au 4 août, Galaxy Research avait relié 1 596 BTC à trois vagues d’attaques confirmées. Une quatrième vague possible porterait le total à 2 055 BTC, mais elle ne disposait pas encore d’assez de confirmations de victimes.
TRM Labs a publié le 5 août une estimation distincte d’environ 1 816 BTC, en précisant qu’elle restait provisoire. Les chiffres diffèrent, car les analystes ne regroupent pas les adresses de la même façon et n’appliquent pas les mêmes critères de confirmation des victimes. Ce sont des estimations crédibles, pas un total définitif établi.
-
Le chemin défaillant touche la génération de seed
La migration vers libNgU a modifié le chemin de génération des seeds.
-
Première alerte publique
L’alerte initiale visait Mk3 et considérait d’abord les modèles plus récents comme hors risque principal.
-
L’étendue des versions concernées s’élargit
Les recommandations ont été mises à jour pour inclure Mk4, Mk5, Q et les branches Edge séparées ; des versions corrigées ont été publiées.
-
Pertes et causes techniques analysées
Coinkite a reconnu l’impact réel et publié plus de détails sur la compilation, le linker et les sous-modules.
-
Les pages d’état et de migration sont regroupées
Coinkite a publié une matrice des versions corrigées, des preuves de validation ciblées et un guide de migration dédié.
Procédez lentement et vérifiez chaque étape
Séquence de migration sécurisée
Aller trop vite peut aggraver la situation. Préparez le nouveau portefeuille, vérifiez que vous pouvez recevoir et restaurer, puis transférez le solde.
- 01
Vérifiez l’ancienne sauvegarde
Vérifiez que la sauvegarde écrite et l’empreinte du portefeuille correspondent bien au portefeuille qui détient actuellement les fonds.
- 02
Installer et vérifier le firmware corrigé
Utilisez le bon modèle et la bonne branche. Vérifiez le téléchargement officiel et la version sur l’appareil avant toute nouvelle seed.
- 03
Générez une nouvelle seed
Utilisez le processus COLDCARD corrigé ou un autre hardware wallet que vous avez évalué. Ne réutilisez ni n’importez les anciens mots.
- 04
Sauvegardez le nouveau portefeuille hors ligne
Notez soigneusement la nouvelle seed. Si vous utilisez une phrase secrète, sauvegardez-la séparément et à l’identique.
- 05
Vérifiez l’empreinte et l’adresse de réception
Redémarrez l’appareil, vérifiez l’empreinte du portefeuille attendue et comparez une adresse de réception affichée sur le hardware wallet.
- 06
Envoyer un petit montant test
Transférez un petit montant depuis l’ancien portefeuille et vérifiez que le nouveau le reçoit et peut être restauré.
- 07
Transférez le solde restant
Une fois le test validé, transférez le reste vers ce nouveau portefeuille vérifié.
- 08
Conservez l’ancienne sauvegarde jusqu’à confirmation
Ne détruisez pas l’ancienne sauvegarde tant que toutes les transactions attendues ne sont pas confirmées et que le nouveau portefeuille n’a pas été vérifié.
Changer d’appareil ne suffit pas
Ne restaurez pas la même seed vulnérable sur une autre marque
La faiblesse est liée à la seed et à toutes les clés qui en découlent. Importer ces mots dans un autre appareil ne change rien. Générez une nouvelle seed et transférez vos bitcoins par une transaction classique.
Analyse éditoriale GhostlyInc
Nous ne choisirions pas COLDCARD pour un nouveau portefeuille aujourd’hui
Une faille dans la génération de seed est restée présente sur un chemin critique pendant des années, et la première analyse publique n’a pas couvert tous les modèles. Cela réduit fortement notre confiance. Pour un nouvel achat, nous privilégierions actuellement un autre appareil après avoir vérifié la génération de seed, le modèle de récupération, l’historique d’audit, le support firmware et la transparence du code.
Il s’agit d’un avis éditorial actuel, pas d’une affirmation que tous les COLDCARD sont vulnérables ou qu’aucun autre wallet n’est inviolable.
Actions de Coinkite après la révélation
- Détails techniques publiés et instructions concrètes de migration.
- Publication d’un firmware corrigé pour les modèles et branches concernés.
- Des vérifications de compilation ont été ajoutées et une validation indépendante ciblée de la correction a été obtenue.
- Indique que le stock restant avec firmware vulnérable a été détruit et les expéditions stoppées.
Ces réponses sont importantes, mais n’effacent ni la gravité ni les années où des seeds faibles ont pu être générées.
Choisir une alternative
Comparez les modèles de confiance avant achat
Trezor, BitBox, Blockstream Jade, Bitkey et Ledger reposent sur des matériels, firmwares, sauvegardes et modèles de confiance différents. Cet incident ne fait pas d’eux des gagnants par défaut. Comparez les critères ci-dessous et achetez uniquement auprès du fabricant ou d’un revendeur agréé vérifié.
Trezor Safe 3 : notre choix économique
Le Safe 3 associe une interface à deux boutons intuitive, un design open source et un Secure Element EAL6+ qui gère l’authentification de l’appareil et ajoute une entropie indépendante. Optez pour l’édition Bitcoin uniquement si vous n’utilisez pas d’autres cryptomonnaies.
Trezor Safe 5 : notre choix ergonomique
Le Safe 5 reprend le même Secure Element que le Safe 3, mais son écran tactile couleur et son retour haptique facilitent la configuration, la saisie de sauvegarde et la vérification des transactions. Un écran plus grand ne dispense toutefois pas de vérifier l’adresse complète.
Ces liens sont affiliés et peuvent nous rapporter une commission sans frais supplémentaires pour vous. Ils ouvrent la boutique Amazon de votre région. Achetez uniquement auprès de la boutique officielle Trezor ou d’un revendeur agréé, puis vérifiez l’emballage et l’authenticité de l’appareil avant toute configuration.
Leçons au-delà d’un seul fabricant
Un hardware wallet est un système, pas une garantie de sécurité
L’aléa est au cœur de la confiance
Le chiffrement fort et le stockage sécurisé ne peuvent rien pour une clé prévisible dès sa création.
La composition doit être testée
Un composant sécurisé n’est utile que si le binaire final l’utilise réellement. Les résultats de compilation doivent être vérifiés directement.
L’open source améliore la transparence, pas la certitude
Le code public permet une relecture indépendante, mais ne garantit pas que chaque erreur critique d’intégration sera détectée à temps.
Les plans de récupération doivent prévoir la migration
Une sauvegarde restaure les mêmes clés. Si ces clés sont vulnérables, la récupération consiste à générer de nouvelles clés et à transférer les fonds.
Sources et vérifications
Recommandations et éléments sur l’incident
Les recommandations firmware peuvent évoluer. Nous avons vérifié l’état, les instructions de migration, l’explication technique et les rapports indépendants au 18 août 2026. Consultez l’état officiel avant d’agir.
Questions fréquentes
Mettre à jour le firmware COLDCARD rend-il ma seed existante sûre ?
Non. Le firmware corrigé ne concerne que la génération des futures seeds. Il ne modifie pas une seed existante ni les clés privées qui en découlent. Si la seed a été créée sur un firmware vulnérable, suivez la migration recommandée sauf si l’exception des dés indépendants s’applique clairement.
Quelles versions du firmware COLDCARD corrigent le problème RNG ?
Les versions minimales corrigées sont : Mk2/Mk3 4.2.0, Mk4/Mk5 standard 5.6.0, Q standard 1.5.0Q, Mk4/Mk5 Edge 6.6.0X et Q Edge 6.6.0QX. Vérifiez l’état officiel avant toute nouvelle seed.
Puis-je résoudre le problème en important la seed dans un autre hardware wallet ?
Non. Le nouvel appareil générerait les mêmes clés privées à partir des mêmes mots. Créez une nouvelle seed et transférez vos bitcoins vers une adresse de ce nouveau portefeuille.
Des lancers de dés rendent-ils ma seed COLDCARD sûre ?
Coinkite précise que l’exception nécessite au moins 50 lancers de dés équitables, indépendants et privés lors de la création de la seed, sans que la séquence n’ait jamais été enregistrée ou exposée. En cas de doute, suivez la migration conservatrice.
Les attaquants ont-ils cassé Bitcoin ou ECDSA ?
Non. L’incident concerne une faible entropie lors de la création des clés. Bitcoin a accepté des signatures valides issues d’un espace de possibilités réduit.
Peut-on acheter COLDCARD en toute sécurité aujourd’hui ?
Les versions corrigées intègrent la solution publiée, mais aucun hardware wallet n’est sans risque et cet incident a entamé notre confiance. GhostlyInc choisirait actuellement un autre appareil pour un nouvel achat, après comparaison de l’architecture de sécurité, du modèle de récupération, des audits, du support firmware et de l’ergonomie.