Una falla de desbordamiento en XRP Ledger podría haber permitido que una sola transacción creara más XRP que todo el suministro existente. RippleX, el brazo de desarrollo de Ripple, y la XRPL Foundation divulgaron y corrigieron la falla, probablemente presente desde 2015, a finales de septiembre de 2026. No hay evidencia de que haya sido explotada.

Un tope de suministro que pudo haberse roto

XRP Ledger es la blockchain descentralizada detrás de XRP. Gestiona pagos y trading mediante un libro de órdenes integrado, y el motor de pagos es el componente que cruza los pagos con las órdenes colocadas allí. El suministro total al lanzamiento era de 100 mil millones de XRP. No hay minería ni inflación; solo las comisiones quemadas reducen ligeramente el suministro. Ese tope fijo se apoya en un invariante a nivel de ledger —la regla de que ninguna transacción puede crear XRP— y precisamente esa garantía es la que socavó la falla de desbordamiento.

La versión 3.4.1 del software de servidor xrpld se lanzó el 25 de septiembre, y el informe de divulgación se publicó 14 días después. Antes de eso, más del 80% de los validadores de la Default Unique Node List (UNL) ya se habían actualizado. La falla afectaba a xrpld 3.4.0 y a todas las versiones anteriores. Veria Labs, que reportó la falla, calcula que una única transacción de explotación habría creado alrededor de 18 billones de XRP.

Cómo se habría acuñado XRP de la nada

El motor de pagos sumaba los montos de todas las órdenes que un pago consumía en el libro de órdenes, usando una suma de enteros de 64 bits sin verificación de desbordamiento. Si la suma crecía lo suficiente, el valor se envolvía a un número pequeño. Cada propietario de orden habría recibido el pago completo, mientras que el ledger solo debitaba al comprador la suma envuelta. La diferencia habría surgido como XRP nuevo.

Dos salvaguardas deberían haberlo impedido. Sin embargo, el invariante que establece que ninguna transacción puede crear XRP usaba la misma aritmética con desbordamiento. Además, la verificación de saldo por cuenta solo se activa por encima del suministro total, y el XRP creado habría quedado distribuido en muchas cuentas.

Para el ataque, un actor habría configurado cientos de cuentas, cada una ofreciendo una fracción mínima de un token por una cantidad enorme de X. Un solo pago consumiría entonces todas las órdenes, y cada cuenta involucrada podría pertenecer al atacante. El costo era de unos pocos cientos de XRP en reservas recuperables más comisiones, por lo que el atacante no necesitaba un saldo inicial grande.

Aun así, nadie podría haber provocado el desbordamiento por accidente. Los pagos normales nunca alcanzan la suma requerida, porque ningún trader real cotizaría precios así. El informe también señala que no hay evidencia de explotación en ninguna red pública. Cayden Liao, de Veria Labs, dice que el exploit encadena dos fallas que por separado tendrían una severidad baja, y sospecha que por eso nadie encontró antes la vulnerabilidad.

Reportada a través del programa de bug bounty

Cayden Liao y Veria AI reportaron la vulnerabilidad el 22 de septiembre a través del programa de bug bounty de la red, calificándola inicialmente como "Major". RippleX reprodujo el ataque y elevó la calificación a "critical", y luego desarrolló la corrección en privado. Un día después, la corrección llegó a la rama de lanzamiento de la versión 3.4.1 y se incluyó en el release candidate 3.4.1-rc1. Desde entonces, el motor de pagos verifica si hay desbordamiento al sumar los montos de las órdenes; si la suma se desborda, esa parte del pago falla.

Solo Veria Labs ha proporcionado detalles sobre el descubrimiento. La empresa afirma que un agente de IA encontró la falla y construyó un exploit funcional. En cambio, el informe de divulgación nombra solo a Liao y Veria AI como reportantes. La cifra de alrededor de 18 billones de XRP proviene del cálculo de Liao y equivaldría a 184 veces el suministro total. Veria también dice haber recibido la recompensa máxima de 250.000 USD, aunque el informe no menciona un monto. Programas como este son un mecanismo estándar en las principales redes blockchain para recompensar la divulgación responsable.

