Ledger solucionó discretamente una falla grave en su aplicación de Ethereum casi dos semanas antes de que alguien fuera de la empresa supiera que existía, y la forma en que se hizo pública esa cronología se ha convertido en su propia pequeña controversia. La vulnerabilidad de Ethereum de Ledger implicaba una condición de carrera que podría haber permitido que una aplicación maliciosa sustituyera una transacción legítima por una dañina mientras el usuario aún la estaba aprobando en la pantalla de su dispositivo. Ledger corrigió el problema el 12 de agosto de 2026, pero casi no dijo nada públicamente hasta que un investigador de seguridad obligó a sacar la historia a la luz más de una semana después.
Summary
Puntos clave
- Ledger corrigió la falla en su aplicación de Ethereum el 12 de agosto de 2026, distribuyendo la solución en la versión 1.22.2 sin un boletín público de seguridad.
- El error era una condición de carrera que involucraba comandos APDU que podían permitir que una aplicación maliciosa sustituyera una transacción legítima durante el clear signing.
- El equipo interno de Ledger, Donjon, encontró la falla utilizando herramientas asistidas por IA antes de que cualquier investigador externo la reportara.
- La firma de seguridad TestMachine divulgó públicamente el error entre el 21 y el 23 de agosto de 2026, utilizando un agente de IA llamado Azimuth.
- No habían surgido informes confirmados de fondos robados vinculados a la falla hasta el 24 de agosto de 2026.
La corrección secreta de Ledger de la vulnerabilidad en la app de Ethereum
La corrección de Ledger llegó sin fanfarrias el 12 de agosto de 2026, enterrada en una actualización de software rutinaria en lugar de ser señalada como un parche de seguridad. El cambio se incluyó en la versión 1.22.2 de la aplicación de Ethereum y, durante aproximadamente diez días, la empresa no emitió ningún aviso, ninguna entrada de blog y ninguna declaración pública que explicara qué se había reparado realmente.
Detalles del parche y la versión
Los usuarios que ejecutaban la aplicación de Ethereum necesitaban actualizar a la versión 1.22.2 o posterior para recibir la corrección. Ledger ha enfatizado que actualizar solo el software de escritorio o móvil complementario no habría sido suficiente, ya que el código vulnerable residía en la aplicación que se ejecuta directamente en el propio dispositivo de hardware.
Naturaleza del error de condición de carrera
La falla se centraba en los comandos APDU, el lenguaje técnico que los dispositivos Ledger utilizan para comunicarse entre una computadora conectada y el chip seguro que realmente firma las transacciones. La promesa central de seguridad de Ledger se basa en lo que la empresa llama clear signing, donde la pantalla del dispositivo muestra detalles legibles de la transacción para que los usuarios sepan exactamente qué están aprobando antes de confirmarla.
La condición de carrera socavaba esa promesa. Durante los flujos de clear signing, un comando malicioso competidor podía colarse y reemplazar la transacción original por otra diferente antes de que el usuario terminara el proceso de aprobación. En la práctica, alguien podía creer que estaba confirmando una pequeña transferencia de tokens mientras en realidad estaba autorizando acceso ilimitado a tokens para la dirección de la cartera de un atacante.
Cronología del descubrimiento y la divulgación
La brecha entre el parche silencioso de Ledger y la divulgación pública es donde la historia se vuelve polémica, con ambas partes describiendo una secuencia de eventos diferente.
Detección interna por Donjon usando herramientas de IA
La unidad interna de seguridad de Ledger, conocida como Donjon, afirma que descubrió la vulnerabilidad por sí misma, antes de que cualquier investigador externo la señalara. El equipo se apoyó en herramientas de investigación asistidas por IA para identificar y corregir la falla, un enfoque que refleja un cambio más amplio hacia la búsqueda de vulnerabilidades asistida por máquinas dentro de los equipos de seguridad de monederos de hardware.
Divulgación pública por el investigador de seguridad TestMachine
Ese período de silencio terminó cuando TestMachine, una firma de seguridad de IA, publicó sus propios hallazgos entre el 21 y el 23 de agosto de 2026. TestMachine afirma que descubrió el error utilizando un agente autónomo de IA llamado Azimuth, que la firma construyó específicamente para buscar exploits en contratos inteligentes. En el propio benchmark EVMBench de la compañía, Azimuth supuestamente detecta el 86,3% de los errores conocidos con aproximadamente un 2,7% de falsos positivos.
En su divulgación, TestMachine escribió que la falla fue «encontrada por Azimuth durante un escaneo autónomo de la aplicación de Ethereum de Ledger», añadiendo que había sido «validada en Flex», «compartida y verificada con el equipo», mientras la firma «rechazaba cualquier recompensa». TestMachine también señaló código APDU y de interfaz de usuario compartido entre Nano X, Nano S Plus, Stax y Apex, sugiriendo que el problema subyacente podría extenderse más allá del dispositivo Flex que probó.
Respuesta y disputa de Ledger
El CTO de Ledger, Charles Guillemet, rechazó enérgicamente la forma en que se enmarcó la divulgación. Dijo que TestMachine solo contactó con el programa de recompensas de Ledger después de que la corrección ya se hubiera distribuido, y que la solución ya llevaba activa unas dos semanas cuando los investigadores hicieron pública la información. Guillemet acusó a TestMachine de fabricar miedo para llamar la atención en lugar de practicar una investigación de seguridad responsable, argumentando que la presentación pública implicaba que el error seguía activo cuando ya se había resuelto.
La versión de TestMachine difiere en la secuencia. La firma sostiene que descubrió y validó de forma independiente el error, compartió sus hallazgos con Ledger, rechazó la oferta de recompensa y luego decidió publicar. El repositorio público de la aplicación de Ethereum de Ledger muestra varios cambios relacionados con seguridad realizados a lo largo de agosto que cubren estados de firma y finalización de mensajes, aunque los registros disponibles no aíslan claramente un único cambio vinculado a esta falla específica.
Impacto en la seguridad y recomendaciones para usuarios
Para los usuarios habituales de Ledger, la cifra más importante de esta historia es sencilla: no habían aparecido informes confirmados de fondos robados vinculados a la vulnerabilidad hasta el 24 de agosto de 2026. Eso no significa que el riesgo fuera teórico. Un exploit funcional podría haber permitido a un atacante reescribir los términos de una transacción que el usuario creía estar aprobando, convirtiendo una transferencia rutinaria de tokens en acceso ilimitado para una dirección maliciosa.
No había disponible públicamente, en el momento de la publicación, una prueba de concepto completa que demostrara robo real de fondos en todos los dispositivos mencionados, y Ledger no ha publicado un aviso formal de seguridad ni ha anunciado ningún proceso de compensación vinculado al incidente. Ese silencio es en sí mismo parte de la historia. Un parche distribuido silenciosamente y sin un boletín público deja a los usuarios tener que reconstruir el riesgo a partir de divulgaciones de terceros en lugar de recibirlo directamente del fabricante.
Ledger ha aconsejado a los usuarios actualizar tanto el firmware de su dispositivo como la aplicación de Ethereum a la versión 1.22.2 o posterior, señalando que actualizar solo el software de escritorio o móvil complementario no reemplazará una aplicación desactualizada en el propio monedero de hardware. Dado que TestMachine señaló código compartido entre las líneas Flex, Nano X, Nano S Plus, Stax y Apex, mantener cada dispositivo conectado actualizado sigue siendo la salvaguarda más directa disponible para los usuarios en este momento.
Este episodio también subraya por qué el método de descubrimiento importa tanto como la propia corrección. El uso de herramientas asistidas por IA por parte de Donjon para detectar la falla antes que cualquier externo muestra cómo el escaneo automatizado se está convirtiendo en parte de la capa de defensa interna en los fabricantes de monederos de hardware. Al mismo tiempo, el uso por parte de TestMachine de su propio agente de IA para encontrar y divulgar de forma independiente la misma clase de error en cuestión de semanas plantea una pregunta incisiva para la industria: si las herramientas de IA ahora pueden sacar a la luz estas fallas tanto desde dentro como desde fuera de una empresa casi simultáneamente, las prácticas de tiempos de divulgación y transparencia pueden necesitar ponerse al día tan rápido como lo ha hecho la propia tecnología.
Preguntas frecuentes
¿Cuál fue la falla de seguridad en la aplicación de Ethereum de Ledger?
Fue una condición de carrera que involucraba comandos APDU que podía permitir que una aplicación maliciosa sustituyera transacciones legítimas por otras dañinas durante la firma.
¿Cómo y cuándo fue descubierta la vulnerabilidad por Ledger?
El equipo interno de seguridad de Ledger, Donjon, encontró la falla utilizando herramientas asistidas por IA antes de que cualquier investigador externo la reportara.
¿Cuándo se divulgó públicamente la vulnerabilidad?
El investigador de seguridad TestMachine divulgó públicamente el error entre el 21 y el 23 de agosto de 2026.
¿Hay alguna evidencia de que se robaran fondos debido a esta vulnerabilidad?
No habían aparecido informes confirmados de fondos robados vinculados a esta vulnerabilidad hasta el 24 de agosto de 2026.
{«@context»:»https://schema.org»,»@type»:»FAQPage»,»mainEntity»:[{«@type»:»Question»,»name»:»¿Cuál fue la falla de seguridad en la aplicación de Ethereum de Ledger?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Fue una condición de carrera que involucraba comandos APDU que podía permitir que una aplicación maliciosa sustituyera transacciones legítimas por otras dañinas durante la firma.»}},{«@type»:»Question»,»name»:»¿Cómo y cuándo fue descubierta la vulnerabilidad por Ledger?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»El equipo interno de seguridad de Ledger, Donjon, encontró la falla utilizando herramientas asistidas por IA antes de que cualquier investigador externo la reportara.»}},{«@type»:»Question»,»name»:»¿Cuándo se divulgó públicamente la vulnerabilidad?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»El investigador de seguridad TestMachine divulgó públicamente el error entre el 21 y el 23 de agosto de 2026.»}},{«@type»:»Question»,»name»:»¿Hay alguna evidencia de que se robaran fondos debido a esta vulnerabilidad?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»No habían aparecido informes confirmados de fondos robados vinculados a esta vulnerabilidad hasta el 24 de agosto de 2026.»}}]}
Artículo producido con la asistencia de inteligencia artificial y revisado por el equipo editorial.
