Una bandera de compilación que permaneció inactiva en el firmware de la billetera de hardware COLDCARD durante cinco años ha sido vinculada al robo de aproximadamente $116 millones en bitcoin, después de que una configuración de compilación errónea debilitara silenciosamente la aleatoriedad utilizada para generar las semillas de los usuarios. Lo que comenzó como una elección de configuración pasada por alto se convirtió en uno de los mayores robos de autocustodia registrados en 2026.

Según Block Engineering, el firmware COLDCARD afectado definía la macro MICROPY_HW_ENABLE_RNG como cero, mientras que la biblioteca libngu verificaba solo si la macro existía, y no su valor real. Esto hizo que el sistema recurriera al generador seudorrandómico determinista Yasmarang de MicroPython, que produce resultados previsibles y socava de forma fundamental la entropía que una billetera de hardware está diseñada para garantizar.

Cómo la bandera de compilación pasó a ser central en el exploit

Una bandera de compilación es un interruptor en tiempo de compilación que determina qué funciones se activan cuando el software se ensambla en un binario distribuible. En este caso, la bandera debía activar un verdadero generador de números aleatorios de hardware. En cambio, se estableció en cero y la lógica de verificación posterior no detectó la discrepancia.

Como la bandera gobernaba la forma en que se sembraban las claves privadas, las consecuencias fueron graves. Las semillas son el secreto maestro detrás de cada dirección que controla una billetera. Una aleatoriedad predecible en el momento de la generación de la semilla significa que un atacante que comprenda la falla puede reconstruir las claves privadas resultantes.

TRM Labs informó que los atacantes drenaron 1,816 BTC — valorados en aproximadamente $116 millones — desde más de 5,200 direcciones en cuatro oleadas separadas. La magnitud de la campaña indica que la vulnerabilidad afectó a una amplia población de dispositivos y no a un grupo aislado de usuarios.

Block Engineering afirmó que la explotación activa ya estaba en curso cuando publicó su análisis el 30 de julio de 2026, y remitió a los usuarios al fabricante de la billetera, Coinkite, para el informe definitivo.

Qué falló entre el desarrollo, la revisión de lanzamiento y los controles de seguridad

La supervivencia de una bandera mal configurada durante múltiples ciclos de lanzamiento apunta a fallas en la cadena de verificación. La seguridad de las billeteras de hardware depende de firmas de código estrictas, compilaciones reproducibles y controles de integridad rigurosos, precisamente las salvaguardas que debieron haber identificado una macro RNG con valor cero.

Coinkite cuantificó directamente el déficit de entropía. Dijo que las semillas generadas en dispositivos Mk4, Q y Mk5 con firmware anterior a la corrección contenían aproximadamente 72 bits de entropía en lugar de los 128 bits esperados, una reducción que hace viable la reconstrucción por fuerza bruta de las claves privadas. En términos criptográficos, 72 bits representa un espacio de claves aproximadamente 2^56 veces menor que el estándar previsto de 128 bits, cruzando el umbral de lo computacionalmente inviable a lo práctico para un atacante con suficientes recursos.

Coinkite indicó que los fondos generados en el firmware afectado siguen en riesgo a menos que la semilla se haya creado con al menos 50 lanzamientos de dados independientes y privados, o que la billetera esté protegida con una frase de contraseña BIP-39 fuerte y única. La remediación también está fragmentada, dividida entre cinco canales de lanzamiento distintos en lugar de un único parche universal.

La diferencia entre comprobar la existencia de una macro y comprobar su valor representa el tipo de falla lógica sutil que los controles automáticos de integridad y la revisión de código buscan detectar. La mayoría de los ataques documentados contra billeteras de hardware han dependido de manipulación física, técnicas de canal lateral o compromisos en la cadena de suministro; una falla de configuración en tiempo de compilación que debilita silenciosamente la entropía durante años de producción representa un modo de fallo distinto que los modelos de amenaza existentes quizá no anticiparon adecuadamente. Los usuarios de billeteras de hardware esperan un estándar de protección más alto que el de las aplicaciones convencionales precisamente porque una semilla comprometida no puede rotarse tan fácilmente como una contraseña.

Implicaciones más amplias para los usuarios de billeteras de hardware y el sector

Una pérdida de nueve cifras cuestiona directamente la propuesta de valor central del almacenamiento en frío. El momento es relevante: la adopción de la autocustodia se aceleró después de que el colapso de FTX en noviembre de 2022 erosionara la confianza en los intercambios centralizados, lo que hace que vulnerabilidades de billeteras de hardware de esta magnitud sean especialmente dañinas para la credibilidad del ecosistema. CoinDesk informó el 31 de julio de 2026 que el exploit ya había provocado el robo de casi 600 BTC, valorados en ese momento en aproximadamente $38 millones. Los analistas sugirieron que el incidente podría actuar como catalizador para el interés en custodios regulados y ETFs spot de bitcoin.

El sentimiento del mercado reflejó la disrupción. El Fear & Greed Index se situó en 25, lo que indica miedo extremo, mientras bitcoin cotizaba cerca de $64,766.

Para los usuarios afectados, las preguntas prácticas inmediatas son: qué canal de firmware aplica a su dispositivo, si su semilla cumplía con la exención de lanzamientos de dados o frase de contraseña, y con qué rapidez pueden migrarse los fondos a un entorno seguro. Al 6 de agosto de 2026, Coinkite no había publicado su propia cifra acumulada de pérdidas ni una lista de direcciones del atacante, dejando el conteo de TRM Labs como referencia principal.

El incidente subraya que las configuraciones heredadas de compilación no son inertes. Un solo valor en tiempo de compilación, sin examinar durante años de ciclos de lanzamiento, se tradujo en un riesgo sistémico para una línea de productos comercializada por la fortaleza de su seguridad, un recordatorio de que el rigor operativo en la compilación es inseparable de la confianza en las soluciones de autocustodia.