Según el informe, la falla probablemente estaba en el código desde el desarrollo del motor de pagos en 2015, sin ser detectada durante cerca de una década. El caso se inscribe en la tendencia más amplia de la caza de vulnerabilidades asistida por IA, que expone fallas más rápido —una perspectiva que también comparten los desarrolladores de RippleX.

Una corrección sin enmienda

Los cambios de reglas en XRP Ledger normalmente pasan por las llamadas enmiendas, que requieren el respaldo de más del 80% de los validadores de confianza durante un período de dos semanas. Esta corrección, sin embargo, entró en vigor de inmediato a medida que cada servidor individual se actualizaba. El informe la califica como el primer cambio deliberado de este tipo en el procesamiento de transacciones desde que llegaron las enmiendas. El día del lanzamiento, más del 80% de los validadores del Default UNL ya ejecutaban la versión 3.4.1 o posterior.

RippleX justificó la medida por la ventana de tiempo: un lanzamiento regular de código abierto habría mostrado a los atacantes dónde estaba la falla, semanas antes de que la corrección surtiera efecto. Miembros de la XRPL Foundation, RippleX y validadores de XRPL acordaron de antemano que el riesgo justificaba un enfoque rápido. En su opinión, solo las fallas más severas justifican este paso, mientras que todos los demás cambios siguen pasando por enmiendas.

"La IA ha cambiado las cosas. No puedes colar un parche de una falla crítica en un proceso de lanzamiento público de rutina; se detectará y se hará ingeniería inversa de inmediato." — Mayukha Vadari, RippleX

Sin embargo, el equipoó el código fuente de la 3.4.1 en GitHub solo unas dos semanas después de los binarios. Justin Bons, fundador de Cyber Capital, criticó en X que XRP hubiera estado funcionando con código cerrado durante dos semanas. Un parche silencioso con divulgación diferida es una práctica común en seguridad de software, pero sigue siendo controvertida en una red descentralizada con ambiciones de gobernanza.

Una segunda falla en la función de batch

La versión 3.4.1 también cerró una segunda falla, en la función de batch (XLS-56), que afectaba a xrpld 3.3.0 y 3.4.0. Un batch contiene hasta ocho transacciones internas, y según la especificación cada una debe estar en un campo llamado RawTransaction. El servidor no lo verificaba. Como resultado, podría surgir una entrada de ledger permanentemente malformada que habría podido afectar a indexers, explorers y SDKs.

Una variante de consenso era más grave. Con versiones de software mixtas, una transacción manipulada podría haber detenido la validación al costo de una comisión de transacción, aunque el atacante no habría ganado nada on-chain. Mainnet no sufrió impacto, ya que BatchV1_1 no estaba activa allí.

El hallazgo surgió por primera vez en el Sherlock Attackathon, calificado inicialmente como "low". El 18 de septiembre, Denis Angell, de la XRPL Foundation, confirmó que una corrección anterior estaba incompleta. Cuatro días después, Mayukha Vadari identificó el riesgo de consenso. Ripple y el operador de validadores Vet retiraron entonces sus votos para BatchV1_1, una enmienda que originalmente debía activarse el 29 de septiembre. El lanzamiento inició la activación de dos semanas de fixBatchV1_2, y desde el 9 de octubre ambas enmiendas están activas en mainnet.

Proceso de revisión endurecido

Por ello, RippleX está cambiando su proceso de revisión. De ahora en adelante, cada hallazgo de seguridad marcado como corregido pasa por una nueva prueba contra el release candidate, y el equipo solo lo cierra cuando una prueba reproduce la falla original y el candidato la supera. Entre las salvaguardas adicionales mencionadas en el informe figuran los attackathons públicos y el red teaming asistido por IA.

Las versiones anteriores cuentan como "amendment-blocked" y dejan de mantenerse sincronizadas. Los operadores deben así actualizar sus servidores a xrpld 3.4.1 o posterior. Cómo maneje su próximo hallazgo crítico —ya sea por esta vía rápida reservada o mediante una enmienda regular— mostrará si el enfoque sigue siendo la excepción que el informe describe.

Fuente: informe de divulgación de vulnerabilidad de XRPL vía Crypto Valley Journal