Sistemas

La vulnerabilidad rompía una de las promesas que justifica comprar una hard wallet, que la pantalla del dispositivo muestre lo que realmente se está firmando. Ledger la cerró el 12 de agosto en la versión 1.22.2 de su aplicación de Ethereum. El texto completo de las notas de esa versión, en el apartado de correcciones, lo describe en dos palabras: «Security issues«. Diez días después, la firma de seguridad TestMachine publicó el detalle técnico. Y empezó la pelea.

El ejemplo que usó TestMachine en X es el más claro. Hacés clic en «enviar 0,01 ETH a Alice» en una aplicación descentralizada. El Ledger muestra: enviar 0,01 ETH a Alice. Aprobás. La firma que devuelve el dispositivo autoriza `approve(atacante, MAX_UINT256)` sobre tus DAI, es decir acceso ilimitado a ese token para una dirección ajena.

Nada en la pantalla se veía mal, porque nada estaba mal en la pantalla. La causa raíz, según la propia descripción de la firma, es que mientras la interfaz de revisión estaba pendiente, el bucle de comandos APDU seguía aceptando instrucciones. APDU es el canal por el que la computadora le habla a la aplicación que corre en el dispositivo. Un sitio malicioso con acceso vía WebHID podía meter un segundo comando durante la ventana en que el usuario todavía estaba leyendo el primero, y reemplazar la transacción a firmar sin tocar lo que se mostraba.

TestMachine dice que la falla la encontró Azimuth, su agente de escaneo automático, durante un análisis autónomo de la app; que la validó en un Ledger Flex; y que rechazó cobrar cualquier recompensa. Señaló además que el Nano X, el Nano S Plus, el Stax y el Apex comparten el mismo código de APDU e interfaz.

A todo esto, resulta preocupante que los usuarios de Ledger no reciben avisos sobre la necesidad de actualizaciones de carácter regular en las apps instaldas, como fue en este caso -y lo corroboramos en Sistemas-. O sea, uno tiene que dirigirse al apartado de apps instaladas, dentro de Ledger Wallet, desbloquear el contenido en pantalla con el pin del dispositivo, y recién en esa instancia se puede saber sobre actualizaciones. En cambio, cuando hay updates para el programa Ledger Wallet, este avisa inmediatamente cuando se lo abre, desde la pantalla inicial.

La respuesta de Ledger

Charles Guillemet, director de tecnología de la empresa, salió el 23 de agosto con un posteo frontal, donde dijo que circulaba FUD sobre los firmantes de Ledger, impulsado por «una compañía de seguridad de contratos inteligentes». Reconoció el bug en ciertos flujos de clear signing, y sostuvo que lo había encontrado su propio equipo de investigación, Donjon, usando su suite de descubrimiento de vulnerabilidades asistida por inteligencia artificial, con el parche desplegado dos semanas antes.

Sobre la secuencia de divulgación fue tajante. La firma contactó al programa de recompensas de Ledger recién después de que el arreglo ya estaba publicado, y nunca discutió el asunto con ese equipo. «Después publicaron un hilo insinuando que el problema no está resuelto. No lo está. Eso no es investigación de seguridad. Eso es fabricar miedo para llamar la atención», escribió. Agregó que la investigación a velocidad de IA solo mejora la seguridad del ecosistema si los investigadores igual divulgan de forma responsable y verifican antes de publicar.

La réplica sobre el parche silencioso

TestMachine volvió con una cronología que traslada la discusión a otro terreno. El 6 de agosto los arreglos se subieron a la rama de desarrollo, en público. El 13 se fusionó el pull request, se etiquetó la 1.22.2 y se creó el borrador del release. Ese borrador quedó quieto hasta el 24: sin aviso de seguridad, sin notificación. Los usuarios podían actualizar por Ledger Live, pero la publicación de la versión no era pública.

El argumento central es ese hueco. Los commits del arreglo estuvieron a la vista todo ese tiempo, así que cualquiera que siguiera el repositorio de LedgerHQ podía leer el diff, deducir la vulnerabilidad y construir un exploit, mientras los usuarios no tenían ninguna indicación de que estaban expuestos ni de que necesitaban actualizar. Ese es, dicen, el problema del parche silencioso.

Fecha	Hecho
6 de agosto	Los arreglos se suben al repositorio público de desarrollo
12–13 de agosto	Se etiqueta la versión 1.22.2; el changelog dice «Security issues»
21 de agosto	TestMachine publica el hilo con el detalle técnico
23 de agosto	Guillemet acusa de fabricar miedo
24 de agosto	Ledger publica finalmente el release en GitHub

Lo que muestran los registros de Ledger

Dos documentos públicos de la propia empresa permiten evaluar la disputa sin depender de ninguna de las dos versiones.

El changelog del repositorio app-ethereum confirma la versión 1.22.2 con fecha 12 de agosto de 2026 y la descripción de dos palabras. La versión anterior, la 1.22.1 del 27 de mayo, sí detalla su corrección: inestabilidad en el manejo de comunicación APDU.

El índice de boletines de seguridad de Donjon es más elocuente. Su entrada más reciente es la LSB 022, del 4 de junio, sobre recuperación de claves secretas de Monero. No hay ningún boletín que cubra la versión del 12 de agosto.

La LSB 015, del 13 de enero de 2021, se titula «los datos de transacción de activos no soportados no son mostrados por la app de Ethereum 1.6.0». Misma aplicación, mismo tipo de problema —el usuario no ve lo que firma— y en aquel momento recibió un boletín numerado, fechado y documentado públicamente.

Las dos afirmaciones centrales pueden ser ciertas a la vez. Donjon pudo haber encontrado y corregido la falla primero; Azimuth pudo haberla encontrado por su cuenta después, con el parche ya publicado pero sin que nadie supiera qué contenía. Nada en el material disponible contradice ninguna de las dos.

La discusión real no es sobre quién llegó antes sino sobre qué obligación tiene un fabricante después de arreglar. Guillemet tiene razón en que un usuario actualizado estaba protegido. TestMachine tiene razón en que un usuario no puede decidir si actualizar con urgencia cuando el motivo se resume en dos palabras, y en que un commit público es un mapa para cualquiera que sepa leerlo.

No hay, hasta ahora, ningún robo verificado atribuido a esta falla. Tampoco hay un boletín fechado que identifique versiones afectadas y parche, que es lo único que permitiría a un usuario confirmar por sí mismo desde cuándo estuvo expuesto.

Cómo se resuelva? Abrir Ledger Live, actualizar la aplicación de Ethereum y verificar que diga 1.22.2 o superior. Actualizar solo el software de escritorio no alcanza, porque el código vulnerable corre en el dispositivo. Dejar claro que el hecho no comprometió el hardware ni el modelo de seguridad del chip.

Por Sistemas, el 27/08/2026.

Historias relacionadas