Vulnerability Disclosure Report: XRPL Batch Amendment – Unauthorized Inner Transaction Execution

コピー

• LLM用にコピー

  LLM用にページをMarkdownとしてコピー
• Markdownで表示

  このページをMarkdownで開く
• ChatGPTで開く

  ChatGPTから洞察を取得
• Claudeで開く

  Claudeから洞察を得る

By XRPL Labs

This vulnerability disclosure report contains technical details of the XRPL Batch amendment bug reported on February 19, 2026.

Date Reported: February 19, 2026

Affected Version(s): rippled 3.1.0 (with the Batch amendment enabled)

Summary of Vulnerability

On February 19, 2026, Pranamya Keshkamat and Cantina AI identified a critical logic flaw in the signature-validation logic of the XRPL Batch amendment. The bug allowed an attacker to execute inner transactions on behalf of arbitrary victim accounts without their private keys, enabling unauthorized fund transfers and ledger state changes. The amendment was in its voting phase and had not been activated on mainnet; no funds were at risk. Note that even before this bug was reported, the Batch amendment was disabled due to extra caution around ensuring the fixBatchInnerSigs amendment activated first.

UNL validators were immediately advised to vote "No" on the amendment. The emergency release rippled 3.1.1 marks both Batch and fixBatchInnerSigs as unsupported, preventing activation. A corrected replacement, BatchV1_1, has been implemented and is currently under review; no release date has been set.

Impact

If the Batch amendment had activated before this bug was caught, an attacker could have:

• Stolen funds: executed inner Payment transactions draining victim accounts down to the reserve, without access to victim private keys.
• Modified ledger state: submitted AccountSet, TrustSet, and potentially AccountDelete transactions from victim accounts without authorization.
• Destabilized the ecosystem: a successful large-scale exploit could have caused substantial loss of confidence in XRPL, with potentially significant disruption for the broader ecosystem.

Technical Details

Discovery

Pranamya Keshkamat and the autonomous AI security tool Apex (developed by Cantina AI) identified the vulnerability via static analysis of the rippled codebase and submitted a responsible disclosure report. Ripple engineering teams promptly validated the report with an independent proof-of-concept and a full unit-test reproduction. Remediation began the same evening.

Root Cause

When the Batch amendment is enabled, inner transactions in a batch are intentionally unsigned; authorization is delegated entirely to the outer batch's list of batch signers. The function responsible for validating those signers contained a critical loop error: when it 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.

Exploit Path

1. The attacker constructs a batch transaction containing three inner transactions: one that creates a new account they control (account B), one simple transaction from that new account (making it a required signer), and one payment from the victim account to the attacker.
2. The attacker provides two batch signer entries: a legitimate one for account B signed with B's own key, and a forged one claiming to authorize the victim account but signed with the attacker's own key.
3. Because account B does not yet exist at validation time, the signer check exits successfully after the first entry and never validates the second.
4. The victim's payment executes without the victim's keys ever being involved.

Remediation

• UNL validators were contacted and advised to vote "No" on the Batch amendment.
• rippled 3.1.1 was published on February 23, 2026. This release marks Batch and fixBatchInnerSigs as unsupported, preventing them from receiving validator votes or being activated on the network. This is the immediate remediation and does not contain the underlying logic fix.
• The full logic fix removing the early-exit, adding additional authorization guards, and tightening the scope of the signing check has been implemented and is undergoing a thorough review process prior to release under the BatchV1_1 amendment. Given the sensitivity of the changes, no timeline has been set.

Security Enhancements Roadmap

• 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.
• Reviewing all other locations in the codebase where early success returns occur inside loops to confirm no similar patterns exist.

Steps to Reproduce

1. Fund two attacker-controlled accounts and leave a third unfunded. Construct a batch transaction containing a payment that creates the unfunded account, a simple transaction from that account, and a payment from the victim account to the attacker.
2. Sign the batch message with the unfunded account's master key for its signer entry, and with the attacker's own key for a second signer entry that falsely claims to authorize the victim account.
3. Submit the batch transaction to the network.

Pre-fix behavior:

• The batch transaction succeeds.
• The victim account's balance is reduced by the payment amount without the victim's keys being used.
• The attacker's balance increases by the net amount minus the batch fee.

Expected post-fix behavior:

• The batch transaction is rejected with an authorization error.
• No account balances change.

Fixes / Patches Available

rippled 3.1.1 is available now. The corrected BatchV1_1 amendment will be included in a future release following completion of its review; no date has been set.

Acknowledgements

Thanks to Pranamya Keshkamat and Cantina AI (whose autonomous security tool Apex identified the vulnerability) for responsible and thorough disclosure. Their detailed bug report, proof-of-concept, and constructive collaboration throughout the remediation process were invaluable.

Thanks also to the UNL validators who moved swiftly to vote against the affected amendment, the Ripple and XRPL Foundation engineering teams for the expedited review and emergency release, and the broader community of validators, developers, and contributors who keep the XRP Ledger safe and secure.

References

• rippled 3.1.1 release
• Community post on X

Contact

To report security issues, contact [email protected].

Incident Response Timeline