XRPL Patches Critical Batch Amendment Bug That Could Have Drained Funds, Discovered by AI Security Tool

The XRP Ledger Foundation confirmed on February 26, 2026, that a critical vulnerability in the signature-validation logic of the proposed Batch amendment was identified and patched before activation, averting a potential exploit that could have allowed attackers to execute unauthorized transactions and drain funds without access to victim private keys.

Discovered by security engineer Pranamya Keshkamat and Cantina’s autonomous AI security tool Apex on February 19, the flaw was addressed through an emergency release of rippled version 3.1.1 on February 23, with no funds at risk as the amendment remained in the voting phase and never activated on mainnet.

Discovery and Disclosure Timeline

On February 19, 2026, a critical logic flaw was identified in the signature-validation code of the proposed Batch amendment for the XRP Ledger. The vulnerability was discovered through static analysis of the rippled codebase by Pranamya Keshkamat, a security engineer at cybersecurity firm Cantina, working in conjunction with Cantina’s autonomous AI security tool, Apex.

The discovery team promptly submitted a responsible disclosure report to the XRPL Foundation, allowing Ripple engineering teams to validate the finding with an independent proof-of-concept and full unit-test reproduction. Remediation efforts began the same evening.

Hari Mulackal, CEO of Cantina and Spearbit, stated that “our autonomous bug hunter, Apex, found this critical bug,” adding that “had this been exploited, it would have been the largest security hack by dollar value in the world, with nearly $80 billion at direct risk,” referencing XRP’s market capitalization.

Technical Nature of the Vulnerability

The vulnerability resided in the signature-validation logic of the Batch amendment, a proposed feature that would allow atomic execution of up to eight transactions in a single batch operation. When enabled, inner transactions in a batch are intentionally unsigned, with authorization delegated entirely to the outer batch’s list of batch signers.

The root cause was a critical loop error in the function responsible for validating those signers. When the validator encountered a signer whose account did not yet exist on the ledger and whose signing key matched their own account—the normal case for a brand-new account—it immediately declared success and exited, skipping validation of all remaining signers entirely.

This flaw created a clear exploit path: an attacker could construct a batch transaction containing three inner transactions—one creating a new account they control, one simple transaction from that new account (making it a required signer), and one payment from a victim account to the attacker. By providing two batch signer entries—a legitimate one for the new account and a forged one claiming to authorize the victim account but signed with the attacker’s own key—the validation would exit successfully after the first entry and never validate the second, allowing the victim’s payment to execute without their keys ever being involved.

Potential Impact and Remediation

If the Batch amendment had activated before the bug was caught, an attacker could have stolen funds by executing inner Payment transactions draining victim accounts down to the reserve, modified ledger state through unauthorized AccountSet, TrustSet, or AccountDelete transactions, and potentially destabilized the broader ecosystem through loss of confidence in XRPL.

Upon confirmation of the vulnerability, UNL validators were immediately contacted and advised to vote against the Batch amendment. The emergency release rippled 3.1.1 was published on February 23, 2026, marking both Batch and fixBatchInnerSigs as unsupported, preventing them from receiving validator votes or being activated on the network.

A corrected replacement amendment, BatchV1_1, has been implemented with the full logic fix removing the early-exit condition, adding additional authorization guards, and tightening the scope of the signing check. This replacement is currently undergoing thorough review prior to release, with no timeline yet established.

AI’s Emerging Role in Cybersecurity

The discovery highlights the growing role of artificial intelligence in cybersecurity applications. Apex, Cantina’s autonomous AI security tool, identified the vulnerability via static analysis of the codebase, demonstrating AI’s capability to detect subtle bugs that might be overlooked by human reviewers.

This incident coincides with broader industry developments in AI-powered security. On February 20, Anthropic released Claude Code Security, an AI cybersecurity vulnerability scanner that the company claims “can reason like a skilled security researcher.” The emergence of these tools signals a potential shift in how critical infrastructure vulnerabilities are identified and addressed.

XRPL Foundation Response and Future Measures

The XRPL Foundation has outlined a security enhancements roadmap in response to the incident, including adding AI-assisted code audit pipelines as a standard step in the review process, extending static analysis coverage to flag premature success returns inside signer-iteration loops, adding explicit comments and invariant assertions documenting expected behavior for uncreated accounts at validation time, and reviewing all other codebase locations where early success returns occur inside loops to confirm no similar patterns exist.

The foundation also announced a scheduled devnet reset for March 3, 2026, to accommodate the changes and prevent validators who upgrade from becoming amendment-blocked. The reset will delete all devnet ledger data, including accounts, transactions, balances, and other records, with all balances reset to zero and the block number restarting at one. Mainnet, XRPL Testnet, Xahau, and the Hooks testnet will continue normal operations unaffected.

FAQ: Understanding the XRPL Batch Amendment Vulnerability

Q: What was the Batch amendment supposed to do on XRP Ledger?

A: The Batch amendment was a proposed feature allowing atomic execution of up to eight transactions in a single batch operation. It would have enabled developers to build applications with paid features, automated workflows, and direct on-chain revenue models by ensuring multiple transactions executed together either all succeeded or all failed.

Q: How could attackers have exploited this vulnerability?

A: Attackers could have constructed a batch transaction with a payment creating a new account, a transaction from that account, and a payment from a victim account. By exploiting a flaw where validation exited early when encountering a signer for a non-existent account, they could bypass signature checks on the victim’s payment and drain funds without ever possessing the victim’s private keys.

Q: Why was no money lost in this incident?

A: The Batch amendment was still in its voting phase and had not been activated on mainnet when the vulnerability was discovered. The XRPL Foundation immediately advised validators to vote against the amendment and issued an emergency software release (rippled 3.1.1) disabling it entirely, preventing any possibility of activation.

Q: What role did AI play in discovering this vulnerability?

A: Cantina’s autonomous AI security tool, Apex, identified the vulnerability through static analysis of the rippled codebase. The AI’s discovery, combined with human security engineer analysis, enabled responsible disclosure and patching before the amendment could be activated, demonstrating the growing importance of AI-powered cybersecurity tools.