The XRP Ledger (XRPL) deployed an emergency security patch on September 25 after developers uncovered a critical vulnerability that could theoretically have allowed attackers to create approximately 18.5 trillion spendable XRP. The potential amount was substantially greater than the network’s original supply cap of 100 billion XRP.
Developers verified the vulnerability on September 22 and merged the correction on September 23. The fix was included in xrpld version 3.4.1 and addressed an overflow flaw in the payment engine that could have weakened the ledger’s protections against unauthorized XRP creation.
Rather than wait for the standard protocol amendment process, developers released the correction directly. Under XRPL’s usual procedure, validators vote on proposed changes before they become active. In this case, the team opted for a faster response because following the regular timeline could have prolonged the period of exposure.
The decision also reflected concerns that publicly available patch details might help attackers identify how to exploit the underlying weakness before vulnerable servers had been upgraded.
However, an accelerated rollout can create temporary inconsistencies across the network. Servers running different software versions may process the same transaction differently while operators install the update. Veria reported that more than 80% of validators had upgraded by September 25, helping limit the period of potential exposure.
XRPL’s Emergency Response Departed From Standard Protocol
The XRPL amendment framework normally gives validators several weeks to consider and approve changes affecting transaction processing. This approach is intended to coordinate network-wide upgrades and ensure that new rules take effect consistently. The ledger’s pending amendments demonstrate how protocol changes typically progress through validator support.
For this vulnerability, developers concluded that waiting for the usual activation process could create additional security risks. The direct release allowed the correction to take effect on individual servers as operators upgraded, rather than waiting for the standard amendment sequence to conclude.
The XRPL Foundation’s vulnerability disclosure report outlines the payment-engine overflow and the decision to distribute the emergency fix outside the normal process. Although this approach accelerated remediation, it also introduced a temporary risk that different software versions could handle a malicious transaction inconsistently.
The investigation highlighted the potential dangers of legacy code. According to Veria, the vulnerable BookStep aggregation code dated to 2015, while the XRPNotCreated invariant had been in place since 2017. Both components remained part of the software for years before the issue was identified.
Veria’s proof of concept reportedly relied on specially priced offers to distribute the resulting XRP across several accounts, ensuring that each account remained below the ledger’s individual balance limit. The firm estimated the theoretical exposure at approximately $94 billion.
The estimated 18.5 trillion XRP figure represents a hypothetical exploit scenario, not evidence that those tokens were actually created. RippleX reported no evidence that the vulnerability had been exploited on a public network.
AI Tools Could Change How Blockchain Vulnerabilities Are Found
The incident has also renewed discussion about artificial intelligence in cybersecurity. AI-assisted tools can help researchers detect overlooked weaknesses in long-established software, potentially uncovering vulnerabilities that have remained hidden for years. The same capabilities, however, could make it easier for malicious actors to identify exploitable flaws.
The episode reinforces the need for continuous security reviews of blockchain infrastructure, particularly components responsible for enforcing fundamental safeguards such as token supply limits. Long-standing code can still contain weaknesses capable of creating serious risks if left undiscovered.
The reported response unfolded quickly: developers confirmed the bug on September 22, merged the fix the next day, and released xrpld version 3.4.1 on September 25. The patch addressed a potentially severe vulnerability, and no public-network exploitation was confirmed by RippleX.
Even so, the decision to bypass the standard amendment process raises an important question for decentralized networks: how can developers respond to urgent security threats without compromising transparent governance and validator coordination?
The XRPL incident was an emergency measure aimed at addressing a specific vulnerability, not confirmation that the network has replaced its established governance framework. Its broader lesson is the importance of balancing rapid security intervention with coordinated upgrades and decentralized oversight.
