Publicado por
TLDR
- Las versiones maliciosas del XRPL SDK en NPM filtraron claves privadas. Actualizar a V4.2.5 inmediatamente.
- Los SDK falsos (v4.2.1 – v4.2.4, v2.14.2) se cargaron con una puerta trasera. Las claves privadas pueden verse comprometidas.
- El núcleo del libro mayor XRP es seguro. Solo el NPM JavaScript SDK se vio afectado por la violación.
- Los desarrolladores deben actualizar, rotar las claves y usar archivos de bloqueo para evitar futuros ataques de la cadena de suministro.
- Un hacker colocó un código dañino en el SDK XRP. Nueva versión segura lanzada, hasta ahora.
Se ha identificado una vulnerabilidad de seguridad significativa en el Kit de desarrollo de software JavaScript (SDK) del Ledger XRP, específicamente en varias versiones publicadas recientemente del paquete XRPL en el Node Package Manager (NPM). La violación, revelado Por Aikido Security On, ha provocado una respuesta inmediata de la Fundación Ledger XRP y los desarrolladores en todo el ecosistema XRP.
El código malicioso, descrito como una puerta trasera, fue incrustada en las versiones V4.2.1 a V4.2.4 y V2.14.2 del SDK. Estas versiones fueron cargadas a NPM por un usuario identificado como «mukulljangid» y no coincidieron con ningún lanzamiento legítimo del repositorio oficial de GitHub. La vulnerabilidad podría permitir a los atacantes extraer claves privadas de usuarios y desarrolladores utilizando las versiones SDK afectadas, lo que representa una seria amenaza para la seguridad de la billetera y los fondos de los usuarios.
Ataque de la cadena de suministro identificado en xrpl.js
El sistema de monitoreo automatizado de Aikido Security detectó el problema poco después de que se publicaron los paquetes comprometidos. La firma señaló que estas versiones SDK se distribuyeron a través de NPM y eran inconsistentes con el historial de liberación oficial del Ledger XRP en GitHub, lo que plantea preocupaciones inmediatas sobre un compromiso de la cadena de suministro.
La vulnerabilidad se descubrió dentro de una función llamada CheckvalidityOfseed, que se integró encubiertamente en la lógica de instanciación de la billetera. Esta función activó una llamada remota a un dominio no verificado: 0x9c[.]XYZ – Dirigir la creación de la billetera, transmitiendo silenciosamente información clave privada. Según Aikido Security, las versiones comprometidas tempranas (V4.2.1 y V4.2.2) contenían el código malicioso en archivos JavaScript construidos. Las versiones posteriores (V4.2.3 y V4.2.4) incrustaron la puerta trasera más profunda en los archivos de origen de TypeScript.
Además de la puerta trasera, los paquetes comprometidos mostraron signos de manipulación deliberada, incluida la eliminación de herramientas de desarrollo y scripts del archivo paquete.json. Estas modificaciones son consistentes con los intentos de ofuscar cambios no autorizados y reducir la detección durante auditorías o desarrollo.
Respuesta del ecosistema y medidas de mitigación
El Libro mayor de XRP Foundation respondió rápidamente a la divulgación, confirmando la vulnerabilidad a través de las redes sociales el 22 de abril. La Fundación aclaró que la base de código Ledger Core XRP y su repositorio de GitHub no se vieron afectados. En cambio, el problema se aisló al XRPL.JS JavaScript SDK distribuido a través de NPM.
Hoy temprano, un investigador de seguridad de @Aikidoscurity Identificó una vulnerabilidad grave en el paquete XRPL NPM (v4.2.1-4.2.4 y v2.14.2).
Somos conscientes del problema y estamos trabajando activamente en una solución.
Seguirá una autopsia detallada.
– XRP Ledger Foundation (oficial) (@XRPLF) 22 de abril de 2025
Desde entonces, los ingenieros han publicado una nueva versión, V4.2.5, que reemplaza las versiones afectadas y elimina la puerta trasera. Se ha aconsejado a los desarrolladores y proyectos que se basan en las versiones V4.2.1 a V4.2.4 y V2.14.2 que se actualicen de inmediato. Como precaución, se alienta a los usuarios a transferir activos a nuevas billeteras generadas con un software sin compromisos.
Varios proyectos que utilizan el SDK de LEDGER XRP, incluida la billetera Xaman y XRPSCan, confirmaron que no se vieron afectados, no haber integrado las versiones afectadas. Mientras tanto, Gen3 Games CTO Mark Ibanez declaró que su equipo evitó por poco la exposición al mantener una versión bloqueada en su archivo PNPM-Lock.yaml.
Ibanez recomendó prácticas de seguridad estándar, como cometer archivos de bloqueo al control de versiones y evitar el símbolo de caret (^) en las dependencias de paquete. Estas medidas, aunque rutinarias, demostraron ser efectivas para proteger algunos proyectos del SDK comprometido.