RippleX has released xrpld version 3.4.1 to address a critical XRP Ledger vulnerability that could have enabled the unauthorized creation of roughly 18 trillion XRP in a single transaction. The flaw, which dated back to 2015, affected the payment engine and was serious enough that the fix was deployed outside the network’s normal amendment voting process after the issue became public.
According to the disclosed details, no evidence has been found that the bug was exploited on the public XRPL network. RippleX said more than 80% of UNL validators had updated within three days of the report.
How the bug worked
The vulnerability centered on an overflow in the payment engine’s amount aggregation logic. It could be triggered when multiple sell orders were executed at the same time as part of one transaction.
In the described attack path, an attacker could create many accounts and post sell orders for very small token amounts at unusually high prices. If those orders were all filled together, the ledger could miscalculate the final settlement amount, letting sellers receive XRP while buyers were charged only a negligible amount.
A related verification flaw made the situation more dangerous. That second issue could fail to properly block illegitimate XRP creation, meaning unauthorized issuance might not be stopped even after the incorrect settlement occurred.
Why the risk was considered severe
The reported worst-case scenario was the generation of about 18 trillion XRP in a single attack transaction. That figure is about 184 times larger than XRP’s original issuance of 100 billion tokens.
The issue was notable because it did not come from one obvious defect alone. Instead, two bugs described as low severity became highly dangerous when combined, creating a path to a much larger failure in the ledger’s safeguards.
Patch released in days
RippleX said it shipped the fix three days after the vulnerability was reported. The patched release, xrpld 3.4.1, was then adopted by a large majority of the network’s UNL validators in short order.
The company said the update was pushed without going through XRPL’s usual amendment voting process. That step was taken because the vulnerability had become public, increasing the urgency to reduce the network’s exposure.
What happens next
While the public network does not appear to have been exploited, the incident has prompted follow-up work on how vulnerabilities are identified before they reach production systems.
The response includes plans to expand the use of AI-based vulnerability detection and formal verification. Those measures point to a broader effort to catch combinations of seemingly minor bugs that could produce outsized security risks in critical ledger software.
Source: en.bloomingbit.io