La empresa de investigación en seguridad Common Prefix informó previamente al equipo de Ripple sobre dos vulnerabilidades graves de seguridad en XRP Ledger (XRPL), ambas relacionadas con la lógica de consenso en el procesamiento de transacciones por parte de los nodos validadores. Si una lista de nodos únicos (UNL) es comprometida, un atacante puede enviar mensajes maliciosos que provocan la caída en cadena de los nodos validadores. Las correcciones correspondientes se han integrado en la versión rippled 3.0.0.
Riesgo principal de las vulnerabilidades: un nodo validado comprometido puede afectar toda la red
El mecanismo de consenso de XRPL requiere que los nodos validadores lleguen a un acuerdo sobre un conjunto de transacciones, proponiendo transacciones no procesadas conocidas y compartiendo información para establecer un consenso final. La raíz de ambas vulnerabilidades radica en un fallo en la lógica del código rippled para manejar las “transacciones en disputa” (transacciones que difieren entre los conjuntos de transacciones de diferentes nodos validadores).
El ataque requiere que uno de los aproximadamente 35 nodos validadores en la UNL sea comprometido. Aunque los nodos validadores en la UNL suelen estar ocultos tras nodos proxy y solo se comunican con ellos, dificultando el ataque, Nikolaos Kamarinakis, investigador de Common Prefix, señala que no es imposible. Una vez comprometido, el atacante puede desplegar una versión modificada de rippled para enviar continuamente mensajes maliciosos a otros nodos validadores, hasta que el nodo comprometido sea removido de la UNL.
Mecanismos técnicos y soluciones de reparación para las dos vulnerabilidades
Vulnerabilidad 1 — Comparación de transacciones (Comparing Transactions): Un nodo validado comprometido afirma que una transacción existe en un SHAMap cuando en realidad no está presente en el nodo, provocando que otros nodos que intentan buscar la transacción por ID con un identificador inválido se bloqueen.
Reparación 1: Se añadió un paso de verificación para confirmar si la transacción realmente existe en el nodo propuesto, bloqueando así la ruta que causa el bloqueo por ID inválido.
Vulnerabilidad 2 — Reenvío de transacciones (Relaying Transactions): El nodo validado comprometido envía un conjunto de transacciones maliciosas con hashes arbitrarios. Otros nodos los reconocen como transacciones en disputa y tratan de reenviarlas, lo que provoca un bloqueo durante la comprobación de “transacciones falsificadas” debido a datos inválidos.
Reparación 2: Se implementó un mecanismo try-catch para capturar excepciones provocadas por datos maliciosos, evitando que el bloqueo se propague y cause fallos en cadena.
El equipo de Ripple validó estas vulnerabilidades mediante programas de verificación independientes en redes de prueba aisladas, confirmando que tras aplicar las correcciones, los nodos ya no se bloquean al recibir mensajes maliciosos.
Confirmación de las reparaciones y hoja de ruta para fortalecer la seguridad de XRPL
Las correcciones se han integrado en la versión rippled 3.0.0. Ripple ha confirmado que, en entornos de prueba, los nodos con las correcciones aplicadas permanecen estables frente a los mismos vectores de ataque.
Ripple también ha anunciado una hoja de ruta para fortalecer la seguridad de XRPL, que incluye ampliar los auditorías de seguridad para detectar problemas antes del lanzamiento, introducir revisiones de código asistidas por IA para identificar vulnerabilidades potenciales, organizar hackatones de seguridad y aumentar las recompensas por vulnerabilidades para incentivar a investigadores externos a reportar problemas proactivamente.
En el informe, Ripple agradece oficialmente a Common Prefix por su divulgación responsable de las vulnerabilidades y por brindar soporte técnico durante el proceso de reparación.
Preguntas frecuentes
¿Qué tan difícil es realmente atacar estas dos vulnerabilidades en XRPL?
El ataque requiere comprometer uno de los aproximadamente 35 nodos validadores en la UNL. Aunque estos nodos suelen estar ocultos tras nodos proxy y solo se comunican con ellos, lo que limita la superficie de ataque, los investigadores señalan que no es imposible. Por ello, es crucial realizar las reparaciones antes de que las vulnerabilidades sean explotadas públicamente.
¿Qué acciones deben tomar los operadores de nodos XRPL?
Todos los operadores que ejecuten rippled 2.6.2 o versiones anteriores deben actualizar lo antes posible a rippled 3.0.0 para obtener protección completa contra ambas vulnerabilidades. Las versiones anteriores presentan riesgo de caída en cadena de los nodos si un nodo validado en la UNL es comprometido.
¿Qué implicaciones tiene este incidente para la seguridad a largo plazo de XRPL?
El incidente refleja un proceso de divulgación responsable: Common Prefix informó en privado en junio de 2025, y Ripple publicó la versión corregida rippled 3.0.0 en marzo de 2026. Ripple también anunció una hoja de ruta que incluye auditorías de seguridad con IA y mayores recompensas por vulnerabilidades, demostrando su compromiso continuo con la seguridad proactiva.
Aviso legal: La información de esta página puede proceder de terceros y no representa los puntos de vista ni las opiniones de Gate. El contenido que aparece en esta página es solo para fines informativos y no constituye ningún tipo de asesoramiento financiero, de inversión o legal. Gate no garantiza la exactitud ni la integridad de la información y no se hace responsable de ninguna pérdida derivada del uso de esta información. Las inversiones en activos virtuales conllevan riesgos elevados y están sujetas a una volatilidad significativa de los precios. Podrías perder todo el capital invertido. Asegúrate de entender completamente los riesgos asociados y toma decisiones prudentes de acuerdo con tu situación financiera y tu tolerancia al riesgo. Para obtener más información, consulta el
Aviso legal.
