XRPL batch amendment security patch blocks mainnet risk

The XRPL Foundation has halted a serious issue linked to the xrpl batch amendment before it could impact the mainnet, underscoring the ledger’s evolving security posture.

Critical flaw detected during voting phase

The XRPL Foundation disclosed that a critical vulnerability in the proposed Batch amendment was identified and neutralized before mainnet activation. The flaw surfaced while the change was still in its validator voting phase, allowing developers to respond before any production impact.

The issue was discovered on Feb. 19, 2026, by security engineer Pranamya Keshkamat together with Cantina AI’s autonomous tool Apex. According to the foundation, no user funds were ever at risk because the amendment had not yet been enabled on the XRPL mainnet.

The amendment, formally known as XLS-56, aimed to introduce batched transactions on the XRP Ledger. It would have allowed multiple inner transactions to be grouped into a single batch, improving efficiency and coordination. However, those inner transactions were intentionally left unsigned, with authorization delegated to an outer batch transaction listing the signers.

How the bug in signature validation worked

According to the foundation’s postmortem, the vulnerability was rooted in the signature validation logic of the Batch feature. Moreover, the problem centered on a loop error in the signer validation function used to verify batch authorizations.

When the system encountered a signer entry tied to an account that did not yet exist on the ledger, it could exit the loop early. If the signing key matched the new account, the validation process would be incorrectly marked as successful. That said, the software would then skip checks for all remaining signer entries in the batch.

This behavior opened a path to unauthorized transactions. An attacker could execute operations from victim accounts without possessing their private keys, because key checks for those accounts might be bypassed. At the time of discovery, the amendment was only in the validator voting phase and remained disabled on mainnet.

The XRPL Foundation stressed that the proposal had not been activated and reiterated: “The amendment was in its voting phase and had not been activated on mainnet; no funds were at risk.” This assurance was critical to limiting market concern and highlighting the benefit of rigorous pre-activation testing.

Potential impact of the batch amendment bug

The reported exploit scenario required a carefully crafted batch transaction. An attacker would construct a batch containing three inner operations, orchestrated to exploit the faulty logic in signer validation.

First, one inner transaction would create a new account fully controlled by the attacker. Second, another inner transaction would submit a simple transfer or action from that newly created account. Third, a payment from a chosen victim account to the attacker’s account would be included, attempting to move funds without legitimate authorization.

To complete the setup, the attacker would provide two batch signer entries. One signer entry would be valid for the new attacker-controlled account. The second signer entry would falsely claim to authorize transactions for the victim account. However, due to the early loop exit bug, the system might accept the first signer and never properly validate the second.

As a result, the victim’s payment could be executed without a valid signature, transforming the ledger in ways the victim did not approve. The XRPL Foundation warned that successful use of this technique could have enabled arbitrary fund transfers and disruptive ledger changes if deployed at scale.

Moreover, the organization highlighted the risk to broader ecosystem confidence if such an exploit had reached mainnet. Cantina and Spearbit CEO Hari Mulackal commented, “Our autonomous bug hunter, Apex, found this critical bug.” Ripple engineering teams then reproduced the behavior with a proof-of-concept and completed a full unit test before addressing the flaw.

Emergency response and rippled update

Following disclosure, XRPL’s UNL validators were promptly advised to vote “No” on the Batch proposal. This coordination ensured that the amendment could not accidentally cross the activation threshold while remediation was underway.

An emergency software release, rippled 3.1.1, was issued on Feb. 23, 2026. This release explicitly marks both the original Batch amendment and the related fixBatchInnerSigs change as unsupported. Consequently, they are blocked from receiving validator votes and cannot be enabled on any production network.

The emergency version does not include the final corrected logic. Instead, it functions as a protective barrier, ensuring that neither Batch nor fixBatchInnerSigs can reach activation in their flawed form. However, this immediate safeguard bought developers crucial time to design and review a safer replacement.

A corrected amendment named BatchV1_1 has now been implemented as the successor to the original design. This update removes the early exit in signer validation and strengthens checks on all authorization paths. The foundation confirmed that this revision remains under review, and no deployment date has been scheduled.

Strengthening XRPL security practices

In the wake of the incident, the XRPL Foundation outlined additional security measures to harden development workflows. Moreover, it plans to expand the role of AI in reviewing protocol changes to catch subtle logic errors earlier in the process.

The organization intends to increase the use of AI-assisted code audits, building on the success of Cantina AI’s tools and the Apex system in this case. It will also broaden static analysis to specifically detect patterns like premature success returns inside loops, which contributed to the flaw in the batch validation logic.

That said, the foundation stressed that the xrpl batch amendment episode shows the importance of layered defenses, including human review, autonomous analysis and staged activation. By combining these approaches, maintainers aim to reduce the risk of undetected vulnerabilities in future protocol upgrades.

Ultimately, the XRPL Foundation emphasized that the critical bug was patched before mainnet activation and before any funds were compromised. The early detection, coordinated validator response and rapid rippled emergency release helped prevent unauthorized transactions and preserved the integrity of the XRPL network.