#XRP账本修复可增发XRP的漏洞
$XRP This vulnerability was serious enough that the fix bypassed the regular voting process.
On October 9, 2026, XRPL disclosed a vulnerability dating back to 2015 that could create spendable XRP out of thin air. The team said it had found no evidence that the bug had been exploited on the public network.
The mechanism was quite absurd. When the payment system added up order amounts, the numbers got so large that the calculation wrapped around to a small value. Sellers received the full amount, while buyers were charged only a fraction, and the difference became new XRP. Even the program responsible for checking whether new coins had been issued used the same calculation method and made the same mistake. The development team has reproduced the issue in a single-machine test.
If someone had exploited it first and then transferred the newly created coins to an exchange, other holders could have faced extra sell pressure and dilution of their holdings. Keeping coins in a cold wallet would not protect against this price risk.
On September 25, fix version 3.4.1 was released. Developers initially withheld the source code and urged node operators to install it as soon as possible. Justin Bons, founder of Cyber Capital, later strongly criticized the move on X, questioning XRPL’s commitment to decentralization.
I can understand the urgency of this response: publishing the fix code would expose the vulnerability, while following the usual voting process would mean waiting for activation—effectively leaving attackers a window of opportunity.
The trade-off was that node operators had to trust the publisher first, without being able to fully review the source code. During the upgrade, old and new versions could also disagree when handling an attack transaction, potentially causing a split or even taking the network offline. The disclosure report acknowledged this risk, and the source code is now public.
The risk of unauthorized issuance, already reproduced, was serious enough. But emergency measures like this need to be explained each time and reviewed afterward. Node operators’ willingness to cooperate once should not be taken to mean they will automatically accept the same approach every time.
#xrp #Ripple #加密货币
$XRP This vulnerability was serious enough that the fix bypassed the regular voting process.
On October 9, 2026, XRPL disclosed a vulnerability dating back to 2015 that could create spendable XRP out of thin air. The team said it had found no evidence that the bug had been exploited on the public network.
The mechanism was quite absurd. When the payment system added up order amounts, the numbers got so large that the calculation wrapped around to a small value. Sellers received the full amount, while buyers were charged only a fraction, and the difference became new XRP. Even the program responsible for checking whether new coins had been issued used the same calculation method and made the same mistake. The development team has reproduced the issue in a single-machine test.
If someone had exploited it first and then transferred the newly created coins to an exchange, other holders could have faced extra sell pressure and dilution of their holdings. Keeping coins in a cold wallet would not protect against this price risk.
On September 25, fix version 3.4.1 was released. Developers initially withheld the source code and urged node operators to install it as soon as possible. Justin Bons, founder of Cyber Capital, later strongly criticized the move on X, questioning XRPL’s commitment to decentralization.
I can understand the urgency of this response: publishing the fix code would expose the vulnerability, while following the usual voting process would mean waiting for activation—effectively leaving attackers a window of opportunity.
The trade-off was that node operators had to trust the publisher first, without being able to fully review the source code. During the upgrade, old and new versions could also disagree when handling an attack transaction, potentially causing a split or even taking the network offline. The disclosure report acknowledged this risk, and the source code is now public.
The risk of unauthorized issuance, already reproduced, was serious enough. But emergency measures like this need to be explained each time and reviewed afterward. Node operators’ willingness to cooperate once should not be taken to mean they will automatically accept the same approach every time.
#xrp #Ripple #加密货币