A finales de julio y principios de agosto de 2026, se reveló que la conocida cartera de hardware para Bitcoin Coldcard tenía un defecto en la generación de números aleatorios. Esta vulnerabilidad podría hacer que la aleatoriedad de las frases mnemónicas generadas por algunos dispositivos fuera insuficiente, dando así a los atacantes la oportunidad de inferir sistemáticamente las claves privadas de la cartera y transferir los activos BTC de los usuarios.
Según el aviso de seguridad publicado por Coinkite el 30 de julio de 2026, el firmware de Coldcard afectado ya ha publicado una versión con correcciones, pero la actualización del firmware no puede reparar las frases mnemónicas que ya se habían generado. Si la semilla de la cartera del usuario se generó en una versión de firmware afectada, aún será necesario migrarla a una cartera generada de nuevo.
Este incidente vuelve a recordarle a toda la industria de Bitcoin: la seguridad de los monederos en frío no depende solo de “si están o no conectados”, sino de si el proceso de generación de claves es realmente aleatorio, verificable y auditable.
¿Qué ocurrió en el incidente?
Coldcard es un monedero de hardware para Bitcoin lanzado por la empresa canadiense Coinkite. Los monederos de hardware suelen utilizarse para guardar claves privadas sin conexión; el usuario genera en el dispositivo un conjunto de frases mnemónicas y controla los activos BTC en la cadena con esa frase mnemónica.
El problema aparece en la etapa de generación de la frase mnemónica.
Según el análisis del equipo de Block Bitcoin Engineering and Security, en el firmware de Coldcard existe un error de integración en el generador de números aleatorios, lo que hace que algunas versiones no utilicen correctamente el generador de números aleatorios del hardware y, en su lugar, retrocedan a una ruta determinista de aleatoriedad en software. En pocas palabras, el dispositivo debería generar semillas aleatorias casi impredecibles, pero la aleatoriedad en el proceso real de generación se debilitó de forma considerable.
Esto significa que el atacante no necesita obtener el dispositivo del usuario; tampoco necesariamente necesita hacer phishing o usar troyanos. Basta con que pueda reducir el espacio de búsqueda de números aleatorios para que, sin conexión, pueda inferir parte de las frases mnemónicas y las claves privadas.
¿Qué magnitud tuvo el robo?
Las cifras reportadas públicamente aún difieren, lo que indica que la atribución en la cadena y el alcance afectado siguen actualizándose.
CoinDesk informó el 31 de julio de 2026 que, en los ataques iniciales, aproximadamente 594 BTC fueron transferidos desde alrededor de 500 monederos de firma única. BleepingComputer citó posteriormente datos de Galaxy Research y señaló que, tras múltiples rondas de ataque, la magnitud presunta del robo aumentó hasta aproximadamente 1.367 BTC, involucrando 4.585 direcciones, con un valor de alrededor de 88,6 millones de dólares.
También hay una interpretación del mercado que indica que, al 3 de agosto, el atacante podría haber robado más de 1.755 BTC de aproximadamente 5.000 monederos afectados, según los precios de ese momento, equivalentes a unos 110 millones de dólares. Como los métodos de agrupación de direcciones del atacante, atribución de transacciones y estadísticas de la transferencia posterior de fondos varían entre distintas instituciones, la magnitud final de la pérdida aún debe confirmarse con los informes posteriores de Coinkite, las firmas de análisis on-chain y las investigaciones de las autoridades.
Pero, independientemente de cuál sea la cifra final, ya se trata de un incidente grave suficiente para quedar registrado en la historia de la seguridad de los monederos de hardware.
¿Qué dispositivos y usuarios podrían estar afectados?
De acuerdo con el anuncio de Coinkite, el alcance afectado está relacionado con la “versión del firmware que el dispositivo ejecutaba al generar la frase mnemónica”, no con el simple momento en que el usuario compró el dispositivo.
Coinkite mencionó que las versiones 4.0.1 a 4.1.9 de Mk2/Mk3 presentan riesgos; las semillas generadas por dispositivos como Mk4, Mk5, Q, etc., antes de que se publicara el firmware corregido, también se vieron afectadas, aunque con distinta gravedad.
Coinkite ha publicado un firmware de corrección, incluyendo la versión 4.2.0 o superior para Mk2/Mk3, la versión 5.6.0 o superior para Mk4/Mk5 en la edición estándar, la versión 1.5.0Q o superior para la edición Q estándar, y las versiones de corrección correspondientes en la rama Edge.
El punto clave es este: la actualización del firmware solo repara la generación futura de nuevas frases mnemónicas; no puede hacer que las frases mnemónicas antiguas vuelvan a ser seguras.
Si el monedero del usuario se generó en un firmware afectado, lo correcto suele ser actualizar a un firmware corregido, generar una frase mnemónica nueva y nuevas direcciones del monedero, hacer primero una prueba con un monto pequeño y luego migrar el resto de los activos.
¿Por qué incluso un “monedero en frío” puede tener problemas?
Mucha gente cree que, como el monedero en frío no está conectado, entonces es naturalmente seguro. Esa comprensión solo acierta a medias.
Los monederos en frío sí pueden reducir la probabilidad de ataques en línea, riesgos de custodia en exchanges, filtraciones mediante complementos del navegador y ataques remotos con troyanos. Pero la base de un monedero en frío son las claves privadas. Si durante la generación la aleatoriedad de la clave privada o de la frase mnemónica fue insuficiente, el monedero en frío tampoco puede compensar esa deficiencia incluso estando sin conexión.
El núcleo de la seguridad de un monedero de Bitcoin no es “que el dispositivo se vea seguro”, sino tres cuestiones:
¿La frase mnemónica se generó con una fuente de aleatoriedad suficientemente fuerte? ¿El firmware y el hardware fueron auditados a fondo? ¿Los usuarios tienen estrategias correctas de respaldo, migración y multifirma?
La gravedad del incidente de Coldcard radica en que no se trata de un error típico de operación del usuario, sino de un problema en la lógica de generación de claves dentro de la cartera de hardware. Para los usuarios, este tipo de riesgo es el más difícil de identificar porque la interfaz aún muestra correctamente la frase mnemónica y las direcciones, y los activos también se pueden recibir de forma normal.
Lecciones para los usuarios de Bitcoin
Primero, no entiendas “monedero en frío” como seguridad absoluta. El monedero en frío es parte de un sistema de seguridad, no es la seguridad en sí misma.
En segundo lugar, el proceso de generación de la frase mnemónica es más importante que la marca del monedero. Una marca conocida, un dispositivo sin conexión y un proceso que parece profesional; si falla la generación de números aleatorios, aun así el resultado podría ser el robo de los fondos.
En tercer lugar, los usuarios con BTC de alto patrimonio neto no deberían depender a largo plazo de monederos de firma única. La configuración básica para quien mantiene durante mucho tiempo debería incluir mult isig, combinaciones de dispositivos de distintos fabricantes, un passphrase fuerte de BIP-39, gestión de copias de seguridad sin conexión y simulacros de seguridad periódicos.
En cuarto lugar, las actualizaciones de firmware deben hacerse a tiempo, pero la actualización no es una solución milagrosa. Para las semillas débiles ya generadas, la solución real es migrar los activos, no simplemente tocar una vez la actualización.
El veredicto de PunkHash: la esencia de la seguridad del hardware es la “confianza verificable”.
PunkHash ha estado siguiendo a largo plazo el hardware para Bitcoin, los equipos de minería, el Solo Miner, la cadena de suministro de mineros y la infraestructura de Mining & AI. Vemos una tendencia clara: a medida que más activos, capacidad de cómputo y equipos de IA entran en sistemas de hardware, la competencia de la industria ya no se trata solo de precio, rendimiento y entrega; la capacidad de verificación de seguridad será cada vez más importante.
Para mineros, poseedores de BTC y marcas de hardware, lo que realmente vale la pena construir no es un eslogan de “seguridad y fiabilidad”, sino un conjunto de mecanismos verificables:
¿El firmware clave es auditable? ¿Los procesos de números aleatorios, claves y firma se verificaron de forma independiente? ¿Son claras las pruebas de fábrica, el historial de versiones y la ruta de actualización? Si aparece una vulnerabilidad, ¿la empresa puede divulgarla, corregirla y guiar rápidamente la migración de los usuarios? ¿Los usuarios saben qué riesgos puede resolver el dispositivo y cuáles deben resolverse mediante el proceso de operación?
El incidente de Coldcard no niega los monederos en frío; está recordándole a la industria: la confianza en el hardware de Bitcoin no puede basarse solo en la reputación de marca; debe sustentarse en la transparencia de la ingeniería, la evidencia de pruebas y el mantenimiento de seguridad a largo plazo.
FAQ
¿Qué es la vulnerabilidad de Coldcard?
La vulnerabilidad de Coldcard afecta a ciertas versiones de firmware: durante la generación de la frase mnemónica, el proceso de generación de números aleatorios tiene defectos, lo que provoca una aleatoriedad insuficiente en la frase mnemónica y podría permitir que un atacante la deduzca sin conexión.
¿Los monederos en frío siguen siendo seguros?
Los monederos en frío siguen siendo una herramienta importante para la seguridad de activos, pero no equivalen a seguridad absoluta. La seguridad del monedero en frío depende de la generación de la frase mnemónica, de la implementación del firmware, del método de respaldo, de la operación del usuario y de la estrategia de mult ifirma.
¿La actualización del firmware puede resolver el problema?
La actualización del firmware puede corregir el problema de generación de nuevas frases mnemónicas, pero no puede reparar las frases mnemónicas antiguas que ya fueron generadas mediante un firmware afectado. Los usuarios afectados deben migrar a los nuevos monederos generados.
¿Qué tipo de usuarios tiene el mayor riesgo?
Los usuarios que tienen más riesgo son aquellos que generan frases mnemónicas usando firmware Coldcard afectado, no agregan suficiente entropía de dados independientes, no usan un passphrase fuerte de BIP-39, y mantienen a largo plazo un saldo grande de BTC.
¿Cómo se deben custodiar grandes activos en Bitcoin?
Los grandes activos de BTC son más adecuados para una configuración con mult ifirma, combinaciones de carteras de hardware de distintos fabricantes, respaldos sin conexión, un passphrase fuerte, gestión de fondos por capas y verificaciones de seguridad periódicas.
Conclusión
La vulnerabilidad de números aleatorios de Coldcard le dio una lección a toda la industria de Bitcoin: la verdadera seguridad no es solo la palabra “sin conexión”, sino el sistema completo que va desde la aleatoriedad, el firmware, el hardware, el respaldo y la migración, hasta el flujo del usuario.
Para los usuarios que mantienen BTC a largo plazo, la seguridad de los activos no debe quedar en manos de un único dispositivo.
Para las marcas de hardware de Bitcoin, la competencia del futuro no será solo por el rendimiento y el precio, sino por quién pueda hacer la seguridad más transparente, más verificable y digna de confianza a largo plazo.