Ledger corrige una vulnerabilidad en su app de Ethereum que permitía firmar transacciones distintas a las mostradas
Resumen del mercado generado por IA
Ledger corrigió una vulnerabilidad en su app de Ethereum (solucionada en la v1.22.2) que podría permitir que una aplicación web maliciosa explotara una condición de carrera para sustituir los datos de la transacción tras su revisión, convirtiendo potencialmente acciones benignas en aprobaciones perjudiciales. Aunque no se comprometieron claves privadas ni el firmware y no se han reportado pérdidas confirmadas, el incidente pone de relieve el riesgo operativo para usuarios de Ethereum/ERC-20 que interactúan con dApps mediante WebHID y podría deprimir el apetito de riesgo a corto plazo en la actividad vinculada a ETH.
Nivel de impacto
● Media
Activos afectados
ETH/USDT-1.32%
Ideas de IA · ETH/USDTIdeas de IA
▼ Bajista
Haz trading ahora
⚠️ Las ideas generadas por IA se basan en contenido de noticias y se proporcionan solo con fines informativos. No constituyen asesoramiento de inversión ni representan los puntos de vista de BingX. Invertir implica riesgos. Opera de forma responsable.
Quienes utilicen un dispositivo Ledger para gestionar Ether o tokens ERC20 deberían abrir Ledger Live y comprobar qué versión de la app de Ethereum está instalada. Cualquier versión anterior a la 1.22.2 carece de un parche de seguridad. La corrección aborda un fallo que golpea el principal valor de una cartera hardware: que la pantalla muestre con fidelidad lo que el dispositivo va a firmar.
El caso se conoció públicamente el 24 de agosto de 2026, cuando la firma de seguridad TestMachine publicó su análisis. Para entonces, el parche ya existía. Entre esas fechas se sitúa la disputa sobre quién identificó antes el problema y cuándo lo distribuyó Ledger. Para el usuario, lo esencial es el número de versión y revisar qué autorizaciones pudo haber aprobado en el pasado.
Qué ocurrió y qué no se vio afectado
El firmware del dispositivo no se vio comprometido y la custodia de la clave privada no estuvo en riesgo. El fallo residía en la app de Ethereum, el componente que se instala en el dispositivo para operar con Ether y tokens ERC20. Esa app prepara la transacción, la muestra en pantalla y recoge la confirmación del usuario.
En las versiones afectadas, ese flujo podía desordenarse. Una aplicación web maliciosa con acceso al dispositivo conectado podía enviar un segundo comando de firma mientras la primera transacción seguía en pantalla pendiente de revisión. La app intercambiaba los datos en memoria sin lanzar una nueva pantalla de revisión: el usuario seguía viendo en el dispositivo la operación inocua, pero su confirmación se aplicaba a los datos sustituidos.
Según los investigadores, el patrón se reprodujo de forma demostrable en un Ledger Flex. Dado que los dispositivos comparten en gran medida el código de la app de Ethereum, Nano X, Nano S Plus, Stax y Apex también se consideran potencialmente vulnerables. Ledger no ha especificado qué versión incorporó primero el error; la comparación de los investigadores parte de la 1.22.1, etiquetada el 27 de mayo de 2026.
"Clear signing": por qué la pantalla es la promesa de seguridad
El "clear signing" consiste en mostrar en texto claro todos los datos relevantes de una transacción en la pantalla del dispositivo antes de confirmar: dirección de destino, importe y, en llamadas a contratos, la acción que ejecutará el contrato. Esta independencia de la pantalla frente al ordenador es la razón de ser de una cartera hardware: aunque el PC esté comprometido, el navegador muestre una interfaz manipulada o la web sea fraudulenta, la pantalla del dispositivo debería exponer la realidad antes de pulsar confirmar.
En este incidente, la clave privada permaneció a salvo y el firmware no se tocó, pero aun así podía terminar firmándose un consentimiento distinto al revisado. Si la pantalla deja de ser vinculante, en ese punto concreto el dispositivo pierde parte de su ventaja frente a una cartera software en un equipo infectado.
Condición de carrera y comandos APDU: el núcleo técnico
El problema se describe como una "race condition" (condición de carrera): un fallo en el que el resultado depende de cuál de dos comandos casi simultáneos se procesa antes. Este tipo de errores es difícil de detectar porque, la mayoría del tiempo, el flujo funciona con normalidad; solo aparece cuando alguien fuerza el orden.
APDU es el formato de comandos con el que las smart cards y las carteras hardware se comunican con el ordenador. Cada firma se compone de varios comandos. La app de Ethereum mantenía un estado interno para registrar qué transacción estaba en revisión, y ese estado podía sobrescribirse mientras la revisión seguía activa.
WebHID en el navegador: por qué una web puede hablar con tu dispositivo
WebHID es una interfaz del navegador que permite a un sitio web comunicarse directamente con un dispositivo USB, tras conceder permiso de forma explícita. Sin este tipo de acceso, el uso de una cartera hardware dentro de una aplicación descentralizada sería mucho menos práctico. El ataque descrito requiere que el usuario ya haya concedido acceso a un sitio manipulado o comprometido y que inicie allí una transacción. No es un ataque remoto contra un dispositivo guardado en un cajón.
Aprobaciones de tokens frente a transferencias: el riesgo de los permisos ilimitados
En una sustitución como la descrita, el mayor daño suele venir menos de una transferencia puntual y más de lo que puede colarse en su lugar. Una "token approval" es el permiso a un contrato inteligente para gastar en el futuro una cantidad de tokens sin pedir confirmación en cada cargo. Muchas aplicaciones lo solicitan de forma ilimitada por comodidad.
La diferencia es clave: una transferencia cuesta exactamente lo que se aprueba; una aprobación ilimitada puede costar, en el peor escenario, todo el saldo del token afectado en el momento que el receptor elija. Por eso, reemplazar una pequeña transferencia por una aprobación amplia es un objetivo especialmente rentable en la ruta de firma.
Actualizar a la versión 1.22.2: cómo hacerlo en Ledger Live
La versión 1.22.2 cierra la vía descrita con dos medidas: la app rechaza iniciar una nueva sesión de firma mientras hay una revisión en curso, y descarta una confirmación entrante si el estado ya no coincide con lo mostrado en pantalla.
La actualización se realiza desde Ledger Live: conectar el dispositivo, abrir el gestor de aplicaciones instaladas y actualizar la app de Ethereum. Los saldos no se ven afectados, ya que las claves se derivan de la frase de recuperación y no residen en la app. Eliminar y reinstalar la app tampoco implica perder fondos.
Cómo comprobar la versión instalada
Ledger Live muestra la versión de cada aplicación en el gestor del dispositivo. Si figura 1.22.2 o superior, el parche está aplicado. Si figura 1.22.1 o anterior, falta. Revisar solo la versión de Ledger Live no es suficiente.
Por qué una actualización de firmware no actualiza la app de Ethereum
Firmware, Ledger Live y las apps de cada moneda se mantienen y se actualizan por separado. Es común actualizar el firmware y dar por hecho que todo queda protegido, mientras la app de Ethereum sigue desactualizada. Esta separación también explica por qué incidentes de seguridad en carteras hardware pueden ser de naturaleza distinta: a veces el fallo está en el seed, otras en el firmware, y en este caso en una app reemplazable. No hace falta regenerar la frase de recuperación.
Segundo paso: revisar y revocar aprobaciones antiguas
El parche protege firmas futuras, pero no revierte permisos ya concedidos. Si se ha operado con aplicaciones descentralizadas en los últimos meses, conviene revisar qué aprobaciones siguen activas en la dirección. Exploradores de bloques e interfaces especializadas muestran qué contratos pueden gastar qué tokens.
Las aprobaciones a contratos que ya no se usan pueden revocarse una a una. Revocar es una transacción normal y conlleva comisiones de red, por lo que suele ser más eficiente hacerlo en periodos de menor actividad y costes. Un efecto colateral: cada revocación aparece en el historial y genera gastos; documentarlo facilita la trazabilidad, también de cara a herramientas fiscales y de cartera que importan estos eventos.
Disputa de divulgación entre Ledger y TestMachine
Existen dos relatos que no coinciden y ninguno ha sido confirmado de forma independiente. El CTO de Ledger, Charles Guillemet, afirmó que el laboratorio interno Ledger Donjon detectó el error y que el arreglo se distribuyó aproximadamente dos semanas antes de la publicación. Según su versión, TestMachine se presentó después a través del programa de recompensas por fallos y sus declaraciones buscaban generar alarma.
TestMachine sostiene que su sistema de pruebas, Azimuth, descubrió la debilidad en una ejecución automatizada sobre un Ledger Flex y que compartió los resultados con Ledger. A su juicio, en el momento de la publicación no existía un parche disponible.
Los hechos verificables quedan a medio camino: el registro de cambios de la versión 1.22.2 está fechado el 12 de agosto de 2026 y la etiqueta firmada en el repositorio fuente, el 13 de agosto. La versión pasó a ser visible como lanzamiento publicado en torno al 24 de agosto, coincidiendo con el análisis de la firma de seguridad. Entre medias, un usuario no podía encontrar fácilmente esa corrección en la página de publicación.
¿Se han perdido fondos? Lo que se sabe
Con la información facilitada hasta ahora por ambas partes, no hay casos confirmados de explotación. No se han documentado pérdidas y, en cualquier caso, esta vía no permitía extraer claves privadas.
Aun así, una firma obtenida de este modo se vería en cadena como una firma voluntaria normal. La víctima probablemente solo lo detectaría cuando los tokens salieran más tarde y podría atribuirlo a phishing convencional. La ausencia de casos confirmados no prueba que no los haya habido; es una valoración, no un hecho documentado.
Qué enseña el episodio sobre carteras hardware y autocustodia
No sería razonable concluir que esto invalida las carteras hardware. El ataque exigía acceso ya concedido al dispositivo y una aplicación maliciosa, la clave permaneció intacta y el problema está corregido. La lectura útil es otra: la seguridad en autocustodia es mantenimiento continuo. Implica mantener apps actualizadas, limpiar aprobaciones con regularidad y, para patrimonios grandes, añadir capas adicionales de verificación.
Qué hacer ahora
1) Verificar versión y actualizar. Conectar el dispositivo, abrir el gestor de Ledger Live y revisar la app de Ethereum. Cualquier versión por debajo de 1.22.2 debe actualizarse; el firmware por sí solo no la actualiza.
2) Revisar aprobaciones abiertas y revocar las innecesarias. Identificar qué contratos pueden gastar tokens y eliminar permisos que ya no se usan.
3) Documentar movimientos y comisiones. Revocaciones y reajustes generan comisiones y quedan en el historial; registrarlos en el momento evita reconstrucciones posteriores.
(Actualizado a 25 de agosto de 2026. Este artículo no es asesoramiento de inversión. Precios y estructuras de comisiones cambian; revise las condiciones con el proveedor antes de comprar.)