#XRP账本修复可增发XRP的漏洞
$XRP Esta vulnerabilidad era tan grave que, para corregirla, se omitió la votación habitual.
El 9 de octubre de 2026, XRPL reveló que una vulnerabilidad que se remontaba a 2015 podía crear XRP de la nada y hacerlo gastable. Según el comunicado oficial, no se había detectado que alguien la hubiera explotado en la red pública.
El mecanismo era bastante absurdo. Al sumar el importe de las órdenes en el sistema de pagos, el número era tan grande que el cálculo desbordaba y volvía a un valor pequeño. El vendedor recibía el importe original, pero al comprador solo se le descontaba una cantidad mínima; la diferencia se convertía en XRP nuevo. Incluso el programa encargado de comprobar «si se había emitido XRP de más» usaba el mismo método de cálculo y también se equivocaba. El equipo de desarrollo ya había reproducido el problema en pruebas aisladas.
Si alguien se hubiera adelantado y hubiera transferido las monedas creadas a un exchange, los demás titulares podrían haberse enfrentado a una presión de venta adicional y a la dilución de la oferta. Tener las monedas en una billetera fría tampoco habría evitado ese riesgo para el precio.
El 25 de septiembre se publicó la versión corregida 3.4.1. En ese momento, los desarrolladores no publicaron el código fuente y pidieron a los nodos que la instalaran cuanto antes. Poco después, Justin Bons, fundador de Cyber Capital, criticó duramente esta decisión en X y cuestionó el compromiso del proyecto con la descentralización.
Puedo entender la urgencia de esta medida: publicar el código de la corrección habría dejado al descubierto la vulnerabilidad, y seguir el proceso habitual de votación habría obligado a esperar a la activación, dejando una ventana abierta a los atacantes.
El precio de esa decisión fue que los nodos tuvieron que confiar primero en quienes publicaron la versión, sin poder revisar por completo su código fuente de inmediato. Además, durante la actualización, las versiones nuevas y antiguas podían reaccionar de forma distinta ante una transacción maliciosa, lo que podría provocar desacuerdos e incluso detener la red. El informe de divulgación reconoció este riesgo, y el código fuente ya se ha publicado.
El riesgo de emisión adicional, que ya se había reproducido, era suficientemente grave. Pero estas medidas de emergencia deben explicarse cada vez y someterse a una revisión posterior. Que los nodos colaboren una vez no significa que debamos dar por sentado que tendrán que hacerlo siempre.
#xrp #Ripple #加密货币
$XRP Esta vulnerabilidad era tan grave que, para corregirla, se omitió la votación habitual.
El 9 de octubre de 2026, XRPL reveló que una vulnerabilidad que se remontaba a 2015 podía crear XRP de la nada y hacerlo gastable. Según el comunicado oficial, no se había detectado que alguien la hubiera explotado en la red pública.
El mecanismo era bastante absurdo. Al sumar el importe de las órdenes en el sistema de pagos, el número era tan grande que el cálculo desbordaba y volvía a un valor pequeño. El vendedor recibía el importe original, pero al comprador solo se le descontaba una cantidad mínima; la diferencia se convertía en XRP nuevo. Incluso el programa encargado de comprobar «si se había emitido XRP de más» usaba el mismo método de cálculo y también se equivocaba. El equipo de desarrollo ya había reproducido el problema en pruebas aisladas.
Si alguien se hubiera adelantado y hubiera transferido las monedas creadas a un exchange, los demás titulares podrían haberse enfrentado a una presión de venta adicional y a la dilución de la oferta. Tener las monedas en una billetera fría tampoco habría evitado ese riesgo para el precio.
El 25 de septiembre se publicó la versión corregida 3.4.1. En ese momento, los desarrolladores no publicaron el código fuente y pidieron a los nodos que la instalaran cuanto antes. Poco después, Justin Bons, fundador de Cyber Capital, criticó duramente esta decisión en X y cuestionó el compromiso del proyecto con la descentralización.
Puedo entender la urgencia de esta medida: publicar el código de la corrección habría dejado al descubierto la vulnerabilidad, y seguir el proceso habitual de votación habría obligado a esperar a la activación, dejando una ventana abierta a los atacantes.
El precio de esa decisión fue que los nodos tuvieron que confiar primero en quienes publicaron la versión, sin poder revisar por completo su código fuente de inmediato. Además, durante la actualización, las versiones nuevas y antiguas podían reaccionar de forma distinta ante una transacción maliciosa, lo que podría provocar desacuerdos e incluso detener la red. El informe de divulgación reconoció este riesgo, y el código fuente ya se ha publicado.
El riesgo de emisión adicional, que ya se había reproducido, era suficientemente grave. Pero estas medidas de emergencia deben explicarse cada vez y someterse a una revisión posterior. Que los nodos colaboren una vez no significa que debamos dar por sentado que tendrán que hacerlo siempre.
#xrp #Ripple #加密货币