Nearly 200,000 XRP was drained from the Coreum XRPL bridge on Aug. 9 after an attacker appears to have exploited a flaw in its relayer logic, rather than a vulnerability in the XRP Ledger itself.
Summary
- Nearly 200,000 XRP left Coreum’s bridge in 94 signed payments during a 97 minute attack.
- Blockchain analysis found 17 of 28 relayer signatures authorized each XRP payout from the bridge.
- Relayer code processed successful payments with bridge memos without verifying the payment destination address first.
- XRPL documentation confirms native XRP has no trust line, contradicting the initial rippling explanation directly.
- Coreum had not published an official incident report by Tuesday while the bridge remained halted.
On chain analysis published Aug. 11 traced 199,916.3 XRP leaving the bridge account through 94 payments over 97 minutes.
The bridge held about 200,410 XRP before the sequence began at 19:16 UTC. By 20:53 UTC, its balance had fallen to 493.5 XRP. Every outgoing XRP payment carried the bridge’s own multisignature authorization, with 17 signatures from its 28 relayer keys. The evidence does not indicate that those keys were stolen.
XRP bridge relayers mistook self payments for deposits
The attack appears to have targeted how Coreum’s relayers interpreted transactions. The attacker first moved the bridge’s own wrapped Coreum token between wallets under their control while attaching a memo formatted for the bridge. Those transactions appeared in the bridge account’s history because the account issues the wrapped token.
The public relayer code checks whether a payment succeeded, extracts a Coreum recipient from its memo and reads the delivered amount before submitting deposit evidence. However, the published processing flow does not compare the payment’s destination with the bridge address. That allowed wallet to wallet transfers carrying the right memo to be interpreted as deposits.
XRPL.to found that 21 relayers attested the attacker’s first phantom transaction. Once enough matching evidence reached the Coreum contract, the system credited balances that were not backed by real deposits. The attacker then used the bridge’s normal withdrawal process, prompting its relayers to authorize real XRP payments.
The pattern resembles a wider bridge security problem discussed in recent security coverage: cross chain systems can fail even when their underlying blockchains remain secure if the mechanism verifying events on another chain accepts incorrect information.
XRP Ledger data contradicts the rippling theory
An initial warning blamed “rippling” and the bridge account’s DefaultRipple setting. The later transaction analysis rejected that explanation. XRP Ledger documentation states that rippling applies to issued assets held through trust lines. Native XRP does not use those trust lines.
The transaction record provides another distinction. XRPL.to attributed all 199,916.3 XRP removed from the account to payments signed by the bridge itself and found no XRP leaving through a rippling route. It also found that the transactions were not partial payments.
The incident therefore does not currently point to an XRP Ledger consensus failure. That distinction is relevant after developers recently strengthened review of XRPL software and proposed features, as covered in previous software audit coverage. The Coreum incident instead centers on software connecting two independent networks.
Stolen XRP moves onward as bridge stays halted
The two initial receiving wallets forwarded nearly all the XRP within hours. XRPL.to traced roughly 169,000 XRP into two staging accounts created on June 28, with another roughly 34,000 XRP moving toward three other wallets. The analysis has not identified the attacker.
No further XRP left the bridge after 20:53 UTC on Aug. 9. Its account made one additional wrapped token transaction early the next morning before going silent, while the bridge contract was subsequently reported halted. Coreum had not published an official post incident account when the Aug. 11 analysis was released.
The bridge’s own specification allows any relayer or the contract owner to halt operations when unexpected behavior occurs, while only the owner can resume them. The next steps to watch are a formal incident report, remediation of the destination verification flaw, any recovery efforts involving the transferred XRP and a decision on when the bridge can safely reopen.
Be the first to comment