XRP Ledger revela un fallo crítico que habría permitido crear XRP nuevos

XRP Ledger (XRPL) informó el 9 de octubre de 2026 de dos vulnerabilidades de software, entre ellas un fallo crítico que, en determinadas condiciones, podría haber permitido a un atacante generar XRP nuevos y gastables. El segundo problema afectaba a la función de transacciones Batch y podía provocar discrepancias en la validación de operaciones. Según el informe oficial, el fallo del motor de pagos quedó corregido en xrpld versión 3.4.1, publicada el 25 de septiembre. XRPL aseguró que no hay indicios de que la vulnerabilidad se haya explotado en ninguna red pública. El error crítico se encontraba en la forma en que el motor de pagos calculaba el XRP necesario para completar intercambios que atraviesan múltiples ofertas dentro de un libro de órdenes. Cuando el importe combinado superaba el valor máximo soportado por el sistema, el cálculo podía desbordarse. En ese escenario, el motor podía cargar al comprador menos XRP del que se abonaba a los propietarios de las ofertas, lo que en la práctica equivalía a crear XRP. La explotación requería un libro de órdenes preparado de manera específica, con cientos de ofertas a precios inusualmente altos, y después ejecutar una transacción de pago concreta. No podía activarse mediante pagos o operaciones habituales. Un investigador notificó el fallo a través del programa XRPL Bug Bounty el 22 de septiembre de 2026. El equipo de ingeniería de RippleX reprodujo el problema y confirmó que cualquier XRP generado por esta vía podía gastarse. La versión 3.4.1 incorporó controles para evitar el desbordamiento y reforzó las salvaguardas contra la creación no autorizada de XRP. La segunda vulnerabilidad se relacionaba con Batch, una función que permite agrupar y enviar varias transacciones en conjunto. El fallo hacía posible que una transacción dentro de un lote utilizara un campo con una estructura incorrecta y que, aun así, el servidor la aceptara y procesara. El riesgo era que distintas versiones del software de XRPL no coincidieran al determinar si la transacción era válida. Ese desacuerdo podía impedir que los validadores alcanzaran consenso y afectar a la validación del libro mayor. El informe subraya que este problema no permitía eludir firmas de transacciones ni robar fondos directamente. XRPL lo solucionó mediante la enmienda fixBatchV1_2, que obliga a utilizar la estructura correcta. Además, cuando se identificó la vulnerabilidad, la función Batch aún no estaba activada en la mainnet, por lo que el informe no señala cuentas o fondos de la red principal afectados. Para desplegar la corrección, desarrolladores y operadores de validadores retiraron el apoyo a la enmienda Batch original con el fin de reiniciar su calendario de activación mientras se preparaba el ajuste. La enmienda corregida logró el respaldo necesario y se activó en la mainnet el 9 de octubre de 2026, el mismo día en que se publicó el informe. El documento también detalla un cambio en el proceso de pruebas de seguridad: XRPL prevé volver a verificar las vulnerabilidades reportadas sobre versiones candidatas (release candidates) para confirmar que las correcciones funcionan antes de cada lanzamiento. Para los titulares de XRP, XRPL indica que ambas vulnerabilidades ya están resueltas y que no existe evidencia de explotación del fallo crítico del motor de pagos en redes públicas. El informe tampoco concluye que se produjeran pérdidas de fondos ni un aumento real del suministro de XRP. La corrección del motor de pagos está incluida en xrpld 3.4.1 y el problema de Batch se abordó con la enmienda fixBatchV1_2. No se recomienda a los titulares mover fondos ni cambiar claves privadas. La actualización de software concierne principalmente a los operadores de servidores XRPL, que deben usar versiones compatibles para mantenerse sincronizados con la red.