Les portefeuilles matériels reposent sur une promesse simple : gardez les clés hors ligne, et les attaquants ne peuvent pas les atteindre.
Le piratage de Coldcard a brisé cette hypothèse.
Une faille a rendu certaines phrases de récupération prévisibles dès leur création, permettant de voler des Bitcoin alors que les portefeuilles restaient hors ligne et physiquement protégés.
Cette semaine, nous voyons comment l’incident a ébranlé la confiance dans l’auto-garde du Bitcoin et poussé certains détenteurs à revenir vers les plateformes d’échange. Nous examinons ensuite la défaillance technique qui a rendu les clés prévisibles, et pourquoi mettre à jour un portefeuille touché ne peut pas sécuriser des clés déjà créées.
Au sommaire également : un ver npm qui se propage seul, un zero-day Metabase, un contournement de Screen Sharing sur macOS, une faille exploitée de LoadMaster, des routeurs dotés d’une porte dérobée, LLVM pour les tests de sécurité, un e-mail suspect de renouvellement du SSO GitHub, et plus encore.
Dans ce numéro
🌡️ Niveau de menace : alerte élevée
⚡ Actualités : cinq histoires de sécurité à ne pas manquer
🔎 Analyse approfondie : comment le piratage de Coldcard a ébranlé la confiance dans l’auto-garde du Bitcoin
🎣 Est-ce du phishing ?
🔬 Recherche technique : le portefeuille est resté hors ligne. L’attaquant a quand même trouvé la clé.
🛠️ Outil de la semaine : LLVM
👤 Personnalité de la semaine : Andrea Fioraldi
📅 Événement de la semaine : Ekoparty Security Conference 2026
📚 Livre de la semaine : Black Hat GraphQL
😅 Le mème
❓ Une question avant de partir
C’est parti.
Avant d’entrer dans les histoires de la semaine, voici où en est le niveau de menace.
🌡️Niveau de menace
⚡ Actualités
Plus de 400 paquets npm transformés en ver auto-propagateur
ChainDrop a infecté des paquets JavaScript populaires grâce à des identifiants de publication volés. Le malware s’exécutait pendant l’installation, cherchait sur les postes de développeurs et les systèmes CI/CD des secrets npm, GitHub, cloud et d’infrastructure, puis utilisait les jetons volés pour infecter automatiquement d’autres paquets. Microsoft a identifié plus de 400 paquets touchés. Unit 42 a trouvé 453 dépôts GitHub publics correspondant aux schémas de vol de données du ver et a observé son exécution dans dix environnements.
Des jetons volés infectent les systèmes des développeurs et la CI.
Un zero-day Metabase a transformé la réinitialisation de mot de passe en accès administrateur
Metabase a confirmé que des attaquants avaient exploité une faille d’injection SQL jusque-là inconnue contre son service cloud. L’endpoint vulnérable de réinitialisation de mot de passe permettait à des attaquants distants sans identifiants d’obtenir un accès administrateur, pouvant exposer les identifiants et les données des bases connectées. Metabase a corrigé sa plateforme cloud et publié des correctifs pour les versions auto-hébergées. Framework, Tally et Kilo Code ont ensuite signalé une exposition de coordonnées de clients, de hachages de mots de passe ou de jetons d’accès Slack.
Le contournement de la réinitialisation de mot de passe expose les bases de données connectées.
Aucun mot de passe valide requis : Apple corrige un contournement de Screen Sharing sur macOS
Apple a révélé qu’un attaquant sur le même réseau pouvait s’authentifier à Screen Sharing sur macOS sans identifiants valides. La vulnérabilité, référencée CVE-2026-65400, fonctionnait avant l’authentification et touchait les systèmes où Screen Sharing était activé. Huntress a constaté que changer le mot de passe VNC ou restreindre les utilisateurs autorisés n’empêchait pas l’exploitation. Apple a corrigé la faille le 6 août dans macOS Tahoe 26.6.1, Sequoia 15.7.9 et Sonoma 14.8.9.
Un attaquant local contourne l’authentification de Screen Sharing.
La CISA a donné trois jours aux agences pour corriger une faille exploitée de LoadMaster
CVE-2026-8037 touche Progress Kemp LoadMaster, un produit qui répartit le trafic entre applications et serveurs. La faille permet à un attaquant distant sans identifiants d’exécuter des commandes du système d’exploitation via une entrée insuffisamment vérifiée envoyée à l’appliance. Progress a publié des correctifs pour les versions touchées. La CISA a ajouté la vulnérabilité à son catalogue Known Exploited Vulnerabilities le 7 août et fixé au 10 août la date limite de remédiation pour les agences fédérales.
Une requête non authentifiée exploite un répartiteur de charge vulnérable.
Plus de 20 modèles de routeurs livrés avec une porte dérobée de niveau root activée par défaut
VulnCheck a découvert un implant de contrôle à distance nommé ENDLESSDOORS dans des routeurs vendus sous les marques Zbtlink et Wiflyer. Le logiciel contacte une infrastructure externe et peut exécuter des commandes avec tous les privilèges système sans authentifier le serveur. VulnCheck estime qu’au moins 100 000 routeurs touchés pourraient être déployés dans le monde. Le 6 août, Zbtlink a déclaré que l’implant était un outil d’assistance, suspendu la vente des routeurs touchés, retiré le firmware et commencé à développer des mises à jour.
Un implant intégré permet le contrôle à distance des routeurs.
🔎 Analyse approfondie
Comment le piratage de Coldcard a ébranlé la confiance dans l’auto-garde du Bitcoin
Des pirates ont volé environ 130 millions de dollars en Bitcoin dans des portefeuilles matériels Coldcard, ce qui en fait le troisième plus gros piratage de cryptomonnaie de 2026.
Les portefeuilles matériels reposent sur une promesse simple : gardez les clés hors ligne, et les attaquants distants ne peuvent pas les atteindre. Il n’y a pas de compte à compromettre, pas de serveur qui détient le secret et aucun moyen d’entrer sans la phrase de récupération ou l’appareil physique.
Le vol de Coldcard a brisé cette promesse.
Les portefeuilles sont restés hors ligne, mais les Bitcoin ont tout de même été volés. Cela a révélé une faiblesse dans l’un des principaux outils sur lesquels les gens comptent pour l’auto-garde du Bitcoin.
L’auto-garde consiste à détenir les clés de ses propres Bitcoin au lieu d’en laisser le contrôle à une plateforme d’échange ou à une autre entreprise. Les portefeuilles matériels créent et stockent ces clés hors ligne, où elles sont censées rester hors de portée des attaquants en ligne.
Coldcard était un portefeuille matériel dédié au Bitcoin, bien établi et réputé pour sa sécurité. Pourtant, une faille dans la façon dont certains appareils généraient les phrases de récupération rendait leurs clés prévisibles dès leur création. Les attaquants pouvaient reconstituer ces clés et accéder aux fonds sans déjouer les protections physiques des portefeuilles.
La vraie question est donc :
Que se passe-t-il quand l’appareil censé protéger l’auto-garde devient son maillon le plus faible ?
L’auto-garde supprime le dépositaire, pas la confiance
On choisit l’auto-garde pour ne pas avoir à faire confiance à une plateforme d’échange ou à une institution financière pour ses Bitcoin. Mais contrôler les clés privées signifie aussi les protéger correctement.
Avant les portefeuilles matériels, cela passait souvent par des portefeuilles papier ou des ordinateurs maintenus en permanence hors ligne. Les portefeuilles matériels ont transformé ces montages compliqués en un appareil dédié qui créait les clés et les gardait hors ligne.
Cela a rendu l’auto-garde praticable, mais n’a pas supprimé la confiance. Elle a simplement été déplacée de l’institution qui détient les Bitcoin vers le fabricant qui construit le portefeuille.
La plupart des utilisateurs ne peuvent pas vérifier comment leur appareil crée ses clés. Ils doivent croire que le fabricant a traité correctement la partie la plus importante.
Le piratage de Coldcard a fait douter de l’auto-garde
Coldcard était l’un des rares portefeuilles matériels dédiés au Bitcoin bien établis. Il était devenu une option de confiance pour ceux qui voulaient garder leurs clés Bitcoin hors ligne et hors d’une plateforme d’échange.
Cette réputation a rendu le piratage plus significatif.
Le rôle de Coldcard ne se limitait pas à garder ces clés hors ligne. Les utilisateurs comptaient sur lui pour les créer de façon sûre dès le départ. Si cette étape échouait à l’insu du propriétaire, toutes les protections suivantes étaient construites autour d’une clé vulnérable.
Une victime a indiqué à Galaxy Research que son Coldcard était resté dans un coffre-fort de banque et ne s’était jamais connecté à Internet. Des attaquants ont tout de même volé 18,25 BTC en sept minutes. L’appareil était resté physiquement protégé, mais la clé qu’il avait créée ne l’était pas.
Le risque venait du produit que les gens avaient choisi pour se protéger.
La réaction s’est propagée dans les communautés Bitcoin et Coldcard sur Reddit. Un utilisateur a dit avoir perdu des Bitcoin dans l’exploit, tandis qu’un autre a dit quitter Coldcard.
Dans une autre discussion, un propriétaire de Ledger s’est interrogé sur toutes les entreprises de portefeuilles matériels, tandis que des commentateurs débattaient d’un passage aux ETF, à Fidelity, Binance ou Coinbase.
Ces messages ne prouvent pas un changement plus large, mais ils montrent que le retour vers des tiers faisait déjà partie du débat.
Coldcard a poussé certains détenteurs de l’auto-garde vers les plateformes d’échange
Après l’exposition de la faille, les détenteurs inquiets pour leurs clés vulnérables ont dû décider où déplacer leurs Bitcoin. Ils pouvaient faire confiance à un autre portefeuille matériel ou laisser une plateforme d’échange protéger les clés à leur place.
Les données on-chain donnent une vue partielle de la suite. Le 31 juillet, près d’un million d’adresses Bitcoin ont envoyé ou reçu des fonds, contre 645 000 la veille, selon CryptoQuant. Ce pic montrait une ruée pour déplacer des Bitcoin, mais pas ce qui a causé chaque transfert ni où les fonds sont allés.
Les dépôts sur les plateformes d’échange donnent un indice plus net. Le même jour, les gens ont déposé plus de Bitcoin sur les plateformes qu’ils n’en ont retiré. La différence était de 11 163 BTC, selon CoinDesk. La plupart sont allés vers Binance, River, Kraken et OKX.
Tous les dépôts ne peuvent pas être reliés à Coldcard. Mais le calendrier suggère que certains détenteurs ont choisi une plateforme d’échange plutôt qu’un autre portefeuille en auto-garde.
Les plateformes d’échange comportent toutefois leurs propres risques. Beaucoup de détenteurs de Bitcoin choisissent l’auto-garde parce que les plateformes ont été piratées ou se sont effondrées à plusieurs reprises. En 2025, par exemple, des attaquants ont volé environ 1,5 milliard de dollars à la plateforme Bybit.
Pour les détenteurs revenus vers les plateformes, ce choix a levé l’incertitude immédiate autour de Coldcard. Mais il n’a pas supprimé le besoin de confiance. Il a simplement déplacé cette confiance du fabricant du portefeuille vers une plateforme chargée de protéger leurs clés et de leur donner accès à leurs Bitcoin.
Coldcard n’a pas prouvé que l’auto-garde est morte. Il a montré que posséder ses clés signifie toujours faire confiance aux outils qui les créent.
Qu’est-ce qui fait qu’un portefeuille matériel est sûr ?
Coldcard avait une solide réputation. Mais une réputation reflète ce qu’un produit a déjà traversé. Elle ne montre pas quelles parties de sa sécurité ont été testées de manière indépendante.
Des termes comme open source, air-gapped (conçu pour fonctionner sans connexion directe à Internet) et secure element (une puce conçue pour protéger les clés secrètes) peuvent donner à un portefeuille un air de confiance. Ce sont des fonctionnalités utiles, mais elles ne prouvent pas que le produit complet est sûr.
Le code public doit encore être relu, et une puce certifiée ne qualifie pas automatiquement le logiciel chargé de créer et de protéger les clés.
Une qualification formelle de sécurité identifie le produit et la version logicielle exacts testés, les menaces incluses et l’organisation qui a réalisé l’évaluation.
La certification ANSSI du Ledger Nano S Plus, par exemple, ne s’applique qu’à la version et à la configuration évaluées. Sa cible de sécurité inclut des menaces comme la génération de nombres aléatoires prévisibles et les mises à jour de firmware malveillantes. Elle montre ce qui a été testé, mais ne garantit pas la sécurité de chaque version future.
Coldcard montre pourquoi c’est important. Sa faiblesse a été introduite par le firmware et touchait la façon dont les phrases de récupération étaient créées. Une revue du seul matériel l’aurait manquée, tandis qu’une revue achevée avant la publication du firmware vulnérable n’aurait plus suffi.
Une qualification significative doit donc couvrir le matériel, le firmware, la génération des clés et le processus de mise à jour. Elle doit aussi être répétée quand une mise à jour change la façon dont les clés sont créées ou protégées.
L’auto-garde supprime le besoin de faire confiance à une plateforme d’échange. Elle ne doit pas remplacer cette confiance par des affirmations que les utilisateurs ne peuvent pas vérifier. La sécurité d’un portefeuille matériel exige des preuves claires, et ces preuves doivent être renouvelées quand le produit change.
🎣 Est-ce du phishing ?
Cliqueriez-vous pour renouveler votre accès SSO GitHub ?
🔬 Recherche technique
Le portefeuille est resté hors ligne. L’attaquant a quand même trouvé la clé.
Les vols signalés de COLDCARD en juillet 2026 ont exposé le mode de défaillance de l’autre côté du stockage à froid. Les attaquants n’ont pas eu besoin de compromettre l’appareil, d’intercepter une transaction, de pousser les utilisateurs à approuver un paiement ni de voler des phrases de récupération dans une sauvegarde. Les informations publiques relient l’incident à une génération faible des seeds dans le firmware touché : les portefeuilles étaient hors ligne, mais l’espace des seeds possibles était assez petit pour être exploré.
Le premier balayage largement documenté a déplacé environ 1 082,65 BTC depuis 1 196 portefeuilles Coldcard en 41 minutes le 30 juillet, soit environ 70 millions de USD à l’époque. Des analyses ultérieures ont porté le total signalé à environ 1 755 BTC répartis sur environ 5 000 portefeuilles, ce qui place la perte près de 116 millions de USD, bien que l’estimation ait continué à évoluer à mesure que les chercheurs regroupaient d’autres transactions.
L’appareil n’a pas fait fuiter la clé après sa génération.
La clé semble avoir été devinable dès le départ.
Les attaquants n’ont pas eu à pénétrer dans le portefeuille. Ils ont exploré ailleurs l’espace de seeds réduit, trouvé des adresses contenant des bitcoin et recréé les clés sur leurs propres machines.
Là où l’aléa est devenu la frontière de sécurité
Un portefeuille Bitcoin ne stocke pas un tas de clés privées sans lien entre elles. Il part d’une entropie : une entrée aléatoire encodée sous forme de phrase de récupération. À partir de la même phrase de récupération et d’une passphrase facultative, BIP-39 produit toujours le même seed, dont le portefeuille dérive sa clé maîtresse, ses clés privées, ses clés publiques et ses adresses.
Cette reproductibilité est voulue. C’est elle qui permet aux mêmes mots de récupération de reconstruire le même portefeuille des années plus tard sur un autre appareil compatible.
Elle crée aussi une règle stricte : quiconque reconstitue le même seed reconstitue le même portefeuille.
Normalement, c’est irréaliste sur le plan du calcul. Une phrase BIP-39 de 12 mots correctement générée représente 128 bits d’entropie, et une phrase de 24 mots, 256 bits. Les espaces de recherche sont si vastes qu’essayer toutes les possibilités n’est pas une attaque praticable.
Mais les mots ne créent pas l’aléa. Ils ne font que l’encoder.
Si le générateur de nombres aléatoires ne peut produire qu’un sous-ensemble limité ou prévisible de valeurs possibles, une phrase de récupération peut sembler normale tout en représentant beaucoup moins d’incertitude que sa longueur ne le suggère. Vingt-quatre mots correctement orthographiés ne valent pas automatiquement 256 bits de sécurité. Ils ne sont aussi solides que le processus qui les a choisis.
C’est la frontière que l’incident COLDCARD semble avoir brisée.
Le repli qui n’aurait jamais dû être possible
COLDCARD publie son dépôt de firmware et prend en charge les builds reproductibles, ce qui permet d’inspecter directement ce chemin de code.
Dans le firmware 4.0.0, COLDCARD a changé la génération des nouveaux portefeuilles : on est passé de son propre chemin d’aléa matériel ckcc.rng_bytes à random.bytes(32), un wrapper autour de la nouvelle bibliothèque libNgU. L’implémentation prévue de libNgU devait utiliser le générateur de nombres aléatoires matériel du STM32.
Une erreur de configuration du build a fait échouer cette intention. LibNgU vérifiait seulement si le paramètre du RNG matériel existait, tandis que MicroPython vérifiait s’il était activé. Le paramètre existait mais valait 0 : la vérification de libNgU passait donc, alors que MicroPython compilait rng_get() comme son repli logiciel.
Ce repli était initialisé à partir de valeurs propres à l’appareil et de valeurs de temps, pas d’une entropie secrète fraîche suffisante. En conséquence, des seeds d’apparence normale pouvaient provenir d’un ensemble de possibilités bien plus petit et énumérable. L’impact exact variait selon la génération d’appareil ; l’avis actuel de Coinkite est la source de référence pour les modèles et les plages de firmware touchés.
La chaîne d’appels qui en résultait ressemblait à ceci :
make_new_wallet()
↓
random.bytes(32)
↓
ngu.random.bytes()
↓
my_random_bytes()
↓
CHIP_TRNG_32()
↓
rng_get() C’est dans ce dernier nom de fonction que l’implémentation et l’hypothèse se sont séparées.
La configuration de la carte COLDCARD définissait MICROPY_HW_ENABLE_RNG à 0 parce que le projet incluait sa propre implémentation de RNG matériel. LibNgU essayait de s’assurer qu’un RNG matériel STM32 était disponible, mais sa garde à la compilation vérifiait seulement si MICROPY_HW_ENABLE_RNG était défini. Elle ne vérifiait pas si la valeur était activée.
Comme la macro existait, libNgU a accepté le build et a associé CHIP_TRNG_32() à rng_get() de MicroPython. Comme la valeur de la macro était zéro, MicroPython a compilé l’autre implémentation de rng_get() : un PRNG logiciel Yasmarang prévu pour les cibles STM32 sans RNG matériel activé.
Le paramètre existait avec la valeur 0. Cela suffisait pour passer la vérification d’existence de libNgU, mais la vérification de valeur de MicroPython a compilé le repli logiciel au lieu de l’implémentation du RNG matériel.
Le repli initialisait son état interne à partir des 32 premiers bits de l’identifiant unique de la puce, combinés par XOR avec le compteur SysTick courant, plus deux registres de l’horloge temps réel. Ces entrées peuvent varier, mais elles n’équivalent pas à 256 bits d’entropie secrète fraîche. LibNgU combinait cette sortie par XOR avec un second flux Yasmarang dont l’état partait de constantes fixes. Mélanger un autre flux déterministe change la sortie ; cela n’ajoute pas d’entropie inconnue.
Cette distinction est essentielle.
Un TRNG matériel mesure un processus physique destiné à fournir une entropie fraîche et imprévisible. Un PRNG logiciel étend un état interne en valeurs qui paraissent aléatoires. Un PRNG cryptographiquement sûr peut être sûr s’il part d’assez d’entropie secrète et est réinitialisé correctement. Un petit repli déterministe initialisé avec des valeurs comme des identifiants d’appareil et l’état d’un minuteur n’est pas un remplacement acceptable pour générer le secret maître d’un portefeuille.
Le plus dangereux n’était pas qu’un générateur logiciel existe. C’était que le chemin de production pouvait l’utiliser silencieusement pour une opération critique pour la sécurité.
Deux vérifications locales rendaient la sortie plus rassurante sans réparer la perte d’entropie. La création du seed vérifiait que les 32 octets générés contenaient plus de quatre valeurs distinctes, ce qui peut détecter un générateur bloqué mais ne permet pas de distinguer une sortie prévisible d’une sortie cryptographiquement aléatoire. Elle hachait ensuite les 32 octets avec SHA-256 pour atténuer le biais. Le hachage peut répartir uniformément une entrée biaisée sur la sortie, mais il ne peut pas créer des possibilités absentes du générateur d’origine. Si un attaquant peut énumérer les entrées, il peut aussi hacher chaque candidat.
Le portefeuille affichait toujours une phrase de récupération valide. La somme de contrôle fonctionnait toujours. Les adresses étaient dérivées normalement. Les transactions étaient signées normalement. Rien dans l’expérience utilisateur n’annonçait que le seed venait d’un espace de recherche bien plus petit.
La défaillance était silencieuse, persistante et irréversible pour chaque portefeuille créé à partir de l’aléa touché.
Comment une attaque par force brute hors ligne devient un vol
Une fois le comportement du RNG compris, le portefeuille physique n’est plus nécessaire.
Un attaquant peut reproduire le générateur faible, énumérer ses états internes plausibles et convertir chaque sortie en phrases de récupération candidates. À partir de chaque candidate, il dérive les clés et adresses Bitcoin correspondantes.
La blockchain fournit la couche de vérification.
Les adresses Bitcoin et leurs soldes sont publics. L’attaquant n’a pas besoin d’interroger la victime, de se connecter à un service ni de déclencher une alerte sur le portefeuille matériel. Il compare les adresses dérivées à l’historique de la blockchain et garde les candidates qui correspondent.
Quand un seed candidat dérive une adresse contenant des bitcoin, la recherche est terminée. L’attaquant détient désormais la même autorité de signature que le propriétaire d’origine du portefeuille. Il peut recréer le portefeuille sur son propre système et produire une transaction que le réseau Bitcoin considère comme parfaitement valide.
Il n’y a pas de signature falsifiée que le réseau pourrait rejeter. Pas d’échec de mot de passe. Pas de flux d’authentification anormal.
L’attaquant a la clé.
Pourquoi 41 minutes ne décrivent pas toute l’attaque
Le chiffre le plus spectaculaire des informations publiées est la fenêtre de 41 minutes pendant laquelle plus de mille bitcoin ont été déplacés.
C’était probablement la phase d’exécution, pas le début du travail.
Énumérer les seeds candidats, dériver leurs adresses, vérifier leurs historiques et prioriser les cibles approvisionnées pouvait se faire avant l’apparition de la première transaction de vol. Le balayage rapide suggère que l’attaquant avait peut-être déjà préparé une liste de portefeuilles vulnérables et de clés privées, puis traité les cibles de plus grande valeur en une rafale coordonnée.
Les transactions ultérieures compliquent l’attribution. Les estimations publiques sont passées de 594 BTC au départ à plus de 1 000 BTC, puis à environ 1 755 BTC à mesure que d’autres vagues et adresses étaient associées à la faiblesse. Un calendrier de transactions ou des flux de fonds similaires peuvent justifier un regroupement, mais ne prouvent pas automatiquement que chaque vol vient d’un seul opérateur.
Pour cette raison, la description la plus prudente est une estimation on-chain évolutive, plutôt qu’un décompte final des victimes ou un total confirmé attribué à un seul attaquant.
Pourquoi mettre à jour l’appareil ne suffit pas
Une mise à jour du firmware peut corriger l’aléa utilisé pour la création des futurs portefeuilles.
Elle ne peut pas ajouter d’entropie à un seed qui existe déjà.
Chaque clé privée et chaque adresse dérivée d’une phrase de récupération touchée reste liée à ce seed d’origine. Effacer l’appareil et restaurer les mêmes mots ne change rien. Importer ces mots dans un autre portefeuille matériel ne change rien. Le nouvel appareil recrée simplement les mêmes clés que l’attaquant peut déjà être en mesure de calculer.
La véritable remédiation est la migration :
Installez un firmware vérifié provenant de la source officielle du fabricant.
Générez un tout nouveau seed avec un processus de confiance, non touché.
Vérifiez hors ligne la procédure de récupération et l’adresse de réception.
Déplacez tous les fonds des adresses dérivées de l’ancien seed vers le nouveau portefeuille.
Considérez comme potentiellement exposé tout portefeuille enfant dérivé de l’ancienne racine, y compris les enfants BIP-85.
Ne saisissez jamais la phrase de récupération sur un site web, un formulaire de support, un « vérificateur » ou un outil de récupération non sollicité.
Les utilisateurs doivent suivre l’avis actuel de Coinkite pour connaître le périmètre définitif des appareils et firmwares touchés. Les informations publiques n’ont pas toujours employé « portefeuille », « adresse », « appareil » et « utilisateur » de façon cohérente, et ces termes ne sont pas interchangeables.
Ce que les équipes de portefeuilles matériels doivent retenir
Ce n’était pas une défaillance de l’algorithme de signature de Bitcoin, de la liste de mots BIP-39 ni du consensus de la blockchain. C’était une défaillance d’implémentation au moment où un secret de long terme était créé.
Les leçons d’ingénierie sont donc d’une netteté inhabituelle :
Un RNG cryptographique doit échouer de façon fermée. Si la source d’entropie prévue est indisponible, la création du seed doit s’arrêter avec une erreur visible.
Le code de production ne doit pas contenir de repli silencieux non cryptographique pour la génération de clés.
Les tests doivent exercer l’image de firmware signée exacte et le chemin matériel livrés aux utilisateurs, pas seulement le comportement au niveau du code source ou du simulateur.
La configuration au moment du build doit vérifier que l’implémentation de RNG requise est active.
Des sources d’entropie indépendantes peuvent être combinées pour que la défaillance d’un composant ne détermine pas entièrement le seed.
La génération de seeds exige des tests à réponse connue, d’injection de fautes et de chemins négatifs, en plus des tests statistiques d’aléa.
Les builds reproductibles améliorent la transparence, mais la reproductibilité prouve seulement que le binaire correspond au source. Elle ne prouve pas que le source est sûr.
La garde multisignature est la plus solide quand les clés sont générées indépendamment, idéalement sur des implémentations et des fabricants différents. Répéter le même générateur faible sur chaque signataire conserve le même domaine de défaillance.
La leçon plus large est inconfortable parce que le portefeuille matériel semble tout faire correctement après la configuration. Il garde le seed hors ligne. Il protège le PIN. Il vérifie le firmware. Il affiche les adresses sur un écran de confiance. Il signe dans un matériel dédié.
Tous ces contrôles se situent en aval de la génération du seed.
Si le premier secret est prévisible, le reste de l’architecture peut protéger une clé que l’attaquant peut recréer de façon indépendante.
L’air-gap empêche un secret de quitter l’appareil.
Il ne peut pas protéger un secret qui n’a jamais été assez secret.
Note de version et de périmètre : cette section reflète les informations publiques disponibles le 10 août 2026. Les totaux des pertes, les regroupements de transactions et le périmètre précis des appareils touchés évoluaient encore. Le chiffre de 116 millions de USD est une estimation, pas un total de pertes audité et définitif.
Sources : TRM Labs, CoinDesk, avis de sécurité de Coinkite, dépôt de firmware COLDCARD, code de génération de seed du firmware 4.0.0, configuration RNG de la carte COLDCARD, implémentation RNG de libNgU (version figée), implémentation RNG STM32 de MicroPython (version figée), historique des firmwares COLDCARD, spécification BIP-39
🛠️ Outil de la semaine
LLVM
La plupart des gens pensent qu’un compilateur n’a qu’une mission : transformer du code source en application fonctionnelle.
LLVM montre comment la compilation peut aussi devenir une partie des tests de sécurité. L’infrastructure open source derrière Clang peut insérer des vérifications pendant la construction du logiciel, aidant les équipes sécurité à découvrir des erreurs de mémoire et à guider les fuzzers vers du code que les tests ordinaires n’atteignent jamais.
Comment LLVM soutient les tests de sécurité
Clang traduit le code source C et C++ en un format interne que LLVM peut analyser et modifier avant de produire l’application finale.
Pendant ce processus, des outils comme AddressSanitizer peuvent ajouter des vérifications qui détectent des problèmes de mémoire, y compris les tentatives d’accéder à des données hors d’une zone autorisée ou de réutiliser de la mémoire après sa libération.
LLVM inclut aussi libFuzzer. Il envoie à plusieurs reprises des entrées modifiées à un programme et suit quelles parties du code elles atteignent. Les entrées qui découvrent un nouveau comportement sont conservées et modifiées à nouveau, ce qui permet au fuzzer d’explorer de plus en plus profondément l’application.
Un exemple simple
Imaginez qu’une entreprise maintienne une bibliothèque C++ qui traite des fichiers image.
Un ingénieur sécurité compile la bibliothèque avec Clang et active AddressSanitizer. Il connecte ensuite libFuzzer à la fonction chargée d’ouvrir les images et fournit plusieurs fichiers valides comme entrées de départ.
LibFuzzer modifie ces fichiers en continu tout en surveillant quelles parties du parseur sont atteintes. Finalement, une image malformée active un chemin de code rarement utilisé et déclenche une erreur de mémoire.
AddressSanitizer indique où l’erreur s’est produite, ce qui donne à l’équipe une entrée reproductible et un point de départ clair pour l’investigation.
Ce qu’il ne remplace pas
LLVM est un projet d’infrastructure, pas un scanner de sécurité que l’on peut simplement pointer vers une application.
Utiliser ses capacités de sécurité demande généralement l’accès au code source et au processus de build, ainsi qu’une cible de fuzzing adaptée. Il n’identifiera pas automatiquement les failles d’autorisation, la logique métier non sécurisée ni les vulnérabilités que ses tests n’atteignent jamais.
Ces vérifications supplémentaires peuvent aussi ralentir une application : les builds instrumentés sont donc généralement utilisés pour les tests plutôt que livrés aux utilisateurs.
👏 Personnalité de la semaine
Andrea Fioraldi
Cette semaine, nous mettons à l’honneur Andrea Fioraldi , chercheur en sécurité spécialisé dans le fuzzing et la découverte automatisée de vulnérabilités.
Andrea est l’un des mainteneurs d’AFL++, un fuzzer open source porté par la communauté qui réunit en un outil pratique des techniques issues d’années de recherche en sécurité.
Son travail comprend aussi LibAFL, un framework pour construire des fuzzers personnalisés, et QASan, qui aide à détecter les erreurs de mémoire dans des logiciels compilés quand leur code source n’est pas disponible. Sa thèse de doctorat sur les techniques modernes de fuzzing a reçu le Prix de thèse 2024 du GDR Sécurité Informatique.
Pour avoir contribué à transformer la recherche sur le fuzzing en outils open source pratiques de découverte de vulnérabilités logicielles, Andrea Fioraldi est notre Personnalité de la semaine.
📅 Événement de la semaine
Ekoparty Security Conference 2026
Des milliers de chercheurs en sécurité, de professionnels et de passionnés sont attendus à Buenos Aires pour la 22e édition d’Ekoparty , la plus grande conférence de hackers d’Amérique latine.
Sur trois jours, l’événement associe conférences techniques et ateliers à des CTF, des villages communautaires, des activités de hacking en direct et des défis pratiques.
Son programme couvre le hacking mobile, la rétro-ingénierie, le fuzzing, l’exploitation, les firmwares, la sécurité cloud et le hacking matériel.
Pour les équipes AppSec et de sécurité offensive, Ekoparty réunit en un seul événement de nouvelles recherches en sécurité, des démonstrations pratiques et des activités concrètes.
📍 Centro de Convenciones de Buenos Aires, Argentine
📅 7 au 9 octobre 2026
📚 Livre de la semaine
Black Hat GraphQL
Par Nick Aleks et Dolev Farhi
Comment tester une API qui permet aux clients de décider exactement quelles données ils veulent ?
Black Hat GraphQL explique comment fonctionnent les API GraphQL et comment les professionnels de la sécurité peuvent examiner leur surface d’attaque. Il couvre la reconnaissance, la divulgation d’informations, les contournements d’authentification et d’autorisation, l’injection, les attaques par déni de service et la falsification de requêtes.
Grâce à des labs pratiques et à une application GraphQL volontairement vulnérable, les lecteurs apprennent à identifier des faiblesses, à valider des contrôles de sécurité et à intégrer des tests automatisés dans le pipeline de développement.
C’est une lecture utile pour les pentesteurs, les ingénieurs AppSec, les analystes sécurité et les développeurs qui veulent comprendre concrètement comment les API GraphQL sont attaquées et protégées.
😅 Le mème
Si les portefeuilles matériels comme les plateformes d’échange exigent de la confiance, quelles preuves les détenteurs de Bitcoin devraient-ils exiger avant de décider où garder leurs Bitcoin ?
The Breach Brief, L’équipe Ostorlab