Full Report
XRPL added a Batch execution feature. The idea was to have multiple instruction types, such as multiple payments, in a single transaction by batching them altogether. Right before launching the feature, the Cantina AI tool found a horrific vulnerability in the codebase. This is the bug report. The inner transactions in a Batch are intentionally unsigned. This is because the authorization is delegated to the outer batch list of signers. Because of this, there's a function that checks that the owner of the transaction matches the signers. Otherwise, a batch could impersonate other users, so this check is crucial. This validation could be bypassed in a single case: a signer whose account did not yet exist on the ledger and whose signing key matched their account would immediately return success without further validating the inner instructions. As a result, the validation of the remaining signers was completely skipped, allowing for impersonation of other users. Here are the exploit steps: Attacker constructs a batch transaction with three inner instructions. One that creates a new account. One simple transaction from the new account with a valid signer. The final one is the exploit: a transaction where the attacker impersonates the victim. The attacker provides two batch signer entries: a legitimate one for account B and a forged one with the victim account. Because account B doesn't exist at validation time, the signer check exits successfully without validating the second. The victim's payment executes without the victim's key signing. To remediate the issue, the batch proposal was rejected. The team is currently working on a fix for the vulnerability on the early exit. The bug was a funny edge case in the system. To me, this really shows that the more complex the system is, the more bugs like this will appear. Good job to the engineer and the Cantina AI for the discovery! We have entered a new era.
Analysis Summary
# Vulnerability: XRPL Batch Amendment Unauthorized Inner Transaction Execution
## CVE Details
- **CVE ID:** Not yet assigned (Discovered Feb 19, 2026)
- **CVSS Score:** 10.0 (Critical - internal assessment based on impact)
- **CWE:** CWE-287: Improper Authentication / CWE-670: Always-Incorrect Control Flow Implementation
## Affected Systems
- **Products:** rippled (XRP Ledger node software)
- **Versions:** Version 3.1.0
- **Configurations:** Systems where the `Batch` amendment is enabled/voting for activation.
## Vulnerability Description
The vulnerability exists in the signature-validation logic of the `Batch` amendment. In a Batch transaction, inner instructions are intentionally unsigned as authorization is delegated to the outer batch signers.
The flaw occurs in a specific edge case: if an attacker includes a signer entry for an account that does not yet exist on the ledger (e.g., a newly generated address with no balance), and the signing key matches that non-existent account, the validation function returns an immediate "success" status. Due to a logic error in the "early exit" implementation, the code fails to validate any subsequent signers in the list. This allows an attacker to append unauthorized transactions from any victim account to the batch, bypassing the requirement for the victim's private key.
## Exploitation
- **Status:** PoC available (validated by Ripple engineering); not exploited in the wild (Mainnet).
- **Complexity:** Medium
- **Attack Vector:** Network
- **Exploit Steps:**
1. Construct a batch transaction with multiple inner instructions.
2. Include an instruction to create/fund a new Account B.
3. Include an instruction impersonating a Victim Account V.
4. Provide a signer entry for Account B (which doesn't exist at the moment of validation) followed by a forged entry for Account V.
5. The system validates Account B, hits the "early exit" success bug, and executes Account V's payment without a valid signature.
## Impact
- **Confidentiality:** Low
- **Integrity:** High (Total bypass of transaction authorization)
- **Availability:** High (Potential for large-scale ledger state corruption and fund theft)
## Remediation
### Patches
- **rippled v3.1.1:** This emergency release marks the `Batch` and `fixBatchInnerSigs` amendments as unsupported, preventing them from ever being activated on the network.
- **BatchV1_1:** A replacement amendment is currently under review to replace the flawed logic.
### Workarounds
- **Validator Action:** UNL validators were instructed to vote "No" on the original `Batch` amendment to prevent activation.
- **Upgrade:** Node operators should upgrade to **rippled 3.1.1** immediately to remove the vulnerable code path.
## Detection
- **Indicators of Compromise:** Batch transactions containing multiple signer entries where the primary signer is a newly created account and subsequent signers are well-funded victim accounts.
- **Detection methods and tools:** Static analysis tools (like Cantina AI's Apex) and monitoring for `Batch` transaction types on Devnet/Testnet.
## References
- **Vendor Advisory:** hxxps://xrpl[.]org/blog/2026/vulnerabilitydisclosurereport-bug-feb2026
- **Release Notes:** hxxps://xrpl[.]org/blog/2026/rippled-3.1.1
- **Discovery Team:** hxxps://cantina[.]ai/