XRPL (XRP Ledger) reveló dos vulnerabilidades de software el 9 de octubre de 2026, incluida una falla crítica que podría haber permitido a los atacantes crear XRP nuevo y gastable. La segunda vulnerabilidad afectaba a la función de transacciones por lotes de la red y podría haber interrumpido la validación de transacciones.
Según el informe oficial, el error del motor de pagos se corrigió en la versión 3.4.1 de xrpld, publicada el 25 de septiembre. XRPL informó que no hay pruebas de que la vulnerabilidad se haya explotado en ninguna red pública.
Un error de XRPL podría haber permitido crear XRP nuevo
La vulnerabilidad crítica afectaba la forma en que el motor de pagos calculaba el XRP necesario para completar operaciones a través de múltiples ofertas en un libro de órdenes. El cálculo podía desbordarse cuando el importe combinado superaba el valor máximo admitido por el sistema. Esto podría hacer que el motor de pagos cobrara a un comprador menos XRP que la cantidad acreditada a los propietarios de las ofertas, creando efectivamente nuevo XRP.
Explotar el error requería un libro de órdenes cuidadosamente preparado que contuviera cientos de ofertas con precios inusualmente altos, seguido de una transacción de pago específica. La vulnerabilidad no podía activarse mediante pagos o intercambios ordinarios.
Un investigador informó del problema a través del programa de recompensas por errores de XRPL el 22 de septiembre de 2026. El equipo de ingeniería de RippleX reprodujo el error y confirmó que cualquier XRP creado a través del fallo podía gastarse.
El problema se corrigió en la versión 3.4.1. Los desarrolladores añadieron comprobaciones para evitar el desbordamiento del cálculo y reforzaron las salvaguardas del sistema contra la creación no autorizada de XRP.
Segundo error afectó las transacciones por lotes de XRPL
La segunda vulnerabilidad afectaba la función de transacciones por lotes del XRP Ledger, que permite a los usuarios enviar varias transacciones juntas. El fallo permitía que una transacción dentro de un lote utilizara un campo con una estructura incorrecta. El servidor aún podía aceptar y procesar la transacción.
Esto creó el riesgo de que distintas versiones del software XRPL no estuvieran de acuerdo sobre si una transacción era válida. Tales desacuerdos podrían impedir que los validadores alcanzaran consenso e interrumpir la validación del libro mayor.
Según el informe, el problema no permitía a los atacantes eludir las firmas de las transacciones ni robar fondos directamente.
XRPL abordó el fallo mediante la enmienda fixBatchV1_2, que exige que las transacciones utilicen la estructura correcta. La función Batch no había sido activada en la red principal cuando se identificó la vulnerabilidad, por lo que el informe no identificó ninguna cuenta ni fondos de la red principal afectados por este error.
XRPL activa la corrección de seguridad de Batch
Los desarrolladores de XRPL y los operadores de validadores retiraron su apoyo a la enmienda original de Batch para restablecer su cronograma de activación mientras el equipo preparaba la corrección.
La enmienda corregida obtuvo apoyo y se activó en la red principal el 9 de octubre de 2026, el mismo día en que se publicó el informe de la vulnerabilidad.
El informe también describió un cambio en el proceso de pruebas de seguridad. XRPL planea volver a probar las vulnerabilidades informadas frente a candidatas de lanzamiento para confirmar que las correcciones funcionan antes de las versiones de software.
Lo que los tenedores de XRP necesitan saber
Ambas vulnerabilidades han sido corregidas, y XRPL informó que no hay evidencia de que el error crítico del motor de pagos haya sido explotado en una red pública. El informe no establece que ninguno de los fallos haya causado una pérdida real de fondos o un aumento en la oferta de XRP. La corrección del motor de pagos está incluida en la versión 3.4.1 de xrpld, mientras que el problema de Batch se abordó mediante la enmienda fixBatchV1_2.
El informe no instruye a los poseedores de XRP a mover sus fondos ni a cambiar sus claves privadas. La actualización del software es relevante para los operadores de servidores de XRPL, quienes necesitan versiones compatibles para seguir sincronizados con la red.