A serious flaw in a proposed XRPL amendment nearly created a path for attackers to move funds from XRP wallets without private keys. The vulnerability was found in the Batch amendment, known as XLS-56, while it was still under validator voting. Because the proposal had not gained enough support to activate on mainnet, no user funds were exposed and no live transactions were affected.
The issue was identified by independent security researcher Pranamya Keshkamat together with an autonomous AI security tool called Apex. After the discovery, developers released Rippled 3.1.1 and explicitly marked the Batch amendment as unsupported, cutting off the chance that the vulnerable code could be activated by mistake.
How the signer check created an authorization bypass
XLS-56 was designed to improve efficiency by allowing multiple inner transactions to sit under a single outer signature. Those inner transactions were intentionally left unsigned, with authorization delegated to the outer batch signer list. That design reduced overhead, but it also made the signer validation path more sensitive.
According to the disclosure, the software used a loop to verify authorized accounts. If that loop encountered a signer linked to an account that did not yet exist on the ledger, and the signing key matched that new account, the system could immediately treat validation as successful. Then it stopped. Checks that should have continued were skipped because the code exited the loop too early.
That early exit opened the door to an authorization bypass. An attacker, in theory, could have built a specific batch sequence to transfer funds or alter ledger state without legitimate approval. The attack never happened on the live network, but developers said the risk was severe enough to require immediate action. The patched code removes the premature exit logic and hardens the authorization flow.
Why the amendment process kept the flaw off mainnet
The most important safeguard was procedural: XLS-56 had not yet reached the consensus threshold required for activation. The code was still in the amendment voting phase, which gave validators, researchers, and core contributors time to examine it before it could affect production systems.
This case also highlighted the value of layered review. Independent researchers flagged the issue, an automated security tool helped surface it, and maintainers moved quickly to ship a blocking update. The revised amendment is now under peer review before any fresh consideration for voting. For XRPL, the near miss ended without wallet losses or ledger disruption, but it exposed how dangerous a subtle signer validation bug could have been.