-
La vulnerabilidad en la librería crypto-js afecta a al menos cinco wallets de software.
-
Un fallo en el generador de claves reduce la protección real a decenas de bits.
Una wallet de Bitcoin y de otros criptoactivos depende de un número generado al azar para crear la frase de recuperación (o semilla) que protege los fondos. Cuando ese proceso falla, ninguna otra medida de seguridad importa. Dos casos recientes muestran cuánto dinero ya se perdió por esta causa.
La seguridad de esa frase semilla depende de su entropía, es decir, de cuán impredecible es el número aleatorio que le dio origen. Una frase con 128 bits de entropía es prácticamente imposible de adivinar, pero si el generador que la creó es defectuoso, ese número de combinaciones puede reducirse a un puñado que una computadora común prueba en poco tiempo.
La consecuencia de ello es que un hacker puede obtener esa semilla y acceder a los fondos.
Doce años de una falla de entropía oculta para generar semillas
El primer caso tiene origen en crypto-js, una librería de JavaScript utilizada dentro de wallets para generar las frase semillas que protegen los fondos.
El 5 de agosto de 2026, Coinspect publicó su investigación Ill Bloom, que rastreó el origen de varios robos hasta WordArray.random(), la función que crypto-js utiliza para generar números aleatorios al crear una frase de recuperación.
Esa función incorporó en 2014 un generador de números al azar débil, basado en una variante de un método matemático conocido como Multiply-With-Carry y alimentado con Math.random(), una fuente de aleatoriedad del propio lenguaje JavaScript que nunca fue pensada para usos criptográficos.
Los desarrolladores de la librería crypto-js llegaron a corregir el problema en una versión posterior, pero revirtieron ese cambio poco después por considerarlo demasiado disruptivo para quienes ya dependían de la librería. El defecto original volvió a quedar activo y recién se solucionó de forma definitiva unos seis años más tarde, en la versión 4.0.0 en 2020, de acuerdo con la investigación.
El resultado práctico de ese generador defectuoso es que una frase de recuperación pensada para tener 128 o 256 bits de protección terminaba teniendo apenas entre 39 y 47 bits reales, un espacio de combinaciones que un atacante puede recorrer por completo con hardware de uso común.
Si bien el defecto en el código ya está resuelto desde la versión 4.0.0, el riesgo de robos sigue vigente en la actualidad por dos motivos:
- Primero: casi 15.600 proyectos dependen hoy de la librería crypto-js, según el registro npm, sin que se sepa cuántos usan todavía una versión anterior.
- Segundo: cualquier frase de recuperación generada con una versión vulnerable antes de la corrección sigue comprometida hoy, sin importar si la aplicación se actualizó después.
Ese defecto permaneció activo el tiempo suficiente para que miles de wallets generaran sus claves con él. Recién en 2026, mientras investigaba drenajes de fondos en cuentas de Bitcoin y otras redes, el equipo de Coinspect remontó el origen hasta ese código de 2014.
Coinspect documentó tres oleadas de robos ocurridas entre mayo y julio de 2026, por USD 3,1 millones, USD 2,5 millones y USD 38.500 respectivamente, que suman casi USD 5,7 millones.
En la primera de esas oleadas, Bitcoin fue la cadena con mayor cantidad de dinero robado producto del fallo en la entropía de crypto-js, como se ve en la siguiente clasificación:
El desarrollo de crypto-js está discontinuado desde 2023, conforme al repositorio oficial del proyecto, por lo tanto, no se publicarán nuevas versiones que corrijan este código. Aun así, la vulnerabilidad de baja entropía en crypto-js es todavía considerada de «gravedad crítica».
Wallets afectadas por el fallo de entropía en crypto-js
Coinspect confirmó cinco aplicaciones afectadas: NanChat, Bexo, Bitcoin Libre, RRWallet y Milo, y habilitó un verificador en illbloom.org donde cualquier usuario puede comprobar si una dirección pública aparece en la lista de wallets expuestas, sin necesidad de ingresar la frase de recuperación en ningún momento.
Las respuestas de los cinco equipos fueron muy distintas. Coinspect notificó a NanChat el 10 de junio y el equipo lanzó una corrección dos días después, en la versión 1.3.0.
Bexo Wallet preparó una corrección en la versión 20.1.0, pero todavía no está disponible en las tiendas de aplicaciones. Bitcoin Libre, por su parte, ya había resuelto el problema en su versión 4, lanzada en julio de 2024, mucho antes de conocerse la investigación Ill Bloom.
RRWallet y Milo, en cambio, ya no operan, así que no hubo corrección ni aviso posible.
El mismo patrón, ya documentado en un hardware wallet
El segundo caso es el que CriptoNoticias ya documentó en las últimas semanas, un defecto de integración en el firmware de Coldcard que redujo la entropía al generar la semilla de recuperación en sus dispositivos. Las últimas estimaciones ubican el robo en más de 2.055 bitcoin, unos USD 130 millones.
Un grupo de investigadores decidió medir en la práctica la velocidad de ese tipo de ataques. Armaron lo que se conoce como honeypots, wallets señuelo cargadas con fondos reales de bajo valor, generadas igual que las semillas comprometidas de Coldcard, para observar cuánto tardaban los bots en encontrarlas y vaciarlas.
Algunas de esas wallets señuelo usaban solo la semilla comprometida. Otras sumaban una frase de contraseña adicional (passphrase), un dato que normalmente eleva mucho la seguridad porque agrega entropía propia por encima de la semilla original.
El desarrollador James O’Beirne contó en una publicación en X que sus honeypots eran vaciados con apenas 11 bits de entropía añadida en esa frase de contraseña, es decir, unas 2.048 combinaciones posibles, un número que cualquier computadora recorre en segundos.
Asimismo, el usuario ottosch documentó que una dirección generada con la frase semilla compuesta por la palabra «bus» doce veces recibió 1,77 BTC (USD 111.000), repartidos en cuatro transacciones, y bots la vaciaron por completo en menos de una hora.
Ambos casos muestran, en tiempo real, la misma lógica que explica los robos de crypto-js. La semilla «bus» 12 veces tiene tan poca variabilidad real como una semilla con solo 11 bits de protección adicional, y por eso cae en minutos, sin importar si la debilidad está en la semilla original o en una capa agregada después.
¿Por qué la baja entropía sigue apareciendo?
Los dos casos comparten una misma raíz, aunque se manifiesten en lugares distintos. En ambos, un generador de números aleatorios mal implementado y de baja entropía quedó enterrado dentro de código heredado, código antiguo que sigue en producción porque reescribirlo rompería la compatibilidad con miles de aplicaciones o dispositivos existentes.
Cuando ese código pertenece además a un proyecto discontinuado, como crypto-js, no hay ni siquiera un equipo activo que lo revise de oficio.
Ni actualizar el software ni cambiar el firmware del dispositivo alcanza para proteger fondos generados antes de una corrección, porque el problema no está en la versión que corre hoy sino en el número aleatorio que ya quedó fijado en la clave privada. La única acción que efectivamente protege esos fondos esmigrarlos a una wallet completamente nueva, generada después de la corrección o en una aplicación distinta.
La entropía es invisible mientras funciona bien, y solo se vuelve noticia cuando falla. Tanto Coinspect como los investigadores que documentaron los honeypots de Coldcard coinciden en que sus registros no son exhaustivos, así que el número real de wallets todavía expuestas, tanto por la falla de crypto-js como por la de Coldcard, sigue sin poder determinarse con precisión.
