Coreum-XRPL Bridge Loses 200,000 XRP to Logic Flaw, Not Stolen Keys
- The Coreum-XRPL bridge lost nearly 200,000 XRP through 94 payments over roughly 97 minutes on August 9.
- Every withdrawal carried valid multisignature approval from the bridge’s relayer network, with no evidence any keys were stolen.
- The flaw let an attacker create unbacked balances by tricking relayers into treating certain transactions as real deposits.
A cross-chain bridge connecting Coreum and the XRP Ledger lost nearly 200,000 XRP this week, not through stolen keys or a compromised validator set. No! But through a logic flaw in how the bridge’s relayer network determined what counted as a legitimate deposit.
On-chain analysis by XRPL.to found that 199,916.3 XRP left the Coreum-XRPL bridge on August 9 across 94 separate payments over about 97 minutes. The bridge held about 200,410 XRP before the withdrawals began. It was left with about 493.5 XRP once they finished.
How a Fully Authorized Withdrawal Can Still Be Fraudulent
What makes the incident unusual is that every payout carried proper authorization. Each withdrawal included the bridge’s own multisignature approval, which requires agreement from 17 of its 28 relayer keys, and there’s currently no evidence those keys were stolen or compromised in any conventional sense.
The actual flaw sat in how relayers, programs that monitor activity on connected chains and flag qualifying deposits, determined what counted as a real deposit in the first place. The bridge issues a wrapped CORE token on the XRP Ledger, and because it’s the token issuer, transactions involving that asset can affect bridge-related records even when the funds are moving between two unrelated wallets the attacker controls.
According to XRPL.to’s analysis, the attacker exploited that by making transactions between their own wallets using the memo format the bridge’s relayers expected from a legitimate deposit. Relayers detected those transactions and treated them as real deposits, even though no funds had actually moved into the bridge.
In one documented instance, 21 separate relayers reportedly submitted the same attacker-controlled transaction as a valid deposit. Repeating that pattern let the attacker build unbacked bridge balances representing roughly 200,001 XRP alongside millions of CORE tokens, then withdraw the artificial balance through the bridge’s completely normal, properly signed process.
What the Incident Says About Bridge Security
The 17-of-28 signature threshold did exactly what it was designed to do: it prevented an attacker from directly seizing control of the bridge’s wallet. What it couldn’t prevent was every relayer running the same flawed verification logic and independently reaching the same wrong conclusion about what constituted a deposit.
That distinction matters for how cross-chain bridge security gets evaluated going forward. Multisignature custody protects against unauthorized access to a wallet’s keys, but it doesn’t verify that the underlying economic event a signature is approving actually happened as described.
For relayer-based bridges specifically, confirming that a transaction exists on-chain isn’t sufficient on its own. Systems also need to confirm the funds reached the correct destination, involved the expected asset and amount, and represented a genuine deposit rather than a transaction engineered to look like one.
Sources:
