Retour au blog
CVEcryptomenacetechnique

ColdCard PRNG : comment un bug firmware a permis un vol de 70 millions $ de Bitcoin en 41 minutes

Publié le 2026-08-017 min de lectureCleanIssue

> En bref : Une erreur d'intégration firmware introduite en mars 2021 a redirigé la génération de seed de ColdCard vers un générateur de nombres pseudo-aléatoires (PRNG) logiciel déterministe, au lieu du générateur matériel RNG du STM32. Le 30 juillet 2026, un attaquant a exploité cette faille pour drainer 1 082,65 BTC (~70 millions $) sur 1 196 adresses en 41 minutes. Galaxy Research a cartographié le sweep. Coinkite a livré un firmware d'urgence le 31 juillet pour tous les modèles affectés — mais l'installer ne répare pas une seed déjà générée.

Pourquoi ça vous concerne

Vous ne vendez probablement pas de portefeuilles hardware. Mais cette histoire est l'illustration la plus nette en 2026 d'une classe de défaillance qui touche tout produit SaaS qui génère des secrets : la différence entre une source aléatoire cryptographique et une source déterministe, c'est la différence entre un secret et une valeur publique. Le bug ColdCard est, à la racine, la même classe de faille que d'utiliser Math.random() pour des tokens de session, de seed un PRNG depuis une horloge prévisible, ou de générer des clés API depuis un non-CSPRNG. La version SaaS ne fait simplement pas les titres parce que le vol est plus discret.

Si votre produit génère un secret quelconque — clés API, tokens de session, liens de reset de mot de passe, clés de signature — ce cas est votre conte morale.

La faille en deux phrases

ColdCard est un portefeuille hardware Bitcoin-only fabriqué par la société canadienne Coinkite. Il utilise un microcontrôleur STM32 avec un RNG matériel dédié. En mars 2021, une erreur d'intégration firmware a fait que le code de génération de seed appelait un PRNG logiciel déterministe au lieu du RNG matériel. La sortie du PRNG logiciel peut être reproduite hors ligne si l'attaquant peut déterminer ou suffisamment contraindre trois valeurs : l'UID du device, l'état du timer au moment de la génération, et l'historique des appels RNG précédents.

Block (anciennement Blockstream) a démontré que des seeds candidates peuvent être générées hors ligne puis vérifiées en dérivant leurs adresses Bitcoin et en les comparant aux données publiques de la blockchain. Vous n'avez pas besoin du device physique — vous avez besoin des paramètres qui ont nourri le PRNG, puis vous pouvez brute-forcer les seeds candidates et les vérifier contre le registre public.

Le sweep de 41 minutes

Le 30 juillet 2026, un attaquant qui avait pré-calculé les seeds vulnérables a drainé 1 196 adresses Bitcoin en 41 minutes, prenant 1 082,65 BTC. Galaxy Research a cartographié les transactions et les a reliées à la faille PRNG de ColdCard. La vitesse (41 minutes) indique que l'attaquant avait fait le calcul hors ligne à l'avance — les adresses étaient déjà identifiées, le sweep n'était que l'exécution.

C'est le scénario du pire pour une faille de génération de seed : l'attaquant n'a pas besoin d'interagir avec une victime, n'a pas besoin d'accès réseau au wallet, et ne laisse pas de trace sur le device. Les fonds se déplacent, c'est tout.

La réponse

Coinkite a livré un firmware d'urgence le 31 juillet pour tous les modèles et tracks de release affectés. Mais le détail critique : installer le firmware corrigé ne répare pas une seed existante. Une seed générée sur une version firmware vulnérable reste faible pour la durée de vie de ce wallet. Coinkite dit aux propriétaires affectés de générer une nouvelle seed sur un firmware corrigé et de migrer leurs fonds.

La fenêtre de vulnérabilité est énorme : mars 2021 à juillet 2026 — plus de cinq ans de seeds générées sur des versions firmware affectées.

