El fallo de Ledger podía mostrar una transacción y firmar otra: qué deben hacer los usuarios

La aplicación de Ethereum de Ledger tenía un fallo en ciertos flujos de firma transparente (clear signing) que podía permitir que una dApp maliciosa sustituyera los datos de una transacción mientras el usuario revisaba la operación original. En el escenario más preocupante, la pantalla del dispositivo seguiría mostrando detalles legítimos aunque el Ledger terminara firmando una solicitud diferente. 39

Ledger afirma que su equipo de seguridad Donjon identificó y corrigió el problema antes de que TestMachine lo hiciera público. El parche llegó con la aplicación de Ethereum 1.22.2, publicada el 12 de agosto de 2026, mientras que TestMachine comenzó a divulgar sus hallazgos el 21 de agosto. 569

Cómo funcionaba el ataque de sustitución de firmas

El fallo estaba relacionado con la gestión de los comandos APDU, es decir, los mensajes que intercambian el ordenador, el navegador o una dApp conectada con la aplicación de Ethereum del Ledger. En un flujo normal de firma transparente, el dispositivo recibe los datos de la transacción, muestra en pantalla sus elementos relevantes y espera a que el usuario los revise y apruebe.

Según la investigación divulgada, una web o dApp maliciosa con acceso a WebHID podía enviar un segundo comando APDU mientras la primera transacción seguía en revisión. Esto provocaba una condición de carrera entre dos solicitudes de firma. El flujo vulnerable no vinculaba de forma fiable la transacción mostrada en el dispositivo con una única sesión de firma inmutable, lo que abría la puerta a sustituir los datos que finalmente se firmaban. 3715

El riesgo práctico no era simplemente que una transacción fallara. El usuario podía ver una acción aparentemente inofensiva y aprobarla mientras el dispositivo terminaba firmando una autorización de tokens, una transferencia u otra operación distinta y maliciosa. Eso habría debilitado precisamente la principal función de la firma transparente: comprobar los detalles en la pantalla del dispositivo antes de autorizar una operación. 110

Qué cambió con la versión 1.22.2

La actualización de la aplicación de Ethereum corrigió el flujo de firma afectado. Los análisis técnicos de los cambios indican que la versión 1.22.2 impide que una nueva sesión de firma sustituya a otra que ya está siendo revisada y rechaza una confirmación cuando el estado de la aplicación ya no coincide con la solicitud activa. 10

El director tecnológico de Ledger, Charles Guillemet, afirmó que el equipo Donjon encontró la vulnerabilidad con herramientas de detección asistida por inteligencia artificial y desplegó la solución el 12 de agosto. Los informes describieron las notas de lanzamiento como un aviso breve sobre problemas de seguridad, no como un boletín técnico detallado. 356

La diferencia es importante para los usuarios. Instalar una versión nueva protege el flujo de firma a partir de ese momento, pero un registro de cambios tan escueto ofrece poca información sobre qué se modificó o si los propietarios de los dispositivos debían actuar de inmediato.

La divulgación pública de TestMachine y Azimuth

TestMachine afirmó que su agente de inteligencia artificial, Azimuth, encontró el problema durante un análisis autónomo y que el equipo validó el comportamiento en un Ledger Flex. En publicaciones difundidas entre el 21 y el 23 de agosto, TestMachine explicó que una dApp maliciosa podía introducir una carrera entre comandos APDU durante la revisión de una transacción y presentó el problema como una vulnerabilidad de todos los Ledger que ejecutaran la aplicación de Ethereum. 4715

La divulgación llamó la atención sobre una vulnerabilidad que Ledger asegura que ya había sido corregida. TestMachine también afirmó que rechazó una recompensa por reportarla, mientras que Ledger cuestionó la forma en que se desarrolló la comunicación entre ambas partes. 1612

El desacuerdo sobre quién la descubrió primero

La disputa se centra principalmente en la cronología del descubrimiento y la divulgación privada, no en la existencia del parche.

La versión de Ledger, expresada por Guillemet, es que Donjon descubrió el fallo, lo corrigió y publicó la solución aproximadamente dos semanas antes de que TestMachine difundiera sus conclusiones. El directivo criticó la divulgación posterior por haber generado una alarma innecesaria y sostuvo que la vulnerabilidad ya estaba solucionada. 6712

TestMachine sostiene que Azimuth encontró y validó el problema de forma independiente, y que el lanzamiento silencioso de Ledger no advirtió de manera significativa a los usuarios sobre el riesgo. Sus publicaciones destacaron el escenario de ataque y el alcance de su afirmación. 715

Los informes disponibles respaldan la fecha del parche, el 12 de agosto, y las fechas de las publicaciones públicas, entre el 21 y el 23 de agosto. Sin embargo, no establecen de forma independiente las fechas exactas del descubrimiento privado, las comunicaciones entre los equipos ni una cronología completa. Por eso, esos detalles deben tratarse como versiones enfrentadas y no como hechos definitivamente resueltos. 56912

Qué dispositivos Ledger podrían estar afectados

La afirmación amplia de TestMachine se basó en el código compartido de la aplicación de Ethereum y del proceso de firma, pero la validación práctica que comunicó se realizó en un Ledger Flex. Los informes identificaron familias modernas que podrían compartir el código relevante, entre ellas Nano S Plus, Nano X, Stax y Flex. 2720

Esto no equivale a una prueba de concepto completa e independiente en todos los modelos de Ledger. A fecha del 24 de agosto, la expresión «todos los Ledger» seguía siendo una afirmación de los investigadores, no un resultado demostrado públicamente en cada línea de dispositivos. Conviene distinguir entre una ruta de software potencialmente compartida y un exploit reproducido públicamente en cada modelo.

¿Se robaron fondos de algún usuario?

A fecha del 24 de agosto de 2026, no se habían comunicado robos verificados de forma independiente que estuvieran vinculados específicamente a esta vulnerabilidad. Tampoco se había confirmado una demostración pública completa que cubriera todos los dispositivos incluidos en la afirmación. 25614

Esto describe la evidencia disponible en ese momento; no demuestra que el fallo nunca se explotara. La vulnerabilidad era grave porque podía anular la revisión de la transacción en el dispositivo, una comprobación de seguridad fundamental para los usuarios, aunque los informes disponibles no recogieran pérdidas confirmadas.

Qué deben hacer los usuarios de Ledger

Los usuarios deben abrir Ledger Live y actualizar la aplicación de Ethereum a la versión 1.22.2 o posterior. También deben mantener actualizado el firmware del dispositivo y el resto de las aplicaciones instaladas. Para este fallo concreto, la medida de corrección relevante era actualizar la aplicación de Ethereum, no limitarse a instalar una actualización de firmware. 515

Después de actualizar, la revisión en la pantalla del dispositivo sigue siendo esencial: hay que comprobar el destinatario, el importe y la acción del contrato que muestra el Ledger antes de aprobar cualquier operación. La actualización corrige la ruta de sustitución de sesiones descrita en los informes, pero revisar con atención cada transacción continúa siendo una práctica básica de seguridad.