Trust Wallet, el precedente a Coldcard
Trust Wallet comprometió su extensión de navegador en noviembre de 2022 y de nuevo en diciembre de 2025. Las causas no tienen relación entre sí, las pérdidas, de 170 mil USD y 7 millones de USD respectivamente, se diferencian por un factor de cuarenta, y en ambos casos la empresa reembolsó a los afectados. Esa constante es lo que vuelve al par de episodios un punto de comparación útil frente al robo que sufrieron los usuarios de Coldcard.
La comparación no es un invento. El 1 de agosto de 2026, Charles Guillemet, director de tecnología de Ledger, la planteó desde su cuenta de X y la empresa la reprodujo en su blog corporativo, señalando que el laboratorio Donjon había descubierto a fines de 2022 una vulnerabilidad similar en la extensión de Trust Wallet, que volvía recuperable cada billetera creada por ella a partir de su dirección pública.
Noviembre de 2022, un fallo de generación
Entre el 14 y el 23 de ese mes, la extensión generó billeteras con treinta y dos bits de entropía. Cuatro mil millones de frases mnemónicas posibles, un espacio que una computadora corriente recorre en un par de horas. El defecto quedó registrado como CVE-2023-31290 y afectó a las versiones 0.0.172 a 0.0.182, construidas sobre versiones de Trust Wallet Core anteriores a la 3.1.1.
Trust Wallet Core es una biblioteca multiplataforma cuya generación de material aleatorio depende del entorno de destino. En iOS recurre a SecRandomCopyBytes y en Android a java.security.SecureRandom, ambas fuentes adecuadas. El objetivo WebAssembly, incorporado en abril de 2022 para habilitar la extensión de navegador, carecía de un generador equivalente, y lo que se usó en su lugar fue MT19937, el algoritmo Mersenne Twister, que admite una semilla de treinta y dos bits.
El informe del Ledger Donjon detalla cómo lo demostraron. El equipo construyó el archivo con todas las semillas posibles y recorrió los nodos públicos de Ethereum y Binance Smart Chain para reunir decenas de millones de direcciones. La consulta que devuelve la frase mnemónica y la clave privada de una dirección afectada tomaba alrededor de dos décimas de segundo. Según su estimación, unos treinta millones de dólares llegaron a estar en riesgo en algún momento, cifra parcial porque no monitorearon todas las cadenas ni todos los activos.
La vulnerabilidad se reportó al programa de recompensas de Binance el 17 de noviembre de 2022, y el equipo comprometió la corrección en su repositorio público cuatro días más tarde. La divulgación pública recién llegó el 22 de abril de 2023, tras cinco meses de parcheo silencioso durante los cuales se dio tiempo a los usuarios para migrar sus fondos. Guillemet sostiene que ese procedimiento evitó uno de los mayores compromisos de billeteras del ecosistema.
Las pérdidas totalizaron unos ciento setenta mil dólares, en dos episodios de explotación, en diciembre de 2022 y en marzo de 2023. Trust Wallet corrigió la biblioteca en la versión 3.1.1 y la extensión en la 0.0.183, publicó un informe posterior que consignaba unas quinientas direcciones vulnerables con ochenta y ocho mil dólares pendientes, y abrió un proceso de reclamos. La compensación incluyó el reembolso de los fondos y además una asistencia para cubrir el gas de las transferencias, detalle menor en apariencia pero significativo, porque migrar una billetera comprometida tiene un costo que de otro modo recae sobre la víctima.
El defecto reapareció meses después en otro producto. Los investigadores del caso Milk Sad, que expuso billeteras creadas con Libbitcoin Explorer, escribieron en su divulgación que quedaron impresionados al leer el análisis del Donjon por lo cerca que estaba de lo que ellos habían encontrado. Ambos productos compartían el mismo algoritmo inadecuado, sin relación alguna entre sus equipos.
Diciembre de 2025, un fallo de distribución
La versión 2.68 de la extensión de Chrome incorporó código malicioso que recorría todas las billeteras almacenadas, disparaba una solicitud de frase mnemónica para cada una y la desencriptaba con la contraseña introducida al desbloquear, para enviarla después a un servidor controlado por el atacante. El análisis de SlowMist, recogido por The Hacker News, identificó el uso de posthog-js, una biblioteca de analítica de código abierto, como herramienta de recolección. El dominio se registró el 8 de diciembre y la primera petición se produjo el 21.
El vector no fue un error de programación. Eowyn Chen, directora ejecutiva de la empresa, explicó que el atacante empleó una clave de interfaz de la tienda de extensiones de Chrome filtrada para enviar la versión maliciosa, que superó la revisión de la propia tienda y se publicó el 24 de diciembre a las 12:32 UTC, fuera del proceso interno y sin la revisión obligatoria.
El informe posterior de la empresa reconstruye la respuesta. El 25 de diciembre se reportó públicamente el primer vaciado de billeteras, señalado por los investigadores 0xAkinator y ZachXBT, que rastrearon las direcciones del atacante, mientras el socio Hashdit y los sistemas internos emitían alertas. Investigadores de sombrero blanco lanzaron ataques de denegación de servicio contra el dominio del atacante para inutilizarlo temporalmente y reducir la cantidad de víctimas. La empresa revirtió a la versión 2.67 verificada, la publicó como 2.69, y ese mismo día emitió su primera alerta pública pidiendo desactivar la extensión afectada.
Las pérdidas rondaron los siete millones de dólares, unos tres millones en bitcoin y más de tres millones en ether, con un remanente en solana. PeckShield rastreó más de cuatro millones movidos a través de ChangeNOW, FixedFloat y KuCoin, con unos 2,8 millones todavía en las direcciones del atacante.
La restitución fue inmediata y sin condicionamientos. El 26 de diciembre, Changpeng Zhao escribió en X que siete millones habían resultado afectados, que Trust Wallet los cubriría y que los fondos de los usuarios estaban protegidos, agregando que el equipo seguía investigando cómo los atacantes habían logrado publicar una versión nueva. La cobertura se apoyaba en el fondo de seguro de emergencia que Binance, propietaria de la compañía desde 2018, constituyó en ese mismo año con comisiones de operación. La propia Trust Wallet confirmó el reembolso poco después.
Chen informó que se identificaron 2.596 direcciones afectadas y que se recibieron alrededor de cinco mil reclamos, lo que indica una cantidad considerable de presentaciones falsas o duplicadas intentando acceder a los reembolsos de las víctimas. En paralelo circulaban anuncios en Telegram, formularios de compensación falsos y cuentas de soporte suplantadas, montados sobre el incidente real. La empresa tuvo que pedir a sus usuarios que verificaran los enlaces y no compartieran nunca su frase de recuperación, en medio de un proceso destinado justamente a repararlos.
Comparación entre los casos de Trust Wallet y Coldcard
El episodio de julio de 2026 reproduce el mecanismo del primero de los dos. Un error de integración dejó la compilación del firmware atada a un generador pseudoaleatorio de respaldo, inicializado con el identificador del chip y el estado de sus temporizadores, en lugar del generador de hardware previsto. En ambos casos un componente del sistema quedó unido a una fuente de aleatoriedad inadecuada para uso criptográfico, y en ambos la billetera se genera de manera correcta a los ojos del usuario, con palabras que superan cualquier inspección, sobre un número que el atacante puede reconstruir sin tocar el dispositivo.
La diferencia de magnitud es de tres órdenes. Trust Wallet perdió ciento setenta mil dólares y Coldcard más de mil trescientos bitcoin. No se explica por la gravedad del defecto, que era peor en Trust Wallet, con treinta y dos bits contra los cuarenta del modelo Mk3,sino por la ventana de exposición y por quién encontró el problema primero. La extensión generó billeteras defectuosas durante diez días y el defecto lo halló un laboratorio de seguridad que lo reportó por el canal formal antes de cualquier explotación masiva. El firmware de Coldcard operó cinco años, en código publicado para su revisión, y el problema se conoció cuando los fondos ya se estaban moviendo.
Corresponde señalar que Guillemet no es un observador neutral. Su artículo aclara que los dispositivos de Ledger no están afectados por el aviso del Mk3 y que emplean un generador certificado dentro del elemento seguro, argumento comercial además de técnico. Eso no invalida la comparación, que es correcta en su mecánica y está respaldada por el trabajo publicado de su propio laboratorio.
Capacidad para posibilitar una restitución
Coinkite se comprometió, en su aviso de seguridad, a entregar a los afectados un resumen escrito del incidente y los datos de transacción disponibles, para que gestionen por su cuenta una denuncia policial, un reclamo de seguro o una investigación propia. No hay compensación anunciada.
Trust Wallet opera con el respaldo financiero de un exchange global y de un fondo de seguro constituido para estos casos. Coinkite es un fabricante independiente de hardware, y el valor sustraído en un solo día excede cualquier estimación razonable de su capacidad patrimonial. La probabilidad de recuperar fondos ante un fallo del proveedor depende menos de su responsabilidad que de su balance, el cual rara vez figura como criterio para eligir una wallet.
Por Sistemas, el 04/08/2026.
Siguiente