Ripple Divulga Vulnerabilidades de XRP Ledger 2025 Después de que se Implementaron Correcciones en rippled 3.0.0

Ripple publicó un informe de divulgación de vulnerabilidades el 23 de marzo de 2026, detallando dos errores en el XRP Ledger (XRPL) descubiertos en junio de 2025 que podrían haber impedido el consenso de la red si un validador de la lista de nodos únicos (UNL) hubiera sido comprometido.

Las vulnerabilidades, reportadas por la firma de seguridad blockchain Common Prefix, fueron corregidas en rippled versión 3.0.0, lanzada el 9 de diciembre de 2025, con las correcciones probadas y validadas en octubre de 2025. La divulgación sigue los protocolos de divulgación responsable y describe las causas técnicas raíz, escenarios de impacto y las medidas de remediación implementadas para proteger la disponibilidad de la red.

Resumen de Vulnerabilidades e Impacto

Descubrimiento y Reporte

Nikolaos Kamarinakis de Common Prefix reportó las vulnerabilidades mediante una presentación de divulgación responsable el 9 de junio de 2025. Los equipos de ingeniería de Ripple validaron el informe con una prueba de concepto independiente que reprodujo ambos errores en una red de prueba separada.

Versiones Afectadas

Las vulnerabilidades afectaron las versiones de rippled hasta la 2.6.2, el cliente de software que impulsa el XRP Ledger. Ambas correcciones se incorporaron en rippled 3.0.0.

Impacto Potencial

Las vulnerabilidades requerían que un validador de la UNL —uno de aproximadamente 35 nodos confiables que participan en el consenso— fuera comprometido. Aunque comprometer un validador de la UNL es difícil porque estos nodos generalmente se ocultan tras nodos proxy y solo se comunican con ellos, los investigadores señalaron que no era imposible.

Si se explotaba, un validador comprometido podría manipular los datos de las transacciones en los conjuntos de transacciones, causando que todos los demás validadores que recibieran el mensaje modificado se bloqueasen. Estos bloqueos podrían repetirse hasta que el validador comprometido fuera eliminado de la UNL, potencialmente deteniendo el consenso de la red.

Detalles Técnicos

Vulnerabilidad 1: Comparación de Transacciones

La primera vulnerabilidad surgió de cómo los validadores comparan los conjuntos de transacciones durante el consenso. Cuando un validador recibe un conjunto de transacciones de otro validador, lo compara con el suyo propio e identifica transacciones en disputa. Un validador comprometido podría afirmar que una transacción existía en un nodo dentro del SHAMap donde en realidad no estaba. Cualquier validador que reciba el conjunto de transacciones malicioso se bloquearía al intentar buscar el ID de la transacción usando el ID de nodo inválido.

Vulnerabilidad 2: Reenvío de Transacciones

La segunda vulnerabilidad aprovechó el mecanismo de retransmisión para transacciones en disputa. Un validador comprometido podría enviar un conjunto de transacciones en el que los datos de la transacción fueran un hash arbitrario. Cuando los validadores receptores identificaran esto como una transacción en disputa y trataran de retransmitirla, realizarían una comprobación para determinar si era una pseudo transacción. Los datos inválidos en el conjunto de transacciones causarían que el validador se bloqueara durante esta inspección.

Remediación y Correcciones

Implementación de la Corrección

Para abordar la primera vulnerabilidad, los desarrolladores añadieron una comprobación adicional para confirmar que una transacción puede encontrarse en el nodo donde la propuesta indicaba que estaría ubicada. Para la segunda vulnerabilidad, se añadió un manejador try-catch para gestionar las excepciones lanzadas al inspeccionar transacciones maliciosas.

Pruebas y Validación

Ripple desplegó una versión modificada de rippled en su plataforma de pruebas para simular un validador de la UNL comprometido. Sin las correcciones, ambos ataques provocaban que todos los nodos que recibían mensajes maliciosos se bloquearan. Tras aplicar ambas correcciones, los nodos que recibían mensajes manipulados ya no se bloqueaban.

Cronograma

• 9 de junio de 2025: Descubrimiento inicial y envío del informe
• 10 de julio de 2025: Despliegue del entorno de pruebas
• 6 de agosto de 2025: Primera reproducción de la vulnerabilidad
• 11 de agosto de 2025: Segunda reproducción de la vulnerabilidad
• 19 de agosto de 2025: Correcciones creadas en repositorio privado
• 10 de octubre de 2025: Common Prefix prueba las correcciones
• 16 de octubre de 2025: Common Prefix aprueba las correcciones
• 9 de diciembre de 2025: Correcciones lanzadas en rippled 3.0.0
• 23 de marzo de 2026: Publicación del informe de divulgación de vulnerabilidades

Mejoras en Seguridad

Ripple describió iniciativas continuas para fortalecer la postura de seguridad del XRPL, incluyendo auditorías de seguridad ampliadas para código no lanzado, revisiones de código asistidas por IA, hackatones y mayores incentivos en programas de recompensas por errores.

Preguntas Frecuentes

¿Qué vulnerabilidades se descubrieron en el XRP Ledger?

Se descubrieron dos vulnerabilidades en rippled versiones hasta la 2.6.2 que podrían haber impedido el consenso de la red si un validador de la UNL hubiera sido comprometido. La primera involucraba búsquedas inválidas de ID de transacción durante la resolución de disputas, y la segunda, datos de transacción malformados que causaban bloqueos durante las verificaciones de retransmisión.

¿Se explotaron estas vulnerabilidades?

No. Las vulnerabilidades fueron descubiertas mediante divulgación responsable por Common Prefix, y las correcciones se implementaron en rippled 3.0.0 el 9 de diciembre de 2025, antes de que ocurriera alguna explotación conocida.

¿Qué es un validador UNL y por qué es importante?

Un validador UNL (lista de nodos únicos) es un nodo confiable que participa en el consenso de XRP Ledger. Aproximadamente 35 validadores conforman la UNL predeterminada. Comprometer un validador UNL es difícil porque generalmente se comunican a través de nodos proxy, pero los investigadores señalaron que no era imposible. Las vulnerabilidades habrían requerido tal compromiso para ser explotadas.