Ledger cierra un fallo en la aplicación de Ethereum: cuando la pantalla muestra algo distinto de lo que firmas

Si tienes una Ledger y gestionas con ella ether o tokens ERC-20, abre Ledger Live y comprueba qué versión de la aplicación de Ethereum está instalada en el dispositivo. Si aparece una anterior a la 1.22.2, falta una corrección de seguridad. Esa corrección cierra un fallo que anulaba precisamente la promesa por la que uno compra una cartera de hardware: que en la pantalla aparezca lo que el dispositivo va a firmar.

El caso se hizo público el 24 de agosto de 2026, cuando la firma de seguridad TestMachine publicó su análisis. La corrección ya existía en ese momento. Entre ambas fechas se sitúa una disputa sobre quién encontró el fallo primero y cuándo lo distribuyó Ledger. Para ti, como propietario, esa disputa es secundaria. Lo importante es el número de versión de tu dispositivo y la cuestión de qué aprobaciones concediste en el pasado.

Fallo de seguridad de Ledger en la aplicación de Ethereum: qué ocurrió exactamente

No estaban afectados ni el firmware del dispositivo ni la custodia de la clave privada. El problema estaba en la aplicación de Ethereum, ese pequeño programa que instalas de forma adicional en el dispositivo para ether y tokens ERC-20. Prepara una transacción, te la muestra y recoge tu confirmación.

En la versión defectuosa, esa secuencia podía desordenarse. Una aplicación web maliciosa con acceso al dispositivo conectado podía enviar una segunda orden de firma mientras la primera transacción seguía en pantalla a la espera de revisión. La aplicación intercambiaba entonces los datos en memoria sin abrir una nueva pantalla de comprobación. En el display permanecía la transferencia inofensiva que acababas de examinar. Tu confirmación, sin embargo, se aplicaba a los datos sustituidos.

Según los investigadores de seguridad, el patrón se ha reproducido de forma demostrable en una Ledger Flex. Como los dispositivos comparten en gran medida el código de la aplicación de Ethereum, los Nano X, Nano S Plus, Stax y Apex se consideran también potencialmente vulnerables. Ledger no ha comunicado qué versión de la aplicación contuvo el error por primera vez; la comparación de los investigadores parte de la 1.22.1, la versión etiquetada con anterioridad, del 27 de mayo de 2026.

Clear signing explicado: por qué la pantalla es la verdadera promesa de seguridad

El clear signing designa la visualización en texto claro de los datos completos de la transacción en la pantalla de la cartera de hardware antes de que confirmes: dirección del destinatario, importe y, en las llamadas a contratos, también la acción que el contrato debe ejecutar.

Esa es la razón por la que un dispositivo así tiene sentido. Tu ordenador puede estar infectado, tu navegador puede mostrar una interfaz manipulada, la página web puede ser una falsificación. Mientras el dispositivo que tienes en la mano disponga de una pantalla propia, independiente del ordenador, y muestre en ella los datos reales, cualquier manipulación se detecta antes de que pulses el botón. La clave privada nunca abandona el dispositivo; tampoco necesita hacerlo, porque el propio dispositivo firma.

El fallo golpeó justamente esa cadena en su punto más débil. La clave siguió a salvo, el firmware quedó intacto y, aun así, al final podía salir un consentimiento distinto del que habías leído. Un dispositivo cuya pantalla ya no puede leerse como vinculante equivale, en este punto concreto, a una cartera de software en un ordenador infectado. Si quieres repasar la diferencia entre ambas arquitecturas, la encontrarás en nuestra comparativa de carteras de software y en la comparativa de carteras de hardware.

Condición de carrera y órdenes APDU: el núcleo técnico del fallo

Una condición de carrera es un error en el que el resultado depende de cuál de dos órdenes que llegan casi al mismo tiempo se procesa primero. Estos errores son traicioneros, porque el código parece correcto en sí mismo y la secuencia se ejecuta limpiamente en la inmensa mayoría de los casos. Solo salen a la luz cuando alguien provoca deliberadamente el orden.

APDU es el formato de órdenes con el que las tarjetas con chip y las carteras de hardware se comunican con el ordenador conectado. Cada paso de una firma se compone de varias órdenes de ese tipo. La aplicación de Ethereum llevaba asociado un estado que registraba qué transacción estaba pendiente de revisión. Ese estado podía sobrescribirse mientras la revisión seguía en curso.

WebHID en el navegador: por qué una página web habla con tu dispositivo

