A security flaw in a proposed XRP Ledger (XRPL) upgrade could have allowed unauthorized transactions, but researchers flagged the problem before it could reach the blockchain’s main network.
XRPL Foundation said On February 26, it was announced that the vulnerability was found in the proposed “Batch” amendment, a feature intended to let users bundle multiple actions into a single atomic transaction.
Security researcher Pranamya Keshkamat and Apex, Cantina AI’s autonomous static analysis tool, reported the issue on February 19, the foundation said.
If the amendment had been enabled while the bug was present, an attacker could have performed internal transactions as if they were authorized by another account, without access to that user’s private keys.
That could have allowed unauthorized fund transfers and changes to the ledger settings on the victim’s account, even though the victim did not sign the transaction.
The revelation comes as XRPL has positioned itself for use cases such as tokenization and other compliance-sensitive activities, where perceived security and reliability are central to institutional adoption.
Understanding the critical security flaw in XRPL batch changes
The proposed Batch Amendment changed the way authorization would work on the
That atomic structure can reduce execution risk for developers performing multi-step operations. A new authorization limit is also created.
In the batch design, inner transactions are intentionally unsigned. Instead, authority is delegated to a list of batch signers associated with the outer transaction, making the signer validation code a critical checkpoint.
If these checks fail, the ledger may consider unauthorized actions valid.
According to the disclosure, the bug stemmed from a loop error in the function that validates batch signers.
When the code encountered a signer whose account did not yet exist in the ledger and whose signing key matched that same account, a normal status for a newly created account, the code immediately returned success and stopped checking the rest of the signer list.
That condition was more dangerous in a batch system than it sounds. A batch can contain steps that create accounts within the same atomic sequence, meaning whether an account exists at the time of validation becomes part of the authorization boundary.
According to the report, an attacker could have inserted a valid signing input for an uncreated account he controlled, triggering the premature success condition and bypassing the validation of a spoofed signing input claiming to authorize a victim account.
If Batch had been activated before the error was discovered, the consequences could have been serious.
The Foundation said an attacker could have carried out internal payment transactions that diverted victims’ accounts to the reserve. The same bug could also have allowed unauthorized operations at the account level, including AccountSet, TrustSet, and possibly AccountDelete.
That would amount to a “spending without keys” scenario, the kind of security failure that can cause reputational damage even if losses are limited and addressed quickly.
The flaw could have destroyed XRPL’s security veneer
The flaw could have damaged XRPL’s security story at a sensitive time for the network, which is aggressively expanding into real-world asset (RWA) tokenization and institutional DeFi.
Data from DeFiLlama shows that XRPL has approximately $50 million in total DeFi assets locked on the platform, with nearly $2 billion in RWA assets.
In crypto markets, authorization errors often shape perception long after the underlying technical issue has been resolved.
For a ledger that positions itself as an infrastructure for regulated finance, such an incident would have had wider consequences.
This is especially true as XRPL recently introduced a new set of institution-oriented features, including Permissioned Domains and DEXs.
These features are designed to create secure trading platforms where only approved participants can place and accept orders. The model is aimed at institutions that want blockchain-based settlement without open access for all counterparties.
So the security problem would have undermined that message. A network cannot easily be market-driven or compliance-oriented in on-chain environments, while a proposed transaction upgrade carries the risk of unauthorized actions involving arbitrary accounts.
How XRPL Averted the Security Incident
XRPL’s response was swift through governance and software channels.
The unique Node List (UNL) of trusted validators was contacted and advised to vote “No” on the Batch Amendment.
On February 23, XRPL published rippled 3.1.1, an emergency release that marks both Batch and fixBatchInnerSigs as unsupported. That prevented the amendments from receiving validator votes or being activated on the network.
The release was intended for immediate containment, not a full repair. The disclosure explicitly stated that release 3.1.1 does not contain the underlying logic fix.
XRPL also scheduled a devnet reset for March 3, 2026, to coincide with the 3.1.1 change. That reset only applies to Devnet, not mainnet, but it shows the extent to which the network operators took action to prevent the issue from affecting the active change paths.
A corrected replacement, BatchV1_1, has already been deployed and is currently under review, with no release date set.
According to the announcement, the complete solution eliminates early shutdown, adds additional authorization guards, and limits the scope of signature control.
The report also outlined a broader security roadmap, including more standardized AI-enabled audits, expanded static analysis checks for dangerous loop outputs, and an assessment of similar patterns elsewhere in the codebase.
The next test is to ship the replacement safely
For XRPL, the February outcome will be regarded as a managerial success. The bug was found before activation. Validators coordinated. An emergency release blocked the change path. No money was lost.
But the story doesn’t end there.
BatchV1_1 is now assessed at two levels. The first is technical: whether it delivers the developer benefits of atomic transaction bundling without reopening authorization risk.
The second is procedural: whether XRPL’s governance and engineering systems can keep pace with an expanding set of functions aimed at institutional adoption.
That is the real background to this near miss. XRPL is seeking to grow into a broader financial platform, one that can host gated trading platforms, permissioned environments and more advanced transaction logic, while also attracting builders with ecosystem capital and product breadth.
The more ambitious the roadmap becomes, the more important boring things like signer validation and walking behavior become.
In this case the brakes worked. The next challenge is to prove that the system can accelerate again without losing the safety margin.