Cuando el compilador te advierte y tú le pones cinta adhesiva
Hace unos días el mundo crypto se paralizó con una noticia que parece sacada de una película de hackers barata: una wallet de hardware llamada Coldcard, usada por puristas de Bitcoin para guardar sus monedas «fuera de internet», empezó a drenar fondos. No por un exploit sofisticado, ni por un ataque de ingeniería social. El culpable fue un commit de firmware con cinco letras: «runs».
Y acá es donde la wea se pone técnica e interesante.
La historia del bug más caro de 2026
Coldcard es una wallet de hardware canadiense que promete seguridad extrema. Funciona con un microcontrolador STM32 y corre MicroPython sobre C. El problema nació cuando un desarrollador intentó sobrescribir la función de generación de números aleatorios del hardware (RNG) para poner su propia versión. Como en C no puedes definir dos veces la misma variable, el compilador le tiró un error de símbolo duplicado: «duplicate symbol pyb_rng_get_obj».
En vez de sentarse a entender por qué fallaba, el programador desactivó el RNG de hardware con una línea que suena inocente: #define MICROPY_HW_ENABLE_RNG (0). Eso hizo que el error desapareciera. El firmware compiló, pasó los tests, y salió a producción. El mensaje del commit, con una ironía dramática, fue «runs». El segundo commit relacionado fue aún peor: un simple «x».
Lo que el desarrollador no entendió es que desactivar el RNG de hardware forzó a la wallet a usar un generador pseudoaleatorio llamado Yasmarang, que es inseguro para crear claves criptográficas. Cuando un usuario generaba una nueva wallet, la función random.bytes(32) —que debería producir 32 bytes de entropía criptográfica sólida— devolvía números predecibles. Los atacantes pudieron reconstruir las claves privadas y vaciar las wallets. Galaxy Research estima que se robaron más de 70 millones de dólares en Bitcoin.
La lección que no enseñan en la universidad
Desde mi pega como sysadmin y estudiante de ciberseguridad, esto me recuerda algo que repito cada vez que puedo: la complejidad es el enemigo. Coldcard usa capas sobre capas: C embebido, bindings a Python, librerías de MicroPython, y encima código custom del equipo. Cuando mezclas demasiadas abstracciones sin entender qué pasa en el metal, terminás con un compilador gritándote una advertencia que decidís ignorar.
Y acá hay otro punto caleta: el compilador le estaba haciendo un favor. Le decía «che, tenés dos definiciones de la misma cosa, arreglalo». En vez de eso, apagó la alarma y siguió manejando. En ciberseguridad, eso es exactamente lo que no hay que hacer. Nunca silencies una advertencia del compilador sin entender por qué existe.
MicroPython da la ilusión de que podés hacer programación embebida sin saber C. Eso es mentira. Y esta catástrofe es la prueba. Si estás tocando el código que protege plata de gente real, no alcanza con que «compile y corra». Tenés que saber por qué corre.
Mi opinión
No uso hardware wallets de código cerrado, pero si alguna vez pensé que Coldcard era la excepción segura, este caso me hizo cambiar de opinión. Un commit de un solo carácter de mensaje, cambiando 1.500 líneas de código crítico, sin peer review suficiente, debería haber activado todas las alarmas antes de llegar a un dispositivo que guarda millones. Si en Komatsu viéramos un commit así en el software de un camión autónomo, alguien perdería el puesto el mismo día.
La moraleja es simple: cuando el compilador te avisa, prestá atención. No le pongas cinta. Porque en el fondo, ese error que estás ignorando puede ser la diferencia entre tu wallet llena y una dirección vacía que algún atacante ya vació mientras dormías.
Fuente de inspiración: When random.bytes() runs but doesn’t work