WebHID es una interfaz del navegador que permite a una página web comunicarse directamente con un dispositivo USB conectado, previa autorización expresa por tu parte. Sin ella, una cartera de hardware no podría utilizarse con comodidad en una aplicación descentralizada; con ella, la página web se sitúa más cerca del dispositivo de lo que muchos usuarios imaginan.

El ataque descrito exige que ya hayas concedido ese acceso a una página manipulada o secuestrada y que inicies allí una transacción. No funciona a distancia contra un dispositivo guardado en un cajón. Eso limita considerablemente el círculo de afectados, pero no resta valor al hallazgo: quien trabaja con regularidad con bolsas descentralizadas, puentes o interfaces de staking concede ese acceso constantemente.

Aprobación de tokens en lugar de transferencia: por qué las aprobaciones ilimitadas son tan peligrosas

En un intercambio de este tipo, el daño rara vez procede de la transferencia en sí. Procede de lo que se logra colar en su lugar.

Una aprobación de tokens, approval en inglés, es el permiso concedido a un contrato inteligente para disponer en el futuro de una determinada cantidad de tus tokens sin que confirmes de nuevo cada cargo individual. Muchas aplicaciones solicitan ese permiso sin límite, por comodidad. Una aprobación concedida no caduca y sigue vigente hasta que la revocas expresamente.

La diferencia entre una transferencia y una aprobación

Una transferencia te cuesta exactamente el importe que confirmas. Una aprobación ilimitada te cuesta, en el peor de los casos, todo el saldo del token en cuestión, y además en el momento que elija el destinatario. Por eso el cambio de una transferencia pequeña por una aprobación de amplio alcance es el ataque más rentable contra un circuito de firma. Cómo recogen los atacantes esas aprobaciones en la práctica lo detallamos en nuestro artículo sobre wallet drainers y aprobaciones de firma.

Actualizar la aplicación de Ethereum a la 1.22.2: el camino a través de Ledger Live

La versión 1.22.2 cierra la vía descrita con dos cerrojos. La aplicación rechaza una nueva sesión de firma mientras haya una revisión en curso y rechaza una confirmación entrante cuando el estado ya no coincide con lo que se mostró. La entrada correspondiente a la versión figura en el listado de versiones de la aplicación de Ethereum en Ledger; la nota se limita allí a mencionar problemas de seguridad corregidos, sin describir el fallo.

La actualización en sí no tiene nada de espectacular. Conectas el dispositivo, abres en Ledger Live la gestión de las aplicaciones instaladas y actualizas allí la aplicación de Ethereum. Los saldos existentes no se ven afectados, porque las claves se derivan de tu frase de recuperación y no residen en la aplicación. Desinstalar y volver a instalar la aplicación tampoco te cuesta monedas.

Cómo reconocer la versión instalada

Ledger Live muestra el número de versión de cada aplicación en la gestión del dispositivo. Si aparece 1.22.2 o superior, la corrección está presente. Si aparece 1.22.1 o anterior, falta. Una simple mirada al número de versión del propio Ledger Live no basta para saberlo.

Por qué una actualización de firmware no actualiza también la aplicación de Ethereum

Este es el punto en el que el caso se tuerce con más frecuencia en la práctica. El firmware, Ledger Live y las aplicaciones de cada moneda se mantienen por separado y se actualizan por separado. Quien actualiza el firmware del dispositivo y se queda tranquilo puede seguir teniendo una aplicación de Ethereum obsoleta.

Esa misma separación explica por qué las noticias sobre seguridad de carteras se cruzan tan a menudo sin encontrarse. En el caso Coldcard, el error estaba en la generación de la semilla, en los mismos cimientos, y por eso allí hacía falta una semilla nueva. Los fallos de BitBox afectaban al firmware. Aquí el error se sitúa un nivel por encima, en una aplicación reemplazable, y por eso basta con actualizar la aplicación. Tu frase de recuperación no necesita generarse de nuevo en este caso.

Revisar y revocar aprobaciones de tokens: el segundo paso tras la actualización

La actualización protege las firmas futuras. No pone orden en lo que se concedió en el pasado. Si has trabajado en los últimos meses con aplicaciones descentralizadas, merece la pena revisar las aprobaciones abiertas de tu dirección.

Los exploradores de bloques y las interfaces especializadas enumeran, para una dirección determinada, qué contratos pueden disponer de qué tokens. Las aprobaciones a contratos que ya no utilizas pueden revocarse una a una. La revocación es una transacción ordinaria y genera comisiones de red, razón por la cual la limpieza conviene hacerla en fases tranquilas y con comisiones bajas. Si quieres seguir de cerca el precio del ether mientras tanto, encontrarás nuestro análisis en la predicción del precio de Ethereum.

