The Coreum XRPL Bridge recently suffered a 200,000 XRP exploit after an attacker exploited a flaw in its deposit verification process.
The Coreum Bridge suffered an exploit on Aug. 9 that led to the loss of nearly 200,000 XRP. However, an analysis by XRPL-based analytics platform xrpl.to shows that the XRP Ledger was not responsible for the loss despite an earlier report suggesting so.
Notably, the bridge account held about 200,410 XRP before the incident. At 19:16 UTC, it began sending XRP to two newly created wallets. Over the next 97 minutes, the account made 94 XRP payments totaling 199,916.3 XRP, leaving just 493.5 XRP.
The two wallets had been created less than two hours before the first payment and later moved most of the XRP they received to other addresses.
The XRP Ledger Was Not Responsible
The transaction records show that the bridge itself sent every XRP payment. This is because each transaction listed the bridge account as the sender and carried 17 signatures from its 28 relayer keys.
Since the bridge’s master key was disabled, its 17-of-28 multisig setup provided the only way to approve these transactions.
This goes against an earlier explanation that blamed the XRP Ledger’s DefaultRipple setting. For context, native XRP does not use trust lines and cannot be involved in rippling. DefaultRipple applies to issued tokens, not native XRP, meaning the setting could not have caused the XRP to leave the bridge account.
The transactions also did not use the tfPartialPayment flag. Every XRP that left the bridge came through a payment that its own multisig approved. In other words, the XRP did not simply leak from the account because of an XRPL setting. The bridge authorized the transfers itself.
The Problem Started on Coreum
The evidence instead reveals a flaw in how the bridge checked deposits on Coreum. Notably, the bridge uses relayers to monitor the XRP Ledger and report deposits to its Coreum smart contract.
When enough relayers submit the same evidence, the contract accepts the deposit and issues the corresponding wrapped assets.
The problem was that the relayer code did not properly check where a payment went. It looked for successful payments in the bridge account’s transaction history that included a Coreum recipient memo, but it did not require the payment to have actually gone to the bridge.
This allowed the attacker to make payments between their own wallets look like deposits. The attacker first moved the bridge’s own wrapped-CORE token between two wallets under their control.
Although the transaction never sent funds to the bridge, it still appeared in the bridge’s transaction history because the bridge issued the token. Twenty-one relayers then treated the transaction as a valid deposit and reported it to the Coreum contract.
The Attacker Tested the Flaw Before Draining the Bridge
The attacker first tested the system with a 100-unit transfer of the wrapped-CORE token. They then repeated the process with larger amounts, and followed a pattern that roughly doubled the amount at each step.
The exploit eventually created about 4,356,812 CORE and 200,001 XRP worth of bridge tokens without genuine deposits supporting them. After this, the attacker then used those newly created balances to withdraw real XRP from the bridge.
The first XRP payment involved 3,249 XRP. The bridge then sent a much larger 25,908.6 XRP payment before settling into a pattern of transfers of about 1,694.7 XRP to the two attacker-controlled wallets.
The pattern reveals a flaw in the bridge’s code, not a theft of private keys. Twenty-one relayers accepted the first false deposit because they all followed the same verification process. The attacker therefore exploited a weakness in the shared logic that the relayers used to determine whether a deposit was genuine.
The two wallets received about 107,397.5 XRP and 92,518.8 XRP, respectively. They later moved most of the funds to other addresses in transfers of roughly 9,600 to 9,720 XRP. Large portions went to two accounts created on June 28, 2026.
At the time of this report, Coreum had not published a post-mortem identifying the attacker or saying whether any relayer operator had acted beyond negligence.