La leçon pour les éditeurs SaaS

Trois principes, directement portables depuis ce cas :

  • Vérifiez votre source d'aléatoire à l'exécution, pas seulement à l'intégration. Le bug ColdCard est resté non détecté pendant cinq ans parce que le code *avait l'air* d'appeler le RNG matériel — l'erreur d'intégration l'a silencieusement redirigé. Dans un produit SaaS, ajoutez un self-test au démarrage qui vérifie que le CSPRNG produit bien une sortie à haute entropie. Un mauvais import, une mise à jour de dépendance, ou un changement de config peuvent silencieusement permuter votre source aléatoire.
  • Traitez le registre public comme un oracle. Dans le cas ColdCard, l'attaquant a validé les seeds candidates en vérifiant les adresses dérivées contre la blockchain. L'équivalent SaaS : si vos secrets (clés API, tokens) peuvent être observés ou brute-forcés contre un endpoint public, l'attaquant a un oracle. Rate-limitez les endpoints de validation, utilisez des secrets à haute entropie (minimum 256 bits depuis un CSPRNG), et rotater au moindre soupçon.
  • Un correctif ne rétroactive pas les secrets déjà générés. La leçon opérationnelle la plus importante : quand vous corrigez une faille de génération de secrets, les secrets existants sont toujours vulnérables. Vous devez rotater chaque secret généré pendant la fenêtre de vulnérabilité — pas seulement déployer le fix. Pour un produit SaaS, ça veut dire rotation forcée de chaque clé API, token de session, et clé de signature émis entre l'introduction du bug et le fix.
  • Le pattern plus large

    La faille PRNG de ColdCard rejoint une lignée de défaillances d'aléatoire — depuis Debian OpenSSL (CVE-2008-0166, 2008) jusqu'à la vulnérabilité Android Secure Random (2013) en passant par les tokens prévisibles de l'API server Kubernetes. Dans chaque cas, le code paraissait correct mais utilisait silencieusement une source d'entropie non critique. La défense est la même partout : vérifiez votre RNG, testez la sortie, et rotater les secrets quand vous découvrez l'écart.

    Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.

    Articles liés

    Trois analyses proches pour continuer la lecture sur la meme surface de risque.

    IA & LLMAI agents

    Agent IA Hermes en mode YOLO : l'attaque du ministère thaï des Finances

    Un acteur de menace a fait tourner l'assistant IA open-source Hermes en mode 'YOLO' non surveillé contre le ministère des Finances de Thaïlande, automatisant le post-exploitation : sondage d'hôtes, tentatives d'escalade de privilèges, crawling de dossiers salariés. Les logs de l'attaquant ont été laissés exposés. Un cas réel d'agents IA comme outil offensif.

    2026-07-24 · 6 min de lecture
    CVEsupply chain

    Ver npm sur les packages de mailing : quand un client MCP « postmark » exfiltre discrètement vos emails transactionnels

    Un package npm largement utilisé pour envoyer des emails transactionnels (confirmations de compte, factures, réinitialisations de mot de passe) est compromis avec une porte dérobée en une ligne qui met en copie cachée chaque email sortant vers un serveur contrôlé par l'attaquant. Des dizaines de SaaS RH et paie qui envoient des bulletins de salaire par email sont exposés sans le savoir.

    2026-07-26 · 6 min de lecture
    CVEMicrosoft

    Bing Images CVE-2026-32194 : un SVG forgé qui tourne en SYSTEM sur les serveurs de Microsoft

    Deux failles critiques (CVE-2026-32194, CVE-2026-32191, toutes deux CVSS 9.8) dans le tier de traitement d'images de Bing permettaient à un SVG forgé d'exécuter des commandes en tant que NT AUTHORITY\SYSTEM sur les workers Windows et root sur les workers Linux. Trouvé par XBOW, corrigé côté serveur par Microsoft en mars 2026, détails publiés le 23 juillet.

    2026-07-24 · 6 min de lecture

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit