Root Cause
Coreum's bridge between the Coreum blockchain and the XRP Ledger relies on a committee of relayer nodes that monitor XRPL payment transactions and collectively authorise the minting of wrapped assets on Coreum. The critical flaw was in the relayer deposit-validation logic: relayers confirmed that a payment was directed to the bridge account and that the amount was positive, but they did not verify that the sender was distinct from the bridge account itself or that each depositor address could not produce an unbounded series of credited deposits from a single funded position.
// Simplified pseudocode of the vulnerable relayer deposit check
async function processXRPLPayment(tx: XRPLPayment): Promise<void> {
// Checks that payment reached the bridge escrow account
if (tx.destination !== BRIDGE_ESCROW_ADDRESS) return;
// Checks non-zero amount
if (tx.deliveredAmount <= 0n) return;
// BUG: no check that tx.account !== BRIDGE_ESCROW_ADDRESS
// BUG: no per-depositor rate limit or deposit-nonce tracking
await submitMintAuthorisation(tx.account, tx.deliveredAmount);
}
An attacker who sent XRP from their own wallet to the bridge account had those payments counted as deposits, receiving an equivalent mintable balance on Coreum. The attacker then redeemed that minted balance for native XRP from the bridge reserve, netting the round-trip value.
Attack Steps
| # | Action |
|---|---|
| 1 | Attacker seeds a wallet with a modest XRP balance. |
| 2 | Attacker sends an XRP payment to the Coreum bridge escrow account with a memo tag identifying themselves as depositor. |
| 3 | All 28 relayers observe the payment; 17+ independently submit authorisation for minting wrapped XRP on Coreum. Threshold met. |
| 4 | Attacker receives wrapped XRP on Coreum equal to the payment amount. |
| 5 | Attacker redeems the wrapped XRP via the bridge, withdrawing native XRP from the bridge reserve (net gain per cycle: bridge reserve amount minus attacker's small payment). |
| 6 | Attacker repeats 94 times between 19:16–20:53 UTC, draining the bridge account from 200,410 XRP to 493.5 XRP. |
Impact
- 199,916 XRP drained (~$214,000 at the time of exploit)
- Coreum bridge taken offline; XRP locked on Coreum is not fully backed as of August 17, 2026
- No private keys were compromised and the XRP Ledger itself was unaffected
- TX (the U.S.-based company operating Coreum and Sologenic following their March 2026 merger) confirmed the incident and filed a complaint with the FBI
- A protocol update is under development to address the validation gap
Lessons for Auditors
- Verify deposit source is not the bridge itself. Any bridge relayer crediting deposits based on payments to a bridge address must reject transactions where
sender == bridge_account. This one-line check would have stopped the attack entirely. - Multisig does not compensate for shared flawed logic. Seventeen-of-twenty-eight relayers all running the same validation code gives an adversary 17 correct signatures for a fraudulent transaction. Threshold schemes only defend against key compromise, not logic compromise.
- Per-depositor rate limits and deposit nonces. Each depositor address should have a tracked sequence number or cooldown window; a single address producing 94 sequential deposits at machine speed is a clear anomaly that a rate-limiter would halt.
- Bridge reserve segregation and circuit-breakers. The entire user reserve should not be withdrawable through a single automated flow without a time-delay or guardian approval for large draws.