El XRP Ledger cierra una brecha de 2015 que permitía crear XRP de la nada: qué significa para tus criptos

El XRP Ledger reveló el 9 de octubre de 2026 un fallo que llevaba unos once años en el módulo de pagos de la cadena. Quien lo hubiera aprovechado habría podido crear XRP muy por encima de la oferta total en una sola transacción válida. La brecha está cerrada desde el 25 de septiembre con la versión xrpld 3.4.1, y RippleX escribe en su informe que no hay ningún indicio de que alguien la haya usado en una red pública.

No se trata, por tanto, de una alerta sobre un ataque en curso. Lo que queda por aclarar es tu propio planteamiento: dónde están tus monedas, quién opera el servidor que hay detrás y qué versión corre allí. Este texto sitúa el informe de divulgación, explica el error de cálculo en palabras llanas y lo traduce a los puntos que un inversor en Europa puede comprobar por sí mismo.

Desbordamiento en el módulo de pagos: qué revela el informe del 9 de octubre

El informe de divulgación de xrpld 3.4.1 describe dos hallazgos separados. El más grave afecta al módulo de pagos, es decir, la parte del software que encamina un pago a través de las ofertas del libro de órdenes de la cadena y calcula cuánto debe entregar quien paga y cuánto debe recibir el destinatario.

El hallazgo se comunicó el 22 de septiembre de 2026 a través del programa de recompensas por fallos del XRP Ledger, el canal por el que los investigadores de seguridad presentan vulnerabilidades a cambio de una recompensa. El informe cita a Cayden Liao y a Veria AI como autores del hallazgo. En un primer momento se clasificó como «Major». Después de reproducirlo, el equipo de RippleX elevó la clasificación a crítica.

El alcance está en el informe en una sola frase: un atacante habría podido crear XRP gastables muy por encima de la oferta total, y además en una única transacción confirmada. La apuesta necesaria habría sido pequeña. Hacían falta unos cientos de XRP como reserva, es decir, el depósito que la red exige para las ofertas abiertas y devuelve tras su cancelación, más las comisiones habituales. Estaban afectadas xrpld 3.4.0 y todas las versiones anteriores.

Cómo una suma sin límite podía generar más de 100.000 millones de XRP

El error de cálculo en una frase

El módulo de pagos sumaba los importes de varias ofertas con un entero de 64 bits, sin comprobar si el resultado cabía en ese ancho. Un desbordamiento es exactamente ese caso: cuando una suma supera el mayor valor representable, no salta a un error, sino que vuelve a empezar en cero. Una suma muy grande se convierte así en una cifra muy pequeña.

En la práctica eso significaba, según el informe, que los proveedores de las ofertas cobraban íntegramente mientras al comprador solo se le cargaba el minúsculo resto sobrante tras la vuelta a cero. La diferencia nacía de la nada. Podía desencadenarse con unos cientos de ofertas deliberadamente mal valoradas en el libro de órdenes, que un único pago barría después de golpe.

Lo que pasó por alto el control de la oferta

El XRP Ledger tiene contra este tipo de casos una protección propia, la invariante. Una invariante es una regla que debe cumplirse después de cada transacción; de lo contrario, la red descarta la operación. Una de ellas dice que no pueden crearse XRP.

Ese control se ejecutaba dentro del mismo fallo y empleaba el mismo modo de cálculo sin comprobar. Por eso no veía ningún aumento donde sí lo había. Dos capas de protección cedieron porque ambas se apoyaban en el mismo supuesto. El informe atribuye el fallo a la implementación del módulo de pagos en 2015.

xrpld 3.4.1: una corrección sin enmienda, efectiva al arrancar

Los cambios en las reglas del XRP Ledger pasan normalmente por una enmienda. Una enmienda es una modificación de reglas que los validadores votan y que solo rige en toda la red después de una fase de respaldo. Los validadores son los servidores que confirman el orden de las transacciones.

Con este hallazgo, RippleX eligió a propósito otra vía. Las comprobaciones de desbordamiento en la suma de ofertas y en la combinación de varias rutas de pago se aplican sin votación en cuanto un servidor arranca con la 3.4.1. La invariante cuenta desde entonces con un contador más ancho. El informe lo llama una excepción meditada, justificada por la gravedad del hallazgo.

Para los operadores se deriva de ahí una obligación clara. El informe indica que todos los operadores de servidores deben pasar a la 3.4.1 o posterior para seguir sincronizados con la red. Quien se quede en una versión anterior está, desde la activación del 9 de octubre, bloqueado por la enmienda: se queda en un estado de las reglas que el resto de la red ya ha dejado atrás.

Cronología del 22 de septiembre al 9 de octubre

El informe expone la secuencia, y los intervalos que contiene son el hallazgo de fondo. Entre el aviso y una corrección terminada pasó un día.

