Worked example · 2026-08

Coreum–XRPL bridge — relayers verified that a deposit message was well-formed and never that the XRP had arrived, so self-transfers carrying a forged memo released 199,916 real XRP — Coreum / XRP Ledger — 2026-08-09

Loss: 199,916 XRP (~$200K at the time), drained in 94 separate multisig-authorised payments over 97 minutes, from 19:16 UTC to 20:53 UTC. The bridge's XRPL account fell from roughly 200,410 XRP to 493.5 XRP — effectively the entire reserve. Proceeds went to two newly created wallets. The XRP Ledger itself was not compromised and no bridge private key was stolen.
OAK Techniques observed: OAK-T10.002 (Message-Verification Bypass — primary, confirmed mechanism, in its off-chain relayer form rather than the usual on-chain-contract form. The bridge's relayers validated a deposit notification by checking that the transaction succeeded, that it carried the expected amount, and that the recipient named in the memo was well-formed — but never checked the one fact the withdrawal depended on: whether the corresponding XRP had actually reached the bridge's XRPL account. The attacker moved wrapped Coreum tokens between wallets they already controlled and attached a memo shaped like a genuine bridge deposit; the relayers read the memo as truth and authorised real XRP out the other side. See techniques/T10.002-message-verification-bypass.md). OAK-T10.002.001 (Off-chain Observer Source-Event Forgery — this case is the canonical semantic / custody-level anchor, and the second independent anchor that promoted the sub-Technique from forward candidate to emerging in 2026-08. Its sibling shape is parse-level forgery, anchored at Across on Solana (2026-07), where the observer failed to check that the data it parsed was the event it resembled. Here nothing failed at the parse step: the message was well-formed and its fields were validated — the observer simply never checked the fact the message asserted. Fix differs accordingly: a type-identity check closes the parse-level shape, a custody-state read closes this one. See techniques/T10.002.001-off-chain-observer-source-event-forgery.md). OAK-T10.001 (Validator / Signer Key Compromise) explicitly does not apply — the multisig signers behaved exactly as designed and signed payments the relayer set told them were legitimate; the authorisation was genuine and the premise was false.
Attribution: pseudonymous. No named individual or group and no link to a tracked OAK actor. On-chain identifiers only: two freshly created recipient wallets. TX, the company behind Coreum, confirmed the incident and filed a complaint with the FBI. Public analysis is explicit that available evidence points to a relayer-validation flaw with forged deposit information, not to stolen keys or any weakness in the XRP Ledger.
Key teaching point: A bridge that verifies the deposit message instead of the deposit balance is an honour system with extra steps. Every check the relayers performed was real, and every one of them was performed against an object the attacker authored. Success status, amount, and destination were all copied out of a memo — a free-text field — on a transaction the attacker sent to themselves. The single missing check is also the cheapest one available: read the bridge's own XRPL account balance and confirm it went up by the claimed amount before releasing anything. The structural lesson is that custody state, not event data, is the only safe basis for a release decision. Events describe what someone says happened; balances are what actually happened. This is the same failure as a forged proof accepted on-chain, relocated to the off-chain observer set, and it argues that the reconciliation control usually filed under proof-of-reserves belongs inside the hot release path — every withdrawal gated on locked-versus-issued parity — rather than as a periodic report published after the fact.

Summary

The Coreum–XRPL bridge connects the Coreum chain to the XRP Ledger, with an XRPL account holding the XRP that backs wrapped balances on the Coreum side. Withdrawals are authorised by a relayer set that observes deposit activity and instructs multisig signers to release XRP.

The relayers' validation logic examined the deposit notification rather than the deposit itself. On 2026-08-09, an attacker exploited this by moving wrapped Coreum tokens between wallets under their own control and attaching a memo constructed to look like a legitimate bridge deposit, naming an amount and a recipient. The relayers confirmed the transaction had succeeded, read the amount and recipient from the memo, found them well-formed, and treated the sequence as a genuine inbound deposit — without verifying that any XRP had been received by the bridge's XRPL account.

Each forged signal triggered a real withdrawal. Beginning at 19:16 UTC, the bridge released XRP across 94 multisig-authorised payments, and by 20:53 UTC — 97 minutes later — its account balance had fallen from about 200,410 XRP to 493.5 XRP, a total of 199,916 XRP sent to two newly created wallets.

The bridge was halted once the drain was identified. TX, the company behind Coreum, confirmed the incident and filed a complaint with the FBI. Public analysis has been consistent that the XRP Ledger was not compromised and that no bridge private keys were stolen — the loss traces entirely to what the relayers chose to verify.

Timeline (UTC)

When	Event	OAK ref
(standing)	Relayer validation checks transaction success, memo amount, and memo recipient — but not whether XRP reached the bridge's XRPL account	(standing T10.002 surface)
2026-08-09 (pre-event)	Attacker prepares wallets on both sides and constructs transfers of wrapped Coreum tokens between addresses they control, carrying memos shaped like genuine bridge deposits	(setup)
2026-08-09 19:16	First forged deposit signal accepted; multisig-authorised XRP payments begin leaving the bridge account	T10.002
2026-08-09 19:16 → 20:53	94 payments release 199,916 XRP to two newly created wallets; bridge balance falls from ~200,410 XRP to 493.5 XRP	T10.002
2026-08-09 (post-drain)	Bridge halted pending investigation	M34
2026-08-09 onward	TX confirms the incident, attributes it to a relayer-validation flaw with forged deposit information rather than key theft, and files a complaint with the FBI	(operator response)

