Una vulnerabilidad que existió en el XRP Ledger durante aproximadamente una década podría haber permitido a atacantes crear XRP gastable sin pagarlo, poniendo en riesgo la oferta fija de 100 mil millones de tokens de la criptomoneda. Ese límite es fundamental para el activo: los 100 mil millones de XRP existían desde el lanzamiento del ledger, y las reglas del protocolo están diseñadas para mover tokens entre titulares en lugar de acuñar nuevos. El equipo de desarrollo de Ripple lanzó una actualización de software de emergencia para eliminar el fallo, y los investigadores no encontraron evidencia de que hubiera sido explotado en redes públicas.

El error fue divulgado el 9 de octubre de 2026 y, según los reportes, se remonta a 2015. Los investigadores Cayden Liao y Veria AI descubrieron el problema a través del programa de recompensas por errores del XRP Ledger y lo reportaron el 22 de septiembre. Programas como este son un pilar de la seguridad en criptomonedas, ya que brindan a investigadores externos un canal privado para entregar fallos a los desarrolladores antes de que los detalles se hagan públicos. RippleX, la división de desarrollo de Ripple, reprodujo el ataque y confirmó que el XRP recién creado podría gastarse en transacciones posteriores.

Cómo funcionaba el error de oferta del XRP

En esencia, el fallo era un desbordamiento de enteros en el motor de pagos del XRP Ledger, un defecto clásico de software en el que un cálculo excede el tamaño fijo del número que lo almacena. El ledger procesa las transacciones a través de su exchange integrado, donde los usuarios colocan ofertas para intercambiar un activo por otro.

Un atacante podría haber aprovechado este mecanismo creando cientos de cuentas y colocando ofertas con montos inusualmente grandes de XRP. Un solo pago cuidadosamente construido podría entonces consumir todas esas ofertas a la vez.

Al totalizar el XRP adeudado entre las ofertas consumidas, el contador numérico del motor de pagos podía superarse más allá del valor máximo que podía representar, provocando que el total diera la vuelta a un número mucho más pequeño. Como resultado, las cuentas vendedoras recibirían sus pagos completos mientras el comprador pagaba solo el monto calculado incorrectamente, una discrepancia que efectivamente crearía nuevo XRP.

La salvaguarda existente del ledger, diseñada para detectar la creación no autorizada de XRP, dependía de cálculos vulnerables al mismo desbordamiento y, por lo tanto, podía no detectar los tokens recién creados. RippleX confirmó que ejecutar el ataque habría requerido solo unos pocos cientos de XRP para establecer las cuentas necesarias, además de las tarifas de transacción.

La corrección de emergencia evadió el proceso habitual de votación

Ripple lanzó la versión 3.4.1 del software de servidor del XRP Ledger el 25 de para abordar la vulnerabilidad. A diferencia de los cambios de protocolo convencionales, la corrección del motor de pagos entró en vigencia a medida que los operadores individuales actualizaban sus servidores. La divulgación oficial se publicó en el blog del XRP Ledger en unas dos semanas después del lanzamiento, un intervalo consistente con las normas de divulgación coordinada, en las que las correcciones se publican primero para que los operadores puedan proteger sus sistemas antes de que los detalles del ataque se hagan públicos.

La medida marcó una salida excepcional del proceso estándar de enmiendas del ledger, que generalmente requiere más del 80% de apoyo de los validadores de confianza sostenido durante dos semanas, un mecanismo diseñado para que ninguna parte pueda reescribir unilateralmente las reglas del ledger. RippleX explicó que seguir el proceso normal podría haber expuesto públicamente la vulnerabilidad mientras la red permanecía en riesgo durante el período de votación y activación. Según la divulgación oficial, más del 80% de los validadores de confianza predeterminados se habían actualizado el mismo día del lanzamiento.

El informe de vulnerabilidad, publicado el 9 de octubre, confirmó que los investigadores no encontraron evidencia de explotación en redes públicas. El incidente subraya el valor de la investigación de seguridad independiente y la coordinación rápida en la infraestructura de criptomonedas. También encaja en un patrón familiar de la industria: en 2018, los desarrolladores de Bitcoin Core corrigieron discretamente un error de consenso que podría haber permitido a un minero inflar la oferta de Bitcoin.

Si bien Ripple contuvo la amenaza inmediata, el episodio plantea preguntas más amplias sobre cómo las redes descentralizadas deberían equilibrar las medidas de seguridad de emergencia con una gobernanza transparente. RippleX enfatizó que la respuesta excepcional no cambia el enfoque establecido del ledger para futuras enmiendas al protocolo.