Se detecta una vulnerabilidad de sustitución de transacciones en la aplicación de Ethereum de Ledger

cryptonews.ruPublished on 2026-08-28Last updated on 2026-08-28

Abstract

El 27 de agosto de 2026, el fundador de OneKey, Yishi Wang, informó en X que su equipo logró replicar en laboratorio un ataque de sustitución de transacciones en la aplicación Ethereum de Ledger (versión 1.22.1). La vulnerabilidad, un "race condition", permitía sobrescribir una transacción pendiente de firma mientras el usuario la revisaba en pantalla, haciendo que el dispositivo firmara una transacción distinta a la mostrada. Ledger Donjon respondió el mismo día, afirmando que ningún usuario real resultó afectado y que el fallo ya había sido solucionado en la versión 1.22.2, publicada internamente el 13 de agosto. La comunidad señaló que esta vulnerabilidad coincidía con una divulgada públicamente por el investigador TestMachine el 22 de agosto. El boletín de seguridad oficial de Ledger (LSB 023) detalló que el defecto estaba en el SDK seguro de Ledger, permitiendo que un comando APDU nuevo sobrescribiera uno pendiente. La corrección se realizó en dos fases: primero en la aplicación Ethereum (v1.22.2) y luego en el propio SDK (v26.6.1). Ledger enfatiza que es crucial actualizar las aplicaciones específicas a través de Ledger Live, no solo el firmware. Aunque surgió un desacuerdo menor sobre si la solución final fue en la versión 1.22.2 o 1.22.3, ambas partes coinciden en la necesidad de actualizar. El análisis destaca que este tipo de fallo en la cadena de confianza subraya que la seguridad de una cartera hardware depende de todos sus componentes (firmware, SDK, aplicació...

Yishi Wang, fundador de OneKey —fabricante de monederos de hardware y desarrollador de la aplicación OneKey App— declaró el 27 de agosto de 2026 en la red social X que el equipo OneKey Anzen logró realizar en condiciones de laboratorio un ataque de sustitución de transacción en la aplicación de Ethereum de Ledger, versión 1.22.1. La subsidiaria de Ledger, Donjon, respondió el mismo 27 de agosto de 2026 en la misma red social, afirmando que ningún usuario de monederos de hardware se había visto afectado, y que lo descrito era una demostración de laboratorio de una vulnerabilidad ya corregida.

Según Wang, el problema encontrado es una condición de carrera entre la lógica de visualización de la transacción en la pantalla del dispositivo y el búfer de la transacción misma. Un atacante puede sobrescribir una transacción pendiente de firma en el momento en que el usuario está revisando la operación legítima en la pantalla. Como resultado, en la pantalla se muestra la transacción A, el usuario confirma esa, pero el dispositivo en realidad firma una transacción B completamente diferente que el usuario no vio. Para verificar el ataque, el equipo de OneKey compiló de forma independiente el archivo ELF de la versión 1.22.1. Wang señaló que Ledger corrigió la vulnerabilidad en la versión 1.22.3 de la aplicación, y recomendó a los propietarios de versiones anteriores que actualicen.

En los comentarios de la comunidad a su publicación se aclara que el error encontrado coincide con una vulnerabilidad que el investigador TestMachine había revelado públicamente el 22 de agosto de 2026, y que Ledger la corrigió en la versión 1.22.2, no en la 1.22.3.

Lo que contó TestMachine

El investigador TestMachine informó el 22 de agosto de 2026 que la vulnerabilidad fue detectada por la herramienta de escaneo autónomo Azimuth durante una revisión de la aplicación de Ethereum de Ledger. El error fue confirmado en el dispositivo Flex, y afectó al código común de procesamiento de comandos APDU y a la interfaz, utilizado también en los modelos Nano X, Nano S Plus, Stax y Apex. En el momento de la publicación, la versión corregida 1.22.2 aún no había sido lanzada. Dos días después, el 24 de agosto, TestMachine destacó la aparición del lanzamiento 1.22.2 en GitHub con la nota «Security issues» y aconsejó actualizar la aplicación a través de Ledger Live.

Posición de Ledger Donjon

Según la declaración de Donjon, no se registraron casos de hackeo de usuarios reales. El problema se descubrió como parte de su proceso interno de seguridad y se corrigió en la versión 1.22.2, lanzada el 13 de agosto de 2026, es decir, antes de la publicación de OneKey. La empresa no encontró pruebas de explotación en condiciones reales. Se recomienda a los usuarios actualizar las aplicaciones a la última versión, y la aplicación de Ethereum al menos a la 1.22.3, a través de Ledger Wallet, verificando por separado la versión de la aplicación en el propio dispositivo.

Boletín oficial LSB 023

En el boletín de seguridad oficial de Ledger publicado el 27 de agosto de 2026, con el número LSB 023, se describe la clase de vulnerabilidad: mientras el usuario revisaba una operación en la pantalla, el dispositivo anfitrión podía enviar un nuevo comando APDU sobre uno anterior aún no procesado, lo que permitía cambiar los parámetros de firma después de que se mostraran al usuario, pero antes del momento de la firma real. El defecto está en el procesamiento de entrada/salida de Ledger Secure SDK, no en el sistema operativo del dispositivo o en el firmware.

La corrección se realizó en dos etapas:

  • A nivel de aplicaciones individuales: la primera actualizada fue la versión de Ethereum 1.22.2, lanzada el 13 de agosto de 2026;
  • A nivel del propio SDK: la versión v26.6.1 se lanzó el 21 de agosto de 2026, tras lo cual las aplicaciones se recompilaron teniendo en cuenta el framework actualizado.

La empresa enfatiza que actualizar solo el firmware no es suficiente: los usuarios deben actualizar las aplicaciones a través de Ledger Live. Ledger reitera que no se han encontrado pruebas de explotación de la vulnerabilidad contra usuarios.

Cronología de lanzamientos en GitHub

En el repositorio LedgerHQ/app-ethereum de GitHub se indica que el lanzamiento 1.22.2 está fechado el 24 de agosto de 2026 con la nota «Security issues», y el lanzamiento 1.22.3 el 26 de agosto de 2026, e incluye una serie de correcciones adicionales relacionadas con el mecanismo clear-signing y otras rutas de procesamiento de transacciones.

La diferencia en las evaluaciones entre OneKey y Ledger Donjon se redujo a la versión en la que se corrigió el bug: 1.22.2 frente a 1.22.3. Ambas partes coinciden en que los usuarios deben actualizar la aplicación de Ethereum a la versión más reciente a través de Ledger Live.

Opinión de la IA

Desde el punto de vista del análisis automatizado de datos, la discusión sobre la versión 1.22.2 frente a 1.22.3 es menos importante que la clase de error encontrado en sí: la condición de carrera entre la visualización en pantalla y la firma real de la transacción. Esta lógica no solo es vulnerable en las aplicaciones de Ledger: un problema similar en la cadena de confianza se ha manifestado en otros monederos de hardware, donde un defecto a nivel del generador de números aleatorios en el monedero Coldcard llevó a claves predecibles y pérdidas de cientos de millones de dólares. La situación demuestra un principio general: la seguridad de un monedero de hardware no depende de un solo eslabón —firmware, SDK o aplicación—, sino de toda la cadena de componentes simultáneamente, y una ruptura en cualquiera de ellos invalida las demás protecciones.

Un matiz técnico que quedó fuera de la discusión: los ciclos de actualización separados para aplicaciones y SDK, como en el caso de la aplicación de Ethereum y Ledger Secure SDK, crean una ventana en la que parte del ecosistema ya está protegido y otra parte aún no. ¿Qué pasará si tales ventanas empiezan a encontrarse más rápido de lo que los fabricantes pueden cerrarlas?

Trending Cryptos

Related Questions

Q¿Cuál es la vulnerabilidad principal encontrada en la aplicación Ethereum de Ledger según el artículo?

ALa vulnerabilidad principal es una condición de carrera entre la lógica de visualización de la transacción en pantalla y el búfer de la transacción misma, que permitía a un atacante sobrescribir una transacción pendiente de firma mientras el usuario revisaba la operación legítima en la pantalla. Esto resultaba en que el usuario veía y confirmaba la transacción A, pero el dispositivo firmaba una transacción B diferente.

Q¿Qué recomendaron tanto OneKey como Ledger Donjon a los usuarios para mitigar esta vulnerabilidad?

AAmbas partes recomendaron a los usuarios que actualizaran la aplicación Ethereum a la última versión disponible (mínimo a la versión 1.22.2 o 1.22.3, según la fuente) a través de Ledger Live, y que verificaran la versión de la aplicación instalada en el propio dispositivo hardware.

Q¿En qué sección del artículo se menciona un caso similar de vulnerabilidad en otro fabricante de carteras hardware, y cuál era el problema?

AEn la sección 'Мнение ИИ' (Opinión de la IA). Se menciona que un defecto en el generador de números aleatorios (RNG) en la cartera Coldcard llevó a claves predecibles y pérdidas por cientos de millones de dólares, ilustrando un principio de seguridad similar.

QSegún el boletín de seguridad oficial de Ledger (LSB 023), ¿cuál fue la causa raíz de la vulnerabilidad y en qué componente se encontraba?

ALa causa raíz fue que, mientras el usuario revisaba una operación en pantalla, el dispositivo host podía enviar un nuevo comando APDU sobre otro aún no procesado, lo que permitía cambiar los parámetros de la firma después de mostrarse al usuario pero antes de la firma real. El defecto se encontraba en el manejo de entrada/salida del Ledger Secure SDK, no en el sistema operativo o el firmware del dispositivo.

Q¿Qué discrepancia existió entre las afirmaciones de OneKey y Ledger Donjon sobre la versión en la que se solucionó la vulnerabilidad?

AOneKey afirmó que la vulnerabilidad fue cerrada en la versión 1.22.3 de la aplicación Ethereum, mientras que Ledger Donjon declaró que ya había sido solucionada en la versión 1.22.2, lanzada el 13 de agosto de 2026, antes de la publicación de OneKey. Ambas partes coincidieron en la necesidad de que los usuarios se actualizaran a la última versión.

Related Reads

Access to Active Sessions Instead of Databases: How the Shadow Market in Russia Has Changed

The Russian cybercriminal underground is shifting from selling massive, stolen corporate databases to trading active, short-term access to user accounts, according to a 2026 report. The value of information intercepted directly from infected devices by malware has risen nearly 13% in a year. Attackers now sell packets containing active session tokens (bypassing passwords and two-factor authentication), live email credentials, VPN and cloud storage logins, and corporate network access. A subscription for a steady stream of fresh data costs $250-$300 per month, far exceeding the value of outdated archives. While Russian regulators have successfully penalized companies for data leaks from centralized storage—with no repeat violations recorded after imposing turnover fines—this framework fails against the new threat model. Malware now steals data *after* it leaves the corporate perimeter and is on a user's personal device, a legal grey area. In 2026, 60% of studied web attacks aimed to steal keys for infiltrating corporate infrastructure. The situation mirrors global trends, akin to the Genesis Market shutdown in 2023, and highlights a structural risk: the demand for "fresh" data incentivizes botnet operators to maintain long-term control of infected devices for recurring revenue. This creates a persistent vulnerability layer between personal devices and corporate networks, currently outside the reach of existing regulatory protections.

cryptonews.ru2h ago

Access to Active Sessions Instead of Databases: How the Shadow Market in Russia Has Changed

cryptonews.ru2h ago

SlowMist Flags Fake Qwen 3.8 27B GitHub Repository Concealing StealC Information

SlowMist has identified a fake GitHub repository impersonating Alibaba's Qwen 3.8 27B AI model, which contains an information-stealing virus. The repository, created in August 2026, offered a download file of only 487 KB, far smaller than a legitimate 27-billion-parameter model (over 16 GB). The malicious ZIP file contained a Lua-based script disguised as a certificate, which deploys the StealC malware. Once executed, StealC harvests system data, takes screenshots, and steals browser credentials, cryptocurrency wallet information, and more, sending it to attacker-controlled servers. The malware also includes a backup system that can read new server addresses from the Polygon blockchain if the primary server is taken down. This incident is part of a broader campaign called FakeGit, active since March 2025, which has created thousands of malicious repositories. Approximately 800 of these specifically target AI tools using a method called AgentBaiting, sometimes tricking AI assistants into recommending them. Separate reports detail hundreds of other fake GitHub repositories spreading malware like BoryptGrab and campaigns like Megalodon that generate thousands of clones rapidly. Attackers copy legitimate projects, create convincing documentation, and even list them on public AI registries to appear trustworthy. The fake repositories exploit the high demand for open-source AI capabilities, putting users who run models locally at significant risk of data theft.

cryptonews.ru2h ago

SlowMist Flags Fake Qwen 3.8 27B GitHub Repository Concealing StealC Information

cryptonews.ru2h ago

Trading

Spot

Hot Articles

Discussions

Welcome to the HTX Community. Here, you can stay informed about the latest platform developments and gain access to professional market insights. Users' opinions on the price of ETH (ETH) are presented below.

活动图片