Un efecto secundario en el que casi nadie piensa: cada revocación aparece en tu historial de transacciones y genera comisiones. Quien documenta sus movimientos con orden lo tendrá más fácil en la próxima declaración de la renta; las herramientas fiscales y de seguimiento de cartera más habituales importan esas operaciones de forma automática.

La disputa sobre la divulgación entre Ledger y TestMachine

Sobre lo sucedido existen dos versiones que no coinciden. Ambas se recogen aquí como versiones de cada parte; ninguna de las dos está confirmada de forma independiente.

Charles Guillemet, director técnico de Ledger, declaró que el laboratorio de seguridad propio, Ledger Donjon, había encontrado el error por su cuenta y que la corrección se distribuyó unas dos semanas antes de la publicación. TestMachine, según él, se dirigió al programa de recompensas por fallos solo después. Calificó las declaraciones de la firma de seguridad como la generación de miedo para captar atención.

TestMachine replica que su propio sistema de pruebas, llamado Azimuth, detectó la vulnerabilidad en una ejecución automática sobre una Ledger Flex y que los resultados se compartieron con Ledger. En el momento de la publicación, desde el punto de vista de la firma, no había ninguna corrección disponible.

Los hechos verificables se sitúan entre ambas versiones. La entrada del registro de cambios de la versión 1.22.2 lleva fecha del 12 de agosto de 2026 y la etiqueta firmada en el repositorio del código fuente, del 13 de agosto. Sin embargo, la entrada no se hizo visible como versión publicada hasta alrededor del 24 de agosto, es decir, al mismo tiempo que el análisis de la firma de seguridad. Un usuario que quisiera comprobar entretanto si existía una corrección no podía encontrarla allí. La reconstrucción técnica de la secuencia, fechas incluidas, la ha recopilado CryptoSlate.

¿Ha salido dinero? Qué se sabe sobre los daños

Según los datos aportados hasta ahora por ambas partes, no hay ningún caso confirmado en el que el fallo se haya explotado realmente. No se documentan pérdidas y, en cualquier caso, por esta vía no era posible extraer claves privadas.

Es una buena noticia con una salvedad que hay que enunciar junto a ella. Una firma obtenida por este camino tendría en la cadena el aspecto de cualquier otra firma voluntaria. Un afectado solo advertiría la operación cuando más adelante salieran tokens de su dirección, y probablemente la atribuiría entonces a un phishing corriente. De la ausencia de casos confirmados no cabe deducir, por tanto, con certeza que no los hubiera. Se trata de una valoración, no de una afirmación demostrada.

Qué dice el caso sobre las carteras de hardware y la autocustodia

Sería una conclusión equivocada convertir este episodio en un rechazo de las carteras de hardware. El ataque exigía un acceso al dispositivo ya concedido y una aplicación maliciosa, no tocó la clave y está corregido.

La conclusión útil es otra. Una cartera de hardware traslada la confianza del ordenador a un pequeño aparato con pantalla propia, y ese aparato se compone de firmware, aplicaciones y un software acompañante que se mantienen todos por separado. La seguridad no es aquí un estado que se adquiere con la compra, sino un mantenimiento que se practica. Eso incluye mantener las aplicaciones al día, ordenar las aprobaciones con regularidad y, en saldos elevados, añadir un segundo nivel de confirmación. Qué clase de dispositivo encaja con qué saldo lo desglosamos tras el caso Coldcard en el artículo qué cartera de hardware comprar ahora.

Revisar la aplicación de Ethereum de Ledger: qué te llevas de todo esto

1. Consultar la versión y actualizar. Conecta el dispositivo, abre la gestión del dispositivo en Ledger Live y revisa la aplicación de Ethereum. Todo lo que esté por debajo de la 1.22.2 debe actualizarse, y una actualización de firmware por sí sola no basta. Cómo gestiona cada dispositivo esa separación lo muestra la comparativa de carteras de hardware.
2. Ordenar las aprobaciones de tokens abiertas. Haz que se te muestre, para tu dirección, qué contratos pueden disponer de tus tokens y revoca todo lo que ya no necesites. Si al hacerlo concluyes que quieres una dirección aparte con un saldo pequeño para el uso diario, la comparativa de carteras de software te ayudará a elegir.
3. Documentar los movimientos. Las revocaciones y las reasignaciones generan comisiones y figuran en tu historial. Regístralas sobre la marcha en lugar de reconstruirlas la próxima primavera; las herramientas fiscales y de seguimiento de cartera te ahorran la importación.

(25 de agosto de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)