El 22 de septiembre de 2026 entró el desbordamiento y se reprodujo. El 23 de septiembre la corrección estaba en la rama de publicación de la 3.4.1. El 24 de septiembre el equipo concluyó que un escenario de simple perturbación por esa vía apenas se sostenía. El 25 de septiembre apareció xrpld 3.4.1 y, al mismo tiempo, se abrió una fase de respaldo de dos semanas para la segunda corrección. El 9 de octubre ambos cambios de reglas quedaron activos en la red principal, y ese mismo día apareció el informe.

Las dos semanas entre la entrega y la divulgación son intencionadas, no un descuido. Mientras una parte grande de los servidores siga con la versión antigua, una descripción precisa del fallo equivale a un manual de instrucciones. Se publicó el día en que el cambio de reglas ya estaba en la red.

Cinco de los ocho informes de divulgación del XRPL son de 2026: nuestro propio recuento

Si un hallazgo aislado es un accidente solo se ve en la serie. Por eso hemos contado todas las entradas del blog del XRPL y hemos separado los informes de divulgación. Entre 273 entradas hay ocho informes de ese tipo, y cinco de ellos llevan fecha de 2026.

Los cinco de este año se refieren a la enmienda Batch en febrero, al tratamiento de los importes de transacción en marzo, a una avalancha de mensajes de manifiesto comunicada el 30 de julio, a las comisiones y reservas patrocinadas según XLS-68 comunicadas el 7 de agosto, y al informe sobre la 3.4.1 del 9 de octubre. Los tres más antiguos se reparten entre noviembre de 2024, abril de 2025 y septiembre de 2025. cryptoticker.io elaboró este recuento por su cuenta el 10 de octubre de 2026.

La cifra se puede leer en dos direcciones, y solo mencionar ambas es honesto. Más informes pueden significar que se encuentra más, porque un programa de recompensas y un certamen como la ronda Sherlock Attackathon buscan precisamente eso. También cabe pensar que la cadena gana con cada nueva pieza más superficies donde algo puede atascarse. Para situar el desbordamiento cuenta sobre todo que proviene del núcleo antiguo y no de una de las funciones nuevas.

Enmienda Batch y Permission Delegation: qué quedó activo además el 9 de octubre

El segundo hallazgo del informe afecta a Batch, una función de la propuesta XLS-56 con la que una cuenta presenta hasta ocho transacciones como una unidad. La especificación exige que cada transacción interna vaya en un campo determinado. El servidor no lo comprobaba, de modo que también otros campos podían servir de envoltorio.

Pesaba más que el conjunto de envoltorios admisibles variase según la versión del software. Dos servidores habrían valorado así la misma operación de forma distinta, y eso es precisamente lo que amenaza el acuerdo en la red. Estaban afectadas la 3.3.0 y la 3.4.0 con la enmienda BatchV1_1 aún inactiva. El informe cita como origen el aviso F48 del Attackathon, clasificado al principio como bajo. Denis Angell, de la XRPL Foundation, constató el 18 de septiembre que la primera corrección estaba incompleta, y Mayukha Vadari, de RippleX, detectó el riesgo para el acuerdo. Según el informe no hubo daños: ninguna pérdida de saldos, ninguna clave expuesta, ningún fallo del acuerdo.

Desde el 9 de octubre la red rechaza toda transacción Batch con el envoltorio equivocado, asegurada mediante el cambio de reglas fixBatchV1_2, que quedó activo el mismo día que BatchV1_1. Nuestro artículo del 1 de octubre describía el marco de fechas en el que esta ronda de cambios de reglas podía aplicarse como muy pronto, y la pregunta entonces abierta era por qué partes de ella se retrasaban: el XRP Ledger y la fecha de Permission Delegation. El informe aporta la respuesta. Detrás del retraso estaba la retirada de votos, con la que se impidió una activación con la corrección incompleta.

63.130 de 99.990 millones de XRP: el límite de oferta como núcleo de la promesa

Los XRP se crearon una sola vez y desde entonces no se emiten. De una oferta total de 99.990 millones de unidades, 63.130 millones están en circulación y el resto permanece bloqueado o en manos de la empresa. La capitalización de mercado, es decir, la oferta en circulación al precio actual, se sitúa en unos 88.800 millones de dólares, a 10 de octubre de 2026. XRP ocupa así el quinto puesto entre las mayores criptomonedas.

Esa firmeza de la oferta es el punto donde el desbordamiento duele. Una brecha que crea unidades gastables por encima del límite no afecta a una función secundaria, sino a la promesa sobre la que descansa el precio. Un ataque ejecutado no solo habría cambiado la oferta sobre el papel: habría dañado el control con el que la red advierte los cambios de oferta.

Por eso la clasificación como crítica resulta comprensible, aunque no se perdiera ningún saldo. La medida para hallazgos así es el daño posible, no el daño ocurrido. Y aquí recaía sobre la cifra que sostiene todo el modelo.

Cómo comprobar dónde están tus XRP si llega el momento

La versión de software de un servidor no es algo que un inversor pueda cambiar desde fuera. Lo que sí se puede comprobar es la cadena de responsabilidad: quién custodia las monedas, quién opera la técnica que hay debajo y a quién habría que dirigirse en caso de emergencia.