What defenders observed

Pre-event (the memo field is attacker-controlled input, and it was load-bearing). A memo is free text. Treating its contents as an authenticated statement about custody is equivalent to accepting a self-signed receipt. Any relayer that parses user-supplied metadata should treat every field as hostile and use it only to look up facts, never to establish them (M16).
Pre-event (release on balance, not on event). The prevention-grade control is a locked-versus-issued invariant checked in the withdrawal path: before releasing X, confirm the custody account actually holds at least X more than it did at the last reconciliation point. This would have blocked payment number one, not payment ninety-four (M36).
At-event (94 payments and a reserve that goes to zero is a rate-limiting failure, separately). Even with the verification bug, a per-window withdrawal cap proportional to reserves would have converted a total loss into a partial one and bought most of the 97 minutes back. A bridge that can empty itself inside two hours has no brake, independent of what tripped the accelerator (M11, M38).
Detection (the shape was visible in the reserve balance the whole time). A steady sequence of same-shaped outbound payments against a monotonically falling reserve is one of the most legible signals in bridge monitoring, and it ran for an hour and a half. Watching the custody account balance — not the message queue — is where this class becomes detectable in real time (M39).
Response (halt worked, recovery did not follow). The bridge was stopped and the matter referred to the FBI, but proceeds had already reached two fresh wallets. As in most bridge cases, the post-event levers bound the incident rather than reverse it (M41).
Response (the honest attribution is a design flaw, not an intrusion). TX's framing — relayer validation, forged deposit information, no key theft, no XRPL compromise — is the correct one and is worth preserving because the instinctive reading of "bridge drained" is a stolen key. The distinction changes the entire remediation set.

Public references

[ccncoreum2026] — CCN, "Coreum Bridge Left With Just 493 XRP After 200,000 XRP Exploit" (the 199,916 XRP figure, the fall from ~200,410 XRP to 493.5 XRP, the two newly created recipient wallets, and the relayer-validation framing): https://www.ccn.com/news/crypto/xrp-coreum-bridge-exploit-200000-tokens/
[coineditioncoreum2026] — Coin Edition, "Coreum Bridge Breach Drains 199,916 XRP in 97-Minute Exploit Attack" (the 19:16 → 20:53 UTC window, the 97-minute duration, and the 94 multisig-authorised payments): https://coinedition.com/coreum-bridge-breach-drains-199916-xrp-in-97-minute/
[cryptobriefingcoreum2026] — Crypto Briefing, "Nearly 200,000 XRP drained from Coreum cross-chain bridge exploit" (independent confirmation that the XRP Ledger was not compromised and that no bridge private keys were implicated): https://cryptobriefing.com/coreum-bridge-exploit-xrp-drained/
[livevolatilecoreum2026] — LiveVolatile, "tx (Coreum) XRP Bridge Exploit Explained: How a Relayer Flaw Drained 199,916 XRP" (the mechanism in detail: wrapped-token self-transfers carrying a memo shaped like a genuine deposit, relayers checking success, amount and memo recipient but never confirming XRP receipt): https://www.livevolatile.com/blog/tx-coreum-xrpl-bridge-exploit-relayer-flaw
[xrpltocoreum2026] — XRPL.to Insights, "The Coreum Bridge Released 200,000 XRP. It Wasn't Rippling." (the 94-payment breakdown from the XRPL side and the bridge account's balance trace): https://xrpl.to/insights/coreum-bridge-xrp-drain
[cryptotimesweek0816] — The Crypto Times, "Crypto Whale Loses $25.6M Again as Weekly Hacks Cross $37M" (weekly roundup placing Coreum among the 2026-08-09 → 08-15 incidents and summarising the deposit-verification gap: relayer trusted the memo without confirming the destination): https://www.cryptotimes.io/2026/08/16/crypto-whale-loses-25-6m-again-as-weekly-hacks-cross-37m/
[slowmistzonecoreum2026] — SlowMist Hacked (zone entry, 2026-08-09, Coreum Bridge, $200,000, "Bridge Logic Vulnerability"): https://hacked.slowmist.io/

Discussion

Coreum belongs alongside the July 2026 Across–Solana relayer discriminator forgery and the May 2026 Verus source-amount validation case as part of a cluster OAK is accumulating: bridges whose off-chain observers verified the wrong object. In each, the cryptography held, the signers were honest, and the loss came from a validation routine that examined a claim rather than state. The cluster is worth naming because the mitigation is identical across all of them and is not the mitigation people reach for after a bridge hack. Nobody needed better key management, more signers, or a longer challenge window. They needed one balance read.

The economics here also make a point that larger cases obscure. At roughly $200K, this incident is small enough that it will not appear in most annual loss tables — but the bridge lost 99.75% of its reserve, which is a total loss by every measure that matters to its users. OAK deliberately records the reserve-depletion ratio next to the dollar figure, because "how much was taken" and "how much of what existed was taken" answer different questions, and for infrastructure the second one is usually the more informative.

One further observation for contributors: the attacker's setup required no capital and no privilege — self-transfers of a wrapped token they already held, plus a memo. There was no flash loan, no compromised endpoint, no social engineering, and no exotic cryptography. When a bridge's release logic trusts attacker-authored metadata, the cost of exploitation collapses to the transaction fee, and that is why this class produces near-total reserve loss so reliably: there is nothing to ration the attempt.