#Web3SecurityGuide Les estimations des pertes liées à la faille de sécurité du portefeuille matériel Coldcard ont rapidement dépassé $130 millions, et l’origine du problème réside dans un détail frappant : la faille est passée inaperçue pendant cinq ans.

Selon le suivi le plus récent de Galaxy Research, les pertes liées à Coldcard atteignent 2,055 BTC, soit environ $130 millions, et concernent plus de 7 700 adresses. On estime qu’entre douze et quinze attaquants différents ont exploité indépendamment la même vulnérabilité, un chiffre largement confirmé par le cofondateur d’Elliptic dans une interview accordée à TechCrunch. L’attaque s’est déroulée par vagues ; la première a permis de retirer à elle seule 1 082 BTC d’environ 1 196 adresses en seulement quarante et une minutes, suivie de trois vagues supplémentaires qui ont porté les pertes totales à leur niveau actuel.

L’origine technique de la vulnérabilité est véritablement remarquable. Le problème remonte à la version 4.0.1 du micrologiciel, publiée en mars 2021, qui a conduit certains appareils à rediriger la génération de la seed depuis un générateur matériel de nombres aléatoires vers un mécanisme de secours déterministe utilisant MicroPython. Cela signifie que les portefeuilles créés avec les versions 4.0.1 à 4.1.9 du micrologiciel ont pu générer des clés privées prévisibles au moyen d’attaques par force brute pendant environ cinq ans sans que cela soit détecté. Cette faille a été découverte dans le cadre d’une enquête conjointe menée par les équipes d’ingénierie du fabricant Coinkite et de Block.

Comme vous l’avez mentionné, cet incident démontre avec une clarté extrême que les clés privées constituent toujours un point de défaillance unique pour les actifs crypto. Selon les termes du PDG de Blockaid, il s’agit du « péché originel » du secteur, car Coldcard a précisément été conçu pour éliminer les risques propres aux appareils connectés à Internet en conservant les clés privées hors ligne, mais la vulnérabilité était dissimulée dans le processus même de génération des clés de l’appareil. Même si la plupart des victimes ont suivi toutes les bonnes pratiques de sécurité documentées, elles n’étaient pas protégées contre cette cause fondamentale de la vulnérabilité.

Un autre effet secondaire important de l’incident est que l’attaque elle-même a déclenché une vague d’hameçonnage. Des fabricants rivaux de portefeuilles matériels comme Trezor et Foundation ont signalé une hausse des campagnes d’hameçonnage tentant d’exploiter la vulnérabilité de Coldcard, avec des campagnes utilisant de faux sites d’« audit matériel » pour dérober les phrases de récupération des victimes, ainsi que des bots se faisant passer pour de véritables représentants du service client. Selon les données de TRM Labs, environ 76 % de la valeur dérobée lors de piratages crypto au premier semestre 2026 provenait de failles d’infrastructure et de failles opérationnelles, en particulier du vol de clés privées et de phrases de récupération, ce qui indique que l’incident Coldcard n’était pas un cas isolé, mais s’inscrivait dans une tendance plus large.

Cet événement justifie un appel aux fabricants de portefeuilles matériels afin qu’ils réévaluent leurs processus de développement logiciel, la sécurité de leur chaîne d’approvisionnement et la formation des utilisateurs. Bien que le code open source et les audits indépendants renforcent la sécurité, ils n’offrent aucune garantie, comme le démontre cet incident, une erreur de régression restée indétectée pendant cinq ans en étant la preuve la plus évidente.

Pour les utilisateurs qui stockent des bitcoins sur des portefeuilles matériels via Gate, la mesure pratique à prendre est la suivante : tout appareil Coldcard ayant généré une seed avec une version du micrologiciel comprise entre 4.0.1 et 4.1.9 est considéré comme potentiellement compromis, et les fonds doivent être transférés vers un nouveau portefeuille avec une phrase de récupération régénérée sur un micrologiciel mis à jour ; il ne suffit pas d’appliquer un correctif au micrologiciel pour sécuriser une seed déjà vulnérable. Pendant cette période, il est également nécessaire de se méfier de tout message contenant des « contrôles de sécurité » ou des demandes d’assistance, et la phrase de récupération ne doit en aucun cas être communiquée à un tiers.

Faites vos propres recherches 🔎