Exchange, bróker o custodia propia

Si los XRP están en un exchange, es este el que opera la conexión con la cadena y responde de la versión. Allí el inversor tiene un derecho de retirada, no un acceso directo a las monedas. Qué plataformas de negociación trabajan en Europa con una autorización y qué comisiones implica figura en nuestro panorama de los mejores exchanges de criptomonedas.

Con custodia propia la clave queda en manos del titular y la conexión va por un proveedor o por un servidor propio. Quien use un software de cartera debería actualizarlo tras un aviso de este tipo, porque muchos programas emplean una conexión que viene incluida. Con un nodo propio la obligación del informe se aplica directamente: versión 3.4.1 o posterior; si no, el servidor sale del consenso.

Tres preguntas sostienen esta revisión. Primera: ¿está el saldo en un proveedor con sede y autorización en la UE o en una plataforma sin supervisión europea? Segunda: ¿ha anunciado el proveedor un mantenimiento o una actualización después del 25 de septiembre? Tercera: ¿cómo se tramitaría una retirada si la red estuviera parada durante horas?

La custodia bajo MiCA: un derecho frente a la posesión

Desde MiCA, el reglamento de la UE para los mercados de criptoactivos, los proveedores que custodian o intercambian criptoactivos por cuenta de clientes necesitan una autorización como proveedores de servicios de criptoactivos. Entre sus obligaciones está separar los saldos de clientes de los propios y responder por la pérdida de los valores custodiados.

Eso desplaza la pregunta sin resolverla. Un custodio autorizado es localizable y responde, pero se sitúa entre el titular y la cadena. La custodia propia invierte el planteamiento: ningún tercero puede bloquear el saldo, y nadie responde por una clave perdida. Qué forma es la adecuada depende del importe y de con qué frecuencia alguien opera.

Ante un fallo de protocolo como este, ambas ayudan solo en parte. Una brecha en el módulo de pagos actúa sobre la cadena, no sobre el dispositivo del titular. Lo que decide la custodia es la rapidez con la que alguien puede reaccionar si hay que detener o reconstruir una red.

Precio de XRP en 1,41 dólares: el mercado no se movió con la noticia

XRP cotiza a 10 de octubre de 2026 en 1,41 dólares, un 1,1 % más que el día anterior. El rango del día va de 1,37 a 1,41 dólares. En una semana cae un 5,6 %, y en treinta días sube un 0,8 %.

Los niveles para los próximos días se derivan de ese rango. Por abajo está el mínimo del día en 1,37 dólares; por arriba, el máximo del día limita en 1,41 dólares. Que la divulgación del 9 de octubre no haya dejado huella encaja con su contenido: lo comunicado fue una brecha cerrada sin indicio de explotación, no un incidente en curso.

Nuestra valoración: un fallo que duró once años no es un caso aislado

Desde el punto de vista de la redacción, la gestión de este hallazgo es la contrapartida del fallo en sí. Un día desde el aviso hasta la corrección, dos semanas hasta la divulgación, una corrección sin votación allí donde votar habría tardado demasiado: esa es la conducta que uno espera de una red de este tamaño, y está documentada en el informe.

La otra cara está en nuestro propio recuento. Cinco de ocho informes de divulgación en un solo año, y además un hallazgo del núcleo de 2015 que dos capas de protección dejaron pasar a la vez porque usaban el mismo modo de cálculo. Quien concluya de ahí que la cadena ya está auditada lee demasiado. El origen del hallazgo habla en contra de esa lectura: código que llevaba años funcionando sin llamar la atención, no una función recién construida. Para una valoración de XRP como inversión el episodio no cambia nada en las cifras; cambia algo en la pregunta de cuánta revisión necesitan todavía los cimientos.

Parche del XRPL: sin la versión 3.4.1 un nodo sale del consenso

1. Aclarar la responsabilidad. Mira dónde están tus XRP y quién opera la conexión con la cadena. Con un proveedor cuenta su autorización y si los saldos de clientes se llevan por separado. Qué plataformas trabajan bajo supervisión europea lo muestra nuestro panorama de los exchanges de cripto regulados.
2. Seguir por tu cuenta el estado de la cadena. La activación de los cambios de reglas y la versión de un servidor son públicas. Quien lo sigue con regularidad nota un cambio antes del siguiente aviso. Las herramientas para ello están en nuestro panorama de plataformas de análisis.
3. Documentar saldo y plazos de tenencia. Después de un incidente de protocolo cuenta un registro limpio de tus entradas y salidas, también para la declaración. En Alemania el plazo de tenencia de un año decide si una ganancia tributa. Cómo llevar ese seguimiento está en los software fiscales y rastreadores de cartera.

El episodio se puede releer en la propia fuente: en el informe de divulgación de xrpld 3.4.1 y en el anuncio de la versión 3.4.1 del 25 de septiembre.

(10 de octubre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)