XRP Ledger Reveals Critical Bug That Could Have Allowed Extra XRP to Be Created
XRP Ledger published details of a critical bug in its payment engine that could have allowed specially crafted offers to create and spend XRP beyond the intended limit. The fix is included in xrpld 3.4.1.
A critical bug in XRPL could, according to an analysis by the XRP Ledger project, have allowed XRP to be created and subsequently spent beyond the intended limit. The project published technical details on October 9, while it had already released a fix on September 25 in version xrpld 3.4.1. XRPL says it found no evidence of exploitation on the public network.
The bug was related to an overflow in a 64-bit sum involving specially crafted offers. If successfully exploited, it would not have been merely a transaction-processing error: it could have affected the integrity of the XRP supply, since the units created this way could have been transferred or traded.
Critical XRPL bug and emergency fix
The fix in xrpld 3.4.1 did not take effect only after the standard amendment vote normally used for changes to the network’s rules. It was applied immediately after the server was updated. The project described this procedure as necessary given the nature of the issue.
According to XRPL, publicly releasing the fix before the standard approximately two-week voting period would have revealed the bug to attackers, leaving it exploitable until then. The source code for version 3.4.1 was published afterward.
The related fixBatchV1_2 amendment ultimately passed the standard validator vote. After its activation, older software versions are blocked, the project says. Server operators should use xrpld 3.4.1 or newer.
Questions about network governance
The case concerns not only the security bug itself, but also the protocol’s governance mechanism. In addressing the bug, XRPL deliberately bypassed the usual two-week activation procedure for changing transaction processing. This raised public questions about whether such a procedure conflicts with the network’s decentralized operation.
The XRPL Foundation and participating operators argue that the coordinated emergency update did not amount to centralized control of the network. However, this is their position; based on the available information, it cannot be independently and objectively confirmed. The fact remains that mandatory deployment of the related amendment took place through a standard validator vote.
No evidence of exploitation, but not complete certainty
The project says that its review found no evidence that the bug was exploited on the Mainnet. However, this finding is not definitive proof that historical exploitation never occurred. The extent of the practical risk during the period when not all servers necessarily used the same version is based primarily on XRPL’s own technical assessment.
For users and infrastructure operators, the key point is that the fix is available and older versions are blocked after the amendment’s activation. Operators who have not yet updated the software should move to xrpld 3.4.1 or a newer version.
What to watch next
- an independent audit or forensic analysis to examine the claim that no exploitation occurred on the Mainnet,
- responses from independent validators and operators to the emergency procedure used to deploy the fix,
- planned additional checks and retesting of security fixes before their release.
Sources
- XRP Ledger – Vulnerability Disclosure Report for xrpld 3.4.1 – Primary technical description of the bug, timeline, remediation method, update status, and the project’s claim that no exploitation was detected.
- XRPLF/rippled – Releases – Confirms the release of xrpld 3.4.1, the security nature of the release, and the update requirement.
- Cointelegraph – Documents public criticism of the emergency procedure and the XRPL Foundation’s response.
Verified and updated: October 12, 2026 06:20
