The XRP Ledger team publicly disclosed on October 9 that an integer overflow vulnerability in the payment engine, traceable to around 2015, could theoretically be exploited to “mint” spendable $XRP out of thin air, exceeding the ledger’s established total supply cap of 100 billion. The vulnerability was reported on September 22 by Cayden Liao and Veria AI through the bug bounty program. RippleX reproduced it on an independent node and confirmed that the minted XRP could be transferred onward.
The attack required carefully constructing hundreds of offers to exchange tiny amounts of tokens for huge amounts of XRP, then using a single payment to take all the offers at once. The 64-bit integer wrapped around during summation, so the sellers’ accounts received the full amounts while the buyer was debited only a tiny amount; the difference became newly minted XRP. The ledger’s existing “no new XRP” invariant also wrapped around because it used the same type of addition, and therefore failed to block the attack. The team said there was no evidence of exploitation on the public network. A fix was urgently released with xrpld 3.4.1 on September 25 and took effect immediately after nodes upgraded, without going through the usual amendment waiting period.
The disclosure that same day also covered a validation issue in the Batch transaction wrapper fields. The corresponding amendment, fixBatchV1_2, activated on mainnet on October 9. Nodes that have not upgraded to 3.4.1 will be unable to sync with the network because they will be blocked by the amendment.
#XRP #安全 #行情 does not constitute investment advice
The attack required carefully constructing hundreds of offers to exchange tiny amounts of tokens for huge amounts of XRP, then using a single payment to take all the offers at once. The 64-bit integer wrapped around during summation, so the sellers’ accounts received the full amounts while the buyer was debited only a tiny amount; the difference became newly minted XRP. The ledger’s existing “no new XRP” invariant also wrapped around because it used the same type of addition, and therefore failed to block the attack. The team said there was no evidence of exploitation on the public network. A fix was urgently released with xrpld 3.4.1 on September 25 and took effect immediately after nodes upgraded, without going through the usual amendment waiting period.
The disclosure that same day also covered a validation issue in the Batch transaction wrapper fields. The corresponding amendment, fixBatchV1_2, activated on mainnet on October 9. Nodes that have not upgraded to 3.4.1 will be unable to sync with the network because they will be blocked by the amendment.
#XRP #安全 #行情 does not constitute investment advice