El error de cinco años que permitió robar más de US$100 millones en Bitcoin y reabre el debate sobre cómo guardar criptomonedas

Una hardware wallet guardada fuera de Internet y una seed phrase que nunca fue compartida suelen representar un alto nivel de protección para Bitcoin. Sin embargo, un error de software introducido cinco años atrás demostró que incluso ese esquema puede esconder un punto débil invisible.

Desde el 30 de julio de 2026, atacantes comenzaron a drenar fondos asociados a billeteras Coldcard afectadas por una vulnerabilidad en la generación de sus semillas.

La dimensión del incidente fue creciendo a medida que aparecieron nuevas víctimas. Galaxy Research informó el 14 de agosto que había identificado con alta confianza 1.778,84 BTC robados, valuados entonces en aproximadamente US$112,7 millones, provenientes de más de 8.600 direcciones.

La investigación también identificó conjuntos adicionales de posibles robos que todavía no habían alcanzado el mismo nivel de confirmación y que, de incluirse, elevarían las pérdidas hasta 2.417,35 BTC, unos US$153 millones según la cotización utilizada por Galaxy en ese momento.

El episodio no implicó una vulneración de la red Bitcoin. El problema apareció en una etapa anterior: la manera en que determinados modelos y versiones del firmware de Coldcard generaban la información aleatoria utilizada para crear las semillas que posteriormente derivan en las claves privadas.

“Este caso no demuestra que Bitcoin haya fallado. Lo que muestra es que la infraestructura que usamos para proteger las llaves también puede fallar. Son dos cosas completamente distintas y es fundamental separarlas para no sacar conclusiones equivocadas”, explica Matías Bari, CEO y cofundador de Satoshi Tango.

El punto débil que permaneció oculto durante cinco años

Para que una clave criptográfica sea segura debe partir de suficiente aleatoriedad, técnicamente denominada entropía.

El origen del problema se remonta a marzo de 2021, cuando una modificación de software afectó el proceso mediante el cual determinados dispositivos Coldcard obtenían esa aleatoriedad.

En lugar de utilizar correctamente la fuente de entropía de hardware prevista, el sistema podía terminar recurriendo a una alternativa de software considerablemente más débil.

La consecuencia fue crítica.

Seeds que debían contar con aproximadamente 128 bits de entropía quedaron reducidas, en los casos más comprometidos, a alrededor de 40 bits en equipos Mk2 y Mk3 y a unos 72 bits en modelos posteriores como Mk4, Mk5 y Q.

La diferencia no es menor. Al reducir drásticamente el universo de combinaciones posibles, los atacantes podían generar candidatos de manera automatizada hasta encontrar claves asociadas con direcciones existentes en la blockchain.

Y podían hacerlo sin robar el dispositivo.

El ataque podía ejecutarse offline y sin acceso físico a la hardware wallet. Una persona podía tener el dispositivo desconectado de Internet, correctamente guardado y no haber revelado nunca su frase de recuperación y, aun así, estar expuesta si esa seed había sido generada bajo condiciones vulnerables.

“En cripto solemos repetir que una clave privada debe mantenerse offline. Eso sigue siendo válido, pero este incidente agrega una precisión importante: no alcanza con proteger bien un secreto si ese secreto nació débil. La seguridad empieza en el momento mismo de la generación de la clave”, sostiene Bari.

Actualizar el dispositivo no repara una clave vulnerable

Coinkite, fabricante de Coldcard, publicó firmware corregido para los modelos afectados.

Pero existe una diferencia fundamental: actualizar el firmware puede proteger la generación de nuevas semillas, pero no fortalece retroactivamente una seed vulnerable creada anteriormente.

Una vez generado un secreto con una cantidad insuficiente de entropía, instalar una actualización no modifica ese secreto.

Por eso, ante una seed creada con firmware afectado, la recomendación del fabricante es actualizar el dispositivo, generar una seed completamente nueva y migrar los fondos hacia nuevas direcciones.

Copiar la misma frase de recuperación en otro dispositivo tampoco resuelve el problema: la vulnerabilidad está en la seed original, no solamente en el aparato que la almacena.

Coinkite indicó además que los usuarios que incorporaron al menos 50 tiradas de dados privadas e independientesdurante la generación de la seed pueden no estar expuestos a esta falla específica.

Una passphrase BIP-39 fuerte, única y secreta también puede agregar una barrera independiente, aunque no modifica la debilidad de la seed original.

“La autocustodia da control, pero también traslada responsabilidades. No debería entenderse como una solución mágica ni como un proceso que termina cuando alguien compra un dispositivo. Hay que saber cómo se generó la clave, cómo se hizo el backup, cómo se recupera y qué ocurre si una parte de esa cadena falla”, señala Bari.

¿La autocustodia dejó de ser segura?

El incidente reabre un debate histórico dentro del ecosistema Bitcoin: custodia propia versus custodia mediante terceros.

La conocida máxima “not your keys, not your coins” nació como una advertencia frente al riesgo de mantener activos en plataformas que controlan las claves de sus usuarios.

El caso Coldcard introduce otra dimensión.

Controlar personalmente una clave elimina determinados riesgos de contraparte, pero no elimina los riesgos técnicos, operativos o humanos.

Galaxy Research sintetizó el problema al analizar el ataque: eliminar a un custodio externo no elimina el riesgo de custodia, sino que lo traslada al hardware, al software y a los procesos de generación y protección de las claves.

Esto no convierte automáticamente a la autocustodia en insegura ni a la custodia mediante terceros en superior. Son modelos que exponen al usuario a amenazas diferentes.

En una plataforma, el usuario depende de los controles y la solvencia del proveedor. En autocustodia, asume personalmente la protección de sus secretos y la seguridad de las herramientas que utiliza.

“La discusión madura no es ‘exchange o hardware wallet’ como si hubiese una respuesta universal. La pregunta correcta es qué riesgos entiende cada usuario, cuáles puede administrar y qué solución es adecuada para el monto y el uso que va a darle a sus activos”, plantea Bari.

El caso obliga así a revisar una simplificación frecuente dentro del universo cripto.

Tener control de las claves privadas no significa haber eliminado el riesgo: significa haber cambiado su naturaleza.

La seguridad pasa a depender de una cadena que incluye la generación de la clave, el firmware, el dispositivo, las copias de respaldo, los mecanismos de recuperación y el comportamiento del propio usuario.

Qué debería revisar un usuario después del caso Coldcard

Para quienes hayan utilizado Coldcard, la primera medida es verificar el modelo, la versión del firmware y las condiciones bajo las cuales fue generada la seed.

Coinkite mantiene un advisory específico sobre el incidente y actualmente recomienda utilizar como mínimo las versiones corregidas correspondientes a cada dispositivo. Además, el fabricante volvió a actualizar en agosto el firmware de sus modelos Mk4, Mk5 y Q como parte de una revisión de seguridad más amplia.

Si una seed fue generada utilizando firmware afectado y todavía controla fondos, actualizar solamente el dispositivo no es suficiente: los activos deben migrarse siguiendo las indicaciones oficiales hacia una nueva seed generada de manera segura.

Para los usuarios de cualquier hardware wallet, el episodio también refuerza algunas prácticas generales: obtener firmware únicamente desde fuentes oficiales, verificar cuidadosamente las direcciones antes de transferir, realizar operaciones pequeñas de prueba antes de mover grandes cantidades y mantener copias de recuperación adecuadamente protegidas.

Para patrimonios que justifican una arquitectura de seguridad más compleja, también pueden evaluarse sistemas multifirma que reduzcan la dependencia de una única clave.

“La transparencia del código es valiosa, pero la seguridad necesita capas. Auditorías, pruebas, procesos reproducibles y capacidad de respuesta. El usuario final no puede revisar cada línea de software que corre dentro de un dispositivo; por eso el estándar de la industria tiene que ser cada vez más alto”, afirma Bari.

Un golpe que no afectó a Bitcoin, pero sí a una certeza

El impacto simbólico del caso excede el monto robado porque Coldcard es un producto orientado precisamente a usuarios que buscan una modalidad avanzada de autocustodia.

La vulnerabilidad puso en discusión una idea muy extendida: que una clave creada dentro de una hardware wallet y posteriormente mantenida desconectada resulta, por definición, prácticamente inaccesible.

El incidente mostró algo diferente.

El riesgo puede aparecer antes de que la clave sea almacenada: durante el proceso mismo que la genera.

“Una próxima etapa de adopción no puede depender de que cada usuario se convierta en especialista en criptografía. La industria tiene que construir productos más seguros, procedimientos más claros y educación suficiente para que la gente sepa qué está protegiendo y contra qué riesgo”, concluye Bari.

El caso Coldcard deja así una enseñanza incómoda para el ecosistema.

En Bitcoin, conservar la llave sigue siendo esencial. Pero la pregunta de seguridad ya no termina en quién la posee: también importa cómo fue generada, con qué software, con qué nivel de aleatoriedad y bajo qué controles.

En un sistema en el que una transacción válida no puede revertirse simplemente mediante la intervención de un banco o una plataforma, esa diferencia puede valer millones de dólares.