Ripple Labs lanzó xrpld 3.4.1 el 25 de septiembre para corregir dos vulnerabilidades en el software de servidor de XRP Ledger. Las fallas podrían haber permitido crear XRP sin el respaldo adecuado o haber provocado que distintas versiones del servidor discreparan sobre transacciones por lotes, lo que potencialmente habría detenido la validación de nuevos ledgers.
El equipo de XRPL afirmó que no encontró evidencia de que el desbordamiento de enteros hubiera sido explotado en redes públicas, mientras que la falla de transacciones por lotes no podía afectar a la red principal antes de que se activara la actualización de protocolo correspondiente.
El equipo de la blockchain XRP Ledger publicó un informe sobre las dos vulnerabilidades, ambas corregidas en xrpld 3.4.1. El equipo también reforzó las comprobaciones de saldo y planea verificar nuevamente cada vulnerabilidad corregida en nuevos candidatos de lanzamiento antes de cerrar los informes relacionados.
El desbordamiento podría haber creado XRP sin respaldo
La primera vulnerabilidad fue descubierta el 22 de septiembre de 2026 mediante el programa de recompensas por errores de XRPL. Un desbordamiento de enteros en el motor de pagos podría haber permitido a un atacante crear XRP sin el respaldo adecuado mediante ofertas especialmente diseñadas en el libro de órdenes y un único pago.
Al procesar cientos de ofertas, el software podía sumar incorrectamente los importes de XRP. En lugar de devolver un error, un total excesivamente grande podía desbordarse y convertirse en un número pequeño. Los propietarios de las ofertas seguirían recibiendo los importes completos, mientras que el comprador pagaría una cantidad mucho menor.
Una comprobación estándar destinada a impedir que una transacción creara nuevo XRP también podía fallar debido a un desbordamiento similar. El equipo de XRPL estimó que la vulnerabilidad podría haber existido desde 2015, cuando se introdujo el actual motor de pagos.
La versión 3.4.1 añadió comprobaciones de desbordamiento al calcular los totales y rechaza operaciones no válidas. El equipo afirmó que no había evidencia de que la vulnerabilidad hubiera sido explotada en redes públicas.
La falla de transacciones por lotes amenazaba la consistencia de la red
La segunda vulnerabilidad surgió durante una revisión adicional de los resultados del Sherlock Attackathon. Denis Angell, de la XRPL Foundation, confirmó el 18 de septiembre que una corrección anterior era incompleta. Mayukha Vadari, de RippleX, determinó posteriormente que la falla podía hacer que diferentes versiones del software de servidor llegaran a conclusiones contradictorias.
El problema involucraba el mecanismo Batch, que puede agrupar hasta ocho transacciones en un solo lote. El servidor no comprobaba si cada transacción interna estaba incluida en el campo obligatorio RawTransaction. Por ello, distintas versiones de xrpld podían interpretar de forma diferente la validez de la misma operación, lo que potencialmente podría detener la validación de nuevos ledgers en determinadas condiciones.
El equipo corrigió la falla mediante la actualización fixBatchV1_2, que se activó en la red principal el 9 de octubre. Antes de esa activación, el problema no podía explotarse para afectar a la red principal porque la función BatchV1_1 correspondiente seguía inactiva.
Otros trabajos de seguridad de XRPL
Ripple Labs también trabajó durante 2026 para reforzar la seguridad y ampliar las capacidades de XRPL. En marzo, investigadores de RippleX presentaron un enfoque para transferencias confidenciales de tokens multipropósito diseñado para proteger los datos de los usuarios.
En abril, la empresa anunció un plan multifase para preparar XRPL frente a las amenazas de la computación cuántica, incluida una transición a la criptografía poscuántica para 2028. En octubre, CSD BR de Brasil inició la primera etapa de una asociación con Ripple Labs para tokenizar participaciones de fondos de inversión de BTG Pactual en XRPL.
Fuente: HODL Press
