BitBox reescribió su aviso de julio para admitir que el fallo que no afectaba a los fondos sí permitía robarlos, y 13 parches del firmware nuevo llegaron en ramas de un agente de IA
El 8 de julio, el fabricante suizo de carteras BitBox publicó su lista de fallos corregidos y la resumió en una frase tranquilizadora: ninguno afectaba directamente a los fondos de los…
El 8 de julio, el fabricante suizo de carteras BitBox publicó su lista de fallos corregidos y la resumió en una frase tranquilizadora: ninguno afectaba directamente a los fondos de los usuarios. El fallo número uno de esa lista era una escritura fuera de los límites de memoria que había reportado un investigador de CertiK, y el propio aviso decía que no llegó acompañado de ningún exploit funcional. Ayer, 40 días después, BitBox volvió a entrar en ese mismo artículo y le insertó un recuadro nuevo con fecha 17.08.2026 para decir lo contrario: el fallo es grave y, explotado, habría permitido el robo de fondos.
La corrección no llegó sola. El aviso del lunes, bautizado Dixence, estrena la versión 9.26.5 del firmware y reconoce dos vulnerabilidades graves más, las dos encontradas por el equipo de casa. La compañía dice que las localizó revisando su propio código, y añade con qué: modelos de IA de frontera. Esa frase es el hilo de esta historia, porque el registro público de su repositorio permite ver algo que el aviso no cuenta y que ningún medio ha contado.
El párrafo que ya no dice lo mismo
El aviso de julio funcionaba como la mayoría de los boletines del sector: lista de problemas, agradecimiento a quien los reportó y una valoración del riesgo. Sobre la escritura fuera de límites, reportada por Guanxing Wen desde CertiK, el texto original decía que no se podía descartar del todo un impacto en el flujo de control, que en la jerga es una manera elegante de decir "no sabemos hasta dónde llega". El recuadro añadido ayer sí lo sabe.
Clasificamos el problema como grave: si se explotaba, podría haber permitido el robo de fondos del usuario. El BitBox02 Nova no está afectado. El exploit fue descubierto internamente por ingenieros de BitBox y más tarde reportado de forma independiente por investigadores externos.
Hay dos cambios en esas tres líneas. El primero es la severidad, que pasa de indeterminada a robo de fondos. El segundo es la autoría: en julio el mérito era del investigador externo y ahora la casa dice que el exploit lo encontró antes su propio equipo. Para explotarlo hacía falta engañar al usuario con una app falsa de BitBox para que instalara firmware manipulado en un aparato auténtico, un ataque en dos tiempos que empieza por phishing, la misma pieza que sostiene los incidentes de SafePal y de Trezor.
Los dos textos tampoco coinciden en qué versión tapó el agujero. El recuadro de julio dice 9.26.3, el aviso de ayer dice 9.26.2, y la tabla de dispositivos afectados de ese mismo aviso sitúa el riesgo en las versiones hasta la 9.26.1. En el repositorio, la 9.26.2 figura como la entrega intermedia que subía el gestor de arranque a la v1.2.2, lo que encaja con esa tercera cifra. Qué versión lleva exactamente la comprobación de límites no está publicado, y el informe técnico que promete BitBox no tiene fecha.
Los dos fallos que se estrenan hoy
El primero afecta a la edición Multi, la que soporta varias monedas, y solo cuando el aparato todavía no tiene monedero configurado. Un ordenador malicioso podía provocar una corrupción de memoria y, con ella, ejecutar código arbitrario e instalar firmware manipulado. Traducido: el momento de riesgo es el primer enchufe, cuando el usuario acaba de abrir la caja. La edición solo-bitcoin no está afectada porque su firmware no contiene ese código, que es el argumento comercial de BitBox desde el primer día.
El segundo vive en los pagos silenciosos, el estándar BIP-352 que permite publicar una dirección fija sin sacrificar privacidad. Aquí no había robo posible, sino algo más incómodo de explicar: un atacante podía bloquear los fondos en una dirección de pago no prevista, y recuperarlos exigía la cooperación entre atacante y destinatario. BitBox lo llama por su nombre, ataque de rescate.
| Fallo | Versiones afectadas | Qué permitía | Quién lo encontró |
|---|---|---|---|
| Gestor de arranque | hasta 9.26.1 | Instalar firmware malicioso tras phishing | Interno, luego externos |
| Memoria en edición Multi | hasta 9.26.4 | Ejecución de código en aparato sin configurar | Interno |
| Pagos silenciosos | 9.21.0 a 9.26.4 | Bloquear fondos y pedir rescate | Interno |
| Chip seguro del Nova | enero de 2026 | Dos fallos vía programa de recompensas | Jefe de I+D de Trezor |
Los 691 días de los pagos silenciosos
El registro de cambios del firmware fecha la llegada de los pagos silenciosos en la versión 9.21.0, etiquetada en el repositorio el 25 de septiembre de 2024. El fallo que ahora se corrige vivía en ese código desde entonces, según el rango de versiones afectadas que publica la propia compañía: 679 días hasta la etiqueta de la 9.26.5, y 691 hasta el aviso público. Es el argumento que BitBox usó el 4 de agosto en un artículo sobre actualizaciones y IA: el código viejo envejece más rápido que antes porque la distancia entre descubrir un fallo y entenderlo se está comprimiendo. Trece días después llegó el aviso que lo demuestra con su propio producto.
Quién firma los parches
Aquí está el dato que no aparece en ninguna cobertura. Entre la etiqueta 9.26.4 y la 9.26.5 hay 224 commits que tocan 300 archivos, y 13 de esas incorporaciones vienen de ramas cuyo nombre empieza por agent/benma-agent/, la convención que usa el desarrollador jefe del firmware para el trabajo de su agente automático. El repositorio incluye además un archivo AGENTS.md con instrucciones de arquitectura para agentes, añadido el 11 de diciembre de 2025 y retocado 18 veces desde entonces.
Los títulos de esas ramas se leen como una lista de deberes de seguridad: limitar la profundidad de recursión en los mensajes EIP-712, limitar la profundidad de codificación de Miniscript, inicializar el búfer aleatorio del Bluetooth, inicializar los búferes de salida que Rust pasa a C, validar la longitud de los mensajes de fábrica, validar la longitud de la semilla decodificada al restaurar una copia, rechazar claves de política demasiado grandes, rechazar el emparejamiento Bluetooth mientras hay una operación en curso. En el registro de cambios público, todo eso ocupa dos palabras: "mejoras de seguridad".
La última cifra merece explicación. La etiqueta de la 9.26.5 está fechada el 5 de agosto en un repositorio abierto y el aviso salió el 17: doce días en los que cualquiera con paciencia podía leer los commits de seguridad antes de que existiera el boletín que los explica. Es el precio conocido del código abierto en hardware de custodia, y es el escenario que el artículo del 4 de agosto describía sin aplicárselo.
El mismo día, el dueño de Kraken enchufa un modelo racionado
La coincidencia de calendario ayuda a medir la escala. El lunes también anunció Payward, la matriz de Kraken, que entra en el Proyecto Glasswing de Anthropic y despliega el modelo Claude Mythos 5 sobre toda su infraestructura para buscar vulnerabilidades, con revisión humana antes de dar por bueno cada hallazgo. El acceso lo autoriza el Gobierno de Estados Unidos para operadores de infraestructura crítica, y según el comunicado del programa los socios ya han sacado a la luz miles de fallos de severidad alta o crítica desde abril.
El mismo día, entonces, un fabricante pequeño admite que la IA le encontró dos fallos graves en casa y el exchange estadounidense más antiguo se sienta en un programa con acceso restringido para hacer eso a escala industrial. BitBox añade un detalle que apunta en dirección contraria al pánico: ha recibido un número récord de reportes externos, casi todos elaborados con modelos de IA, y ninguno de esos auditores ha encontrado un fallo crítico o grave.
La otra cara
Nada de esto es un robo. No hay fondos perdidos, no hay indicios de explotación y las tres correcciones estaban listas antes de que existiera el aviso, que es el orden correcto. Reescribir un boletín viejo para empeorar la nota de un fallo es incómodo de leer y, aun así, es mejor práctica que dejarlo mal clasificado para siempre. En enero, BitBox ya había reconocido dos fallos en el chip seguro del Nova reportados por el jefe de investigación de Trezor, su competidor directo, a través del programa de recompensas.
El contraste con el trimestre lo pone el caso Coldcard, donde un fallo de generación de semillas se llevó entre 116 y 130 millones de dólares de más de 5.200 direcciones y BitBox tuvo que publicar un aviso específico para decir que sus aparatos no estaban afectados. Ahí hubo dinero fuera. Aquí hay tres agujeros tapados y una nota de severidad corregida al alza, y el usuario solo tiene una tarea, actualizar. Con el problema de siempre: un parche solo protege cuando está instalado, y en un aparato que vive en un cajón entre transacción y transacción eso puede tardar meses.
- El informe técnico detallado que BitBox promete sobre los tres fallos, y si aclara qué versión del gestor de arranque incorpora la comprobación de límites.
- Si otros fabricantes revisan al alza avisos ya publicados ahora que las auditorías con IA reabren código antiguo.
- Los intentos de phishing que aprovechen este aviso, el vector que la propia compañía señala dos veces en su texto.
- Si aparece un exploit público del fallo de memoria de la edición Multi, que actúa sobre aparatos recién sacados de la caja.
- Cuántas de las ramas del próximo firmware llevan nombre de agente, y si el registro de cambios sigue resumiéndolas en dos palabras.
- Si Payward cumple lo prometido y reporta a los mantenedores del software libre cripto los fallos que encuentre con Mythos 5, y si alguno toca monederos.
Basado en: BitBox (avisos Dixence del 17 de agosto, Oeschinen del 8 de julio y Marmorera de enero), repositorio bitbox02-firmware en GitHub (etiquetas, CHANGELOG y comparación 9.26.4 a 9.26.5), CoinDesk, Businesswire.