Un problème de CryptoJS RNG faible (génération aléatoire insuffisante) serait à l’origine de plusieurs drains de portefeuilles crypto. L’analyse de Coinspect relie cette faiblesse de la bibliothèque JavaScript CryptoJS.lib.WordArray.random() à des phrases de récupération produites avec trop peu d’entropie. Résultat : dans certains cas, des attaquants ont pu reconstruire l’espace de recherche et récupérer des fonds.
Coinspect chiffre les pertes observées à un minimum d’environ 5,7 millions de dollars, après deux vagues de vols identifiées entre fin mai et mi-juillet. L’incident touche cinq applications au total, avec des statuts très différents selon les versions.
Pourquoi une RNG faible change tout pour une phrase de récupération
Les portefeuilles basés sur des standards comme BIP39 utilisent des phrases de récupération pour restaurer l’accès aux fonds. En théorie, l’entropie doit être suffisamment élevée pour que le nombre de possibilités reste gigantesque.
Coinspect a constaté que la fonction aléatoire de CryptoJS, introduite il y a environ douze ans, fournit en pratique une entropie trop faible quand elle est utilisée comme source pour générer des valeurs de sécurité. Même si la phrase obtenue est ensuite transformée via des étapes classiques, l’entropie manquante ne se “rattrape” pas : une fois la phrase générée, elle reste plus devinable partout où elle est importée.
Des espaces de recherche réduits à un niveau “énumérable”
Sur le papier, des tailles d’entropie de 128 bits et 256 bits offrent respectivement des espaces de recherche de 2^128 et 2^256, impossibles à parcourir en pratique.
Dans le cas observé, CryptoJS RNG faible réduirait ces espaces à environ 2^39 et 2^47. Cette diminution rendrait l’attaque réalisable avec du matériel ordinaire, car l’attaquant peut énumérer les sorties, reconstruire des phrases BIP39, dériver des adresses, puis vérifier leur présence sur la blockchain.
Cinq applications identifiées, avec des réponses inégales
Coinspect confirme avoir mis en évidence cinq applications qui auraient utilisé cette RNG comme source d’entropie pour générer des phrases de récupération. Parmi elles, certaines ont été corrigées, d’autres abandonnées, et plusieurs précisions manquent encore pour les plages de versions exactes.
RRWallet
Coinspect indique que RRWallet est arrêté. Aucune correction n’aurait été fournie.
Bexo Wallet
Bexo Wallet serait corrigé en version 20.1.0. Toutefois, Coinspect rapporte que, lors de son examen, les builds mises à jour n’étaient pas encore téléversées publiquement. En pratique, cela signifie que les utilisateurs de la version vulnérable ne pouvaient pas toujours accéder immédiatement au correctif.
NanChat
NanChat aurait été affecté avant la version 1.3.0, avec une correction annoncée en 1.3.0. Coinspect précise que l’application publie aussi des consignes dédiées aux personnes concernées.
Bitcoin Libre
Coinspect associe la correction à la version 4, publiée en juillet 2024.
Milo
Milo est également signalé comme arrêté. Coinspect indique aucun correctif disponible.
Les correctifs ne “réparent” pas les phrases déjà générées
Une information importante pour les utilisateurs : mettre à jour l’application ne suffit pas si une phrase vulnérable a déjà été générée. Une fois produite à partir d’une RNG faible, la phrase reste devinable.
Coinspect recommande donc, pour les utilisateurs ayant créé leurs clés via un chemin vulnérable, de générer une nouvelle phrase de façon sécurisée puis de déplacer les fonds vers cette nouvelle base. Les graines produites par du matériel (hardware wallet) seraient, d’après l’analyse, moins exposées. De même, la plupart des portefeuilles logiciels “actuels” ne seraient pas concernés.
Comment l’attaque a été reproduite et confirmée
Pour étayer sa conclusion, Coinspect décrit une chaîne d’attaque fondée sur l’énumération. Concrètement, l’équipe :
- énumère les sorties issues de la RNG vulnérable ;
- convertit ces sorties en phrases BIP39 ;
- calcule les adresses dérivées ;
- et vérifie si ces adresses correspondent à des éléments observables sur des blockchains publiques.
Cette démarche explique comment des attaquants peuvent relier des graines candidates à des adresses actives, puis drainer les comptes.
Chronologie : un correctif réintroduit, puis stabilisé
Le problème ne serait pas “nouveau” : CryptoJS a oscillé entre versions avec RNG native et réintroduction du code faible. Coinspect indique notamment une histoire de bascule autour de 2014 et une correction définitive plus tard.
La source “Multiply-With-Carry” aurait été alimentée par Math.random() en juin 2014. Ensuite, des versions 3.2.0 et 3.2.1 auraient basculé vers une méthode native cryptographique. Puis, la version 3.3.0 aurait réintroduit le code faible, considérant le changement comme “cassant”. Enfin, la version 4.0.0 aurait rétabli de manière permanente une RNG native en février 2020.
Où le risque apparaît côté intégration
Coinspect signale aussi que le simple fait de dépendre de la librairie ne suffit pas à rendre une application attaquable. Selon l’advisory cité, l’application est réellement concernée seulement si elle utilise la fonction vulnérable pour générer des valeurs sensibles, comme l’entropie des phrases de récupération.
Autrement dit, un paquet “large” ne correspond pas automatiquement à un ensemble complet d’applications exploitables. Il faut que le code réutilise effectivement la RNG au bon endroit dans le workflow de génération.
L’analyse cite également une piste via un fork React Native (ferrumnet/bip39) qui, dans ce cas, remplacerait la RNG cryptographique native en s’appuyant sur CryptoJS. Coinspect précise toutefois que ce n’est qu’une voie possible, et qu’il peut exister d’autres chemins d’intégration.
Deux vagues de drains et une estimation des pertes
Coinspect associe l’exploitation à deux périodes distinctes. Une première vague, autour du 27 mai, aurait entraîné environ 3,14 millions de dollars retirés de 431 comptes.
Une seconde phase, entre le 30 mai et le 13 juillet, totaliserait environ 2,55 millions depuis des adresses liées à 522 graines. Le rapport mentionne notamment environ 2,18 millions de USDT sur une adresse Tron le 4 juillet.
Au total, Coinspect indique avoir suivi 2 114 graines identifiées et des adresses associées couvrant plusieurs écosystèmes, notamment Bitcoin, Ethereum, Tron, Rootstock et Polygon. L’estimation consolidée des pertes observées s’élève à 5 690 922 dollars (au minimum) jusqu’au 13 juillet.
Limites de l’enquête : tout ne peut pas être vérifié
Coinspect estime que la population touchée pourrait se compter par milliers sur des réseaux compatibles EVM ainsi que sur Bitcoin. Toutefois, l’équipe souligne qu’il n’est pas possible de confirmer exhaustivement chaque application vulnérable.
En particulier, certains portefeuilles auraient été retirés des app stores ou des marketplaces d’extensions avant que l’analyse ne puisse être finalisée, ou bien auraient été remplacés par des versions corrigées sans que les anciennes révisions vulnérables restent accessibles.
Que faire si vous utilisez un portefeuille concerné
Coinspect invite les utilisateurs à vérifier, via les canaux officiels du projet, quelles versions sont corrigées et quelles procédures de migration sont recommandées. L’analyse rappelle aussi un point décisif : si votre phrase a été générée via une version vulnérable, le correctif ne vous “protège” pas rétroactivement.
Dans le cas de NanChat, l’advisory indique que les utilisateurs ayant créé un portefeuille avant la v1.3.0 devraient considérer la phrase comme compromise et migrer. La version 1.3.0 intégrerait d’ailleurs un outil pour générer une nouvelle graine et transférer les fonds.
Conclusion : la confiance dans l’aléatoire est un pilier
Cette affaire montre que, dans la cryptographie appliquée, la qualité de l’aléatoire n’est pas un détail. Avec CryptoJS RNG faible, une mauvaise source d’entropie aurait réduit drastiquement l’espace des possibilités, rendant des phrases de récupération plus faciles à deviner dans certains cas.
Si votre portefeuille dépend d’une génération de phrases sensible à ce type de RNG, la bonne approche consiste à confirmer la version exacte, suivre les consignes du projet et, surtout, générer une nouvelle phrase lorsque la vôtre pourrait avoir été produite sur un chemin vulnérable.
Source: https://thehackernews.com/2026/08/cryptojs-weak-rng-behind-57-million-in.html
