Un fallo de seguridad de Coldcard podría haber expuesto 1.128 BTC valorados en 71,1 millones de dólares

Un defecto en el software de Coldcard, presente desde hace cinco años, pudo permitir a un atacante reconstruir claves privadas y vaciar más de 1.100 bitcoin. El fabricante, Coinkite, ha sugerido que la vulnerabilidad pudo detectarse con ayuda de inteligencia artificial (IA), aunque no hay pruebas concluyentes. Puntos clave - Semillas vinculadas a Coldcard expuestas: 1.128,4717 BTC, unos 71,1 millones de dólares. - Coinkite apunta a que la IA pudo localizar el fallo, pero la atribución no está demostrada. - Los usuarios con semillas afectadas deben crear nuevas carteras con firmware corregido. Barrido coordinado: cientos de monederos vaciados El caso se conoció tras un movimiento de unos 594 BTC (cerca de 38 millones de dólares entonces) desde alrededor de 500 direcciones de bitcoin de firma única el 30 de julio. Bitcoin.com News señaló que las transferencias se ejecutaron en unos 25 minutos y parecían dirigirse a carteras con una debilidad técnica común. Revisiones posteriores de la cadena ampliaron el alcance potencial. Investigadores estimaron que entre 1.082 y 1.196 direcciones pudieron verse afectadas durante un intervalo aproximado de 41 minutos. Un panel específico, Coldcard Sweep Watch, situó el total en 1.128,4717 BTC, valorados en torno a 71,1 millones de dólares cuando bitcoin cotizaba cerca de 63.044 dólares. Fuente de la imagen: panel Coldcard Sweep Watch. Captura realizada a las 8:30 a.m. (hora del Este) el 1 de agosto de 2026. Una hora después, a las 9:30 a.m., la estimación subió a 1.128,6633 BTC. La mayor parte de los fondos se consolidó en una dirección con cientos de bitcoin, donde un volumen significativo permanecía prácticamente inmóvil. Todas las direcciones afectadas compartían un elemento clave: las semillas de recuperación se habían creado en monederos físicos Coldcard fabricados por la canadiense Coinkite. La semilla de recuperación es una lista de palabras que otorga control sobre una cartera. Si alguien puede reconstruirla u obtenerla, normalmente puede mover los fondos sin necesidad de disponer del dispositivo. Coldcard detecta un fallo en el sistema de aleatoriedad Coinkite publicó una alerta urgente advirtiendo de que ciertas semillas generadas en dispositivos Coldcard podrían ser débiles. Los equipos Mk3 con firmware 4.0.1 (lanzado en torno a marzo de 2021) y versiones posteriores figuraban entre los de mayor riesgo. Análisis adicionales ampliaron la preocupación a semillas creadas en algunos Mk4, Mk5 y Q antes de que Coinkite difundiera parches de emergencia. Según la información disponible, los productos Tapsigner, Opendime y Satscard no estarían afectados, al utilizar software distinto. El problema estaba en el proceso de generación de datos aleatorios. Los monederos seguros dependen de una aleatoriedad de alta calidad para que la semilla no sea adivinable. En los Mk3 más comprometidos, los investigadores estimaron que la semilla pudo tener solo unos 40 bits de aleatoriedad efectiva en lugar de los 128 bits previstos. La diferencia es crítica: una semilla de 128 bits bien generada se considera, en la práctica, imposible de adivinar por fuerza bruta; con 40 bits, el espacio de búsqueda se reduce drásticamente y un atacante con suficiente potencia de cálculo puede probar semillas fuera de línea y cotejar las direcciones resultantes con la blockchain pública de Bitcoin. En algunos modelos más nuevos, la aleatoriedad efectiva podría haber sido de aproximadamente 72 bits gracias a una capa adicional aportada por hardware seguro. Eso dificulta la reconstrucción, pero seguiría quedando muy por debajo de lo esperado. Un error de configuración sobrevivió 5 años El origen fue un fallo de configuración en tiempo de compilación relacionado con dos funciones de software que realizaban tareas similares. Una usaba el generador de números aleatorios verdaderos basado en hardware del dispositivo; la otra recurría a un mecanismo de software más débil heredado de MicroPython. Coinkite pretendía desactivar la opción de MicroPython, pero una comprobación del software solo verificaba si una etiqueta de configuración estaba definida, no si su valor era cero. El resultado: el firmware podía seleccionar de forma silenciosa la función más débil. Como ambas funciones compartían formato, el código seguía compilando y ejecutándose sin errores evidentes. El fallo entró en el código durante una migración de software en 2021 y permaneció en firmware disponible públicamente durante más de cinco años. Actualizar el dispositivo ahora no refuerza una semilla ya generada bajo el software defectuoso. Los usuarios afectados deben crear una semilla completamente nueva con firmware corregido u otro dispositivo seguro y, después, trasladar los fondos a direcciones controladas por esa nueva semilla. Fuente de la imagen: X. Quienes añadieron al menos 50 tiradas independientes de dados al crear su semilla pueden haber aportado suficiente aleatoriedad adicional para evitar la debilidad. Una passphrase BIP39 robusta también podría haber dificultado la reconstrucción. Las carteras con varias firmas procedentes de dispositivos independientes habrían podido impedir que una única semilla comprometida moviera fondos por sí sola. Coinkite apunta a la IA, pero no aporta pruebas El consejero delegado de Coinkite, Rodolfo Novak, pidió disculpas públicamente y afirmó que la empresa asume toda la responsabilidad por el fallo del firmware. Indicó que el equipo trabaja en software corregido, informes técnicos y soporte para los usuarios afectados. Coinkite y Novak plantearon además una hipótesis llamativa sobre el hallazgo de la vulnerabilidad. Dado que el firmware llevaba años siendo público, la compañía cree que alguien pudo emplear IA para revisar versiones antiguas del código y localizar la ruta de aleatoriedad débil. “A todos los demás desarrolladores: creemos que esta es una realidad sobria del nuevo paradigma de la IA. Las revisiones de código asistidas por IA ya pueden encontrar fallos latentes a una velocidad que supera incluso a los expertos más veteranos del sector”, escribió Novak en su disculpa publicada en X. “Si vuestro firmware es de código abierto o alguna vez fue público, asumid que ya lo están leyendo atacantes y defensores por igual”. Los sistemas modernos de IA para programación pueden procesar repositorios extensos e identificar relaciones sospechosas entre ajustes de configuración, funciones y supuestos de seguridad. Un atacante podría pedir a estos sistemas que busquen generadores aleatorios débiles, funciones de respaldo o errores que afecten a claves criptográficas. Algunos observadores afirmaron haber usado modelos punteros para identificar el exploit por su cuenta. Fuente de la imagen: X. Investigadores independientes señalaron después que utilizaron modelos de IA para localizar o explicar el problema una vez conocida la raíz relacionada con la aleatoriedad. Eso evidencia lo accesible que se ha vuelto el análisis de código asistido por IA, pero no demuestra que el atacante original utilizara IA. Fuente de la imagen: entrada del blog de Coldcard sobre IA. Coinkite reconoció que su propia revisión con un modelo líder de IA no detectó el fallo antes del robo. Ese dato refuerza que la IA no encuentra automáticamente todos los defectos graves y que el resultado depende de las instrucciones, del contexto del código suministrado y de la capacidad del revisor humano para interpretar señales de alerta. Críticas: el fallo humano fue el origen Varios especialistas en seguridad sostienen que centrar el debate en la IA puede desviar la atención del problema básico de ingeniería. Consideran que el error de configuración encaja en una clase conocida de fallos de software y que revisiones de código, pruebas o auditorías enfocadas en la generación de semillas podrían haberlo detectado años antes. Otros descartan que la IA sea responsable y creen que el equipo debería haber identificado el riesgo. Fuente de la imagen: X. Las dos lecturas no se excluyen: un error humano creó la vulnerabilidad y la mantuvo viva; la IA pudo reducir el coste de encontrarla, comprenderla o explotarla. En seguridad, el defensor debe detectar todas las debilidades peligrosas, mientras que el atacante solo necesita una. El episodio también tensiona la idea de que el código abierto es, por sí mismo, garantía de seguridad. Que el código sea público permite auditorías independientes, pero no asegura que alguien revise la sección adecuada, identifique un defecto sutil y lo reporte antes de que un atacante actúe. Para los usuarios de Coldcard, la prioridad inmediata es determinar cuándo y cómo se generó su semilla. Quien tenga una semilla afectada debe verificar las instrucciones en los canales oficiales de Coinkite, instalar el firmware corregido, crear una semilla nueva y mover los fondos con cautela, vigilando posibles intentos de phishing y falsos mensajes de soporte. A más largo plazo, las incógnitas se centran en cuántos bitcoin se sustrajeron, si los investigadores podrán identificar al atacante y si la IA tuvo un papel decisivo en el hallazgo del fallo. Los fabricantes de monederos físicos afrontarán presión para reforzar las pruebas de entropía, auditar configuraciones de compilación y revisar de forma continua el código histórico con expertos humanos y herramientas de IA empleadas de manera adversarial.