← 観測ノート一覧

OBSERVATION NOTE / MDFOOB-HU

CoreumブリッジXRP流出事件―Relayer検証欠陥とクロスチェーンセキュリティの教訓

Coreum--XRPLブリッジのXRP流出について、Relayerの入金検証ロジックと共通原因故障、クロスチェーン設計への教訓を整理します。

Relayer検証欠陥とクロスチェーンセキュリティの教訓

現在日付:2026-08-13 JST

要約

今回の事件は「XRP Ledger(XRPL)が破られた事件」ではなく、XRPL ↔ Coreum間のブリッジが、入金を確認するロジックを誤って実装していたため、存在しないブリッジ入金を本物と認識し、XRPを払い出してしまった事件と理解するのが最も正確である。

報道ベースでは、2026年8月9日にCoreum--XRPLブリッジから199,916.3 XRPが約97分間、94回の取引で流出した。事件前残高約200,410 XRPのほぼ全量である。

重要なのは、攻撃対象がXRPLのコンセンサスや暗号技術ではなく、ブリッジのRelayer(リレイヤー)に存在したsemantic validation(意味論的検証)の欠落だったことである。


1. 何が起きたのか

Coreum Bridgeでは、XRPL上でXRPをブリッジアカウントへ送金し、その入金をRelayerが検知・検証した後、Coreum側で対応する資産を利用できる仕組みが構成されていた。

今回の報道によれば、攻撃者はRelayerソフトウェアの検証上の欠陥を利用し、約20万XRPを流出させた。

レイヤー 今回の状態 評価 --------------------- ------------------------ ------------------------------ XRP Ledger本体 正常 侵害されていない XRPLコンセンサス 正常 問題なし XRP秘密鍵 漏洩確認なし 主因ではない Coreum本体 本件の直接原因ではない ブリッジとは分離して考える Coreum--XRPL Bridge 脆弱性あり 今回の攻撃対象 Relayer 検証ロジック不備 本質的原因 Multisig 正規に署名 「間違った情報を正しく承認」

したがって今回の本質は、

暗号技術が破られたのではなく、業務ロジックが破られた

というタイプのインシデントである。


2. ブリッジは本来どう動くのか

通常は以下のような検証が必要になる。

ユーザー
   │
   │ XRP送金
   ↓
XRPL上のBridge Account
   │
   │ Relayerが確認
   │
   ├─ 本当に送金されたか?
   ├─ DestinationはBridge Accountか?
   ├─ 金額は正しいか?
   └─ Memoは正しいか?
          ↓
Coreum
          ↓
対応するbridged XRPを付与

ところが今回、非常に重要な検証が欠落していたと報じられている。

それが、

XRPLトランザクションのDestinationが本当にBridge Accountなのか

というチェックである。


3. 攻撃者が利用した穴

今回の核心はここにある。

攻撃者は概念的には、次のような状態を作れたと考えられている。

攻撃者Wallet A
       │
       │ XRP
       ↓
攻撃者Wallet B
       │
       │ Memo:
       │ 「Coreumではこのアドレスに」
       ↓
Relayer
       │
       │ 誤認
       ↓
「Bridgeへの入金だ」
       ↓
Coreum側で残高を付与

本来なら、

攻撃者 → Bridge Account

という送金でなければブリッジへのdepositとして認識してはいけない。

ところがRelayerが実質的に、

Transaction exists?       YES
Memo exists?              YES
Transaction valid?        YES

Destination = Bridge?     ← ここが欠落

という状態だった。

その結果、

攻撃者自身のWallet間の送金を「BridgeにXRPが入金された」と誤認

できた。

つまり、XRPL上では実際に存在する正規トランザクションを材料にしながら、そのトランザクションが「ブリッジへの入金」であるという意味付けだけを偽装したことになる。


4. なぜマルチシグが17/28もあったのに防げなかったのか

記事によれば、28リレーキー中17キーが各払い出しを承認した。

一見すると、

「17キーも署名したのになぜ不正送金を防げなかったのか」

という疑問が生じる。

しかし、署名者が判断するために利用している情報そのものが間違っていれば、多数決やマルチシグだけでは安全性を保証できない。

XRPL
 │
 │ transaction
 ↓
Relayer software
 │
 │ ❌ 間違った判定
 ↓
「正規depositです」
 │
 ├─ Relayer 1 → YES
 ├─ Relayer 2 → YES
 ├─ Relayer 3 → YES
 │
 ...
 └─ Relayer 17 → YES
          ↓
      Multisig成立
          ↓
       XRP払い出し

つまり、

17主体が独立した方法で事実を検証したのではなく、同じ欠陥ロジックに依存していた

ことが問題になる。

これはシステム安全性の観点では、

common-mode failure(共通原因故障)

として理解すると分かりやすい。

分散化された署名者が多数存在していても、全員が同一の誤ったソフトウェア判定を信頼していれば、分散化されたまま全員で同じ間違いを承認することがあり得る。


5. 「署名は正しかった」が重要

今回の事件は秘密鍵流出型とは性質が異なる。

単純化すると、

偽造署名
   ↓
X

秘密鍵窃取
   ↓
X

XRPL改ざん
   ↓
X

誤った事実認識
   ↓
○
   ↓
正規署名
   ↓
正規XRP送金

という構造である。

つまりXRPLから見れば、払い出しトランザクションそのものは正規の認証を備えた有効なトランザクションだった。

問題は、

「その払い出しを承認すべき根拠」が誤っていた

ことである。

この区別は非常に重要である。


6. なぜXRPL自体は無傷なのか

今回XRPLは、

「正規に署名されたXRP送金を正しく処理した」

だけである。

Coreum Bridge側から、

このアドレスへ
1,695 XRP送ってください

という正規署名済みTransactionが提出されれば、XRPLはプロトコルのルールに従って処理する。

XRPL自身が、

「そもそもCoreum側でこの払い出しを許可してよかったのか?」

まで判断することはできない。

したがって今回の事件は、XRPL consensus failureではない。

銀行に例えるなら、

銀行間決済ネットワークが破られたのではなく、銀行内部のシステムが架空の請求を正当と判断し、正常な決済ネットワークを使って送金してしまった

という構図に近い。


7. XRPの1ドル割れとの因果関係には注意

記事タイトルでは、

「Coreumブリッジがハッキング、XRPが1ドル割れ」

と並べられている。

しかし、

「約20万XRPが盗まれたためXRP価格が1ドルを割った」

と直接的な因果関係を認定するのは適切ではない。

今回の流出量はXRP市場全体の規模と比較すると小さい。

したがって、XRPの1ドル割れについては、

暗号資産市場全体の弱さ
        +
XRPのテクニカルな$1支持線
        +
デリバティブ市場の需給
        +
Coreum Bridge hackによる心理悪化
              ↓
          $1割れ

という複合要因として考える方が妥当である。

Coreum事件が1ドル割れの主因だったかは確認できない。


8. 「被害額が小さいから大した事件ではない」ではない

今回の被害は約20万XRPであり、過去に発生した数億ドル規模のBridge hackと比較すると金額は小さい。

しかし、技術的には重要な事例である。

理由は、今回の原因が暗号学的安全性ではなく、

semantic validation(意味論的検証)の欠落

だったからである。

コード上、

Transactionが存在する

ことと、

BridgeへのDepositが存在する

ことは同じではない。

今回のソフトウェアは、この2つを実質的に同一視してしまった。

ブリッジ設計では、

「何が起きたか」だけでなく、「誰から誰へ、何の目的で起きたか」まで検証する

必要があることを示した典型例である。


9. Cardanoにも関係する教訓

CardanoのL1セキュリティそのものとは別問題だが、Cardanoが相互運用性を拡大するほど今回の事件は重要な教訓になる。

Cardano
   │
   ├─ Bitcoin bridge
   ├─ Ethereum bridge
   ├─ IBC
   ├─ Midnight
   └─ 他チェーン

このような接続が増加すれば、

  • bridge
  • relayer
  • oracle
  • interoperability middleware

などが新しいattack surfaceになる。

つまり、

L1が堅牢でも、境界部分のソフトウェアが同じ品質でなければ資産は失われる

ということである。

CardanoのようにL1の安全性や形式手法を強く訴求するチェーンほど、将来的には、

「Cardano本体は安全」から「Cardanoへ接続される経路まで安全」へ

セキュリティ評価範囲を広げる必要がある。

DRep・ガバナンスの観点でも、クロスチェーン関連プロジェクトへTreasury資金を投入する場合には、単に「何個のvalidator/relayerが存在するか」だけでは不十分である。

各relayerが何を検証し、その検証実装が本当に独立しているのかまで評価対象にすることが望ましい。


10. Coreum Bridgeで最低限必要と考えられる対策

今回の報道内容から考えると、Destinationチェックを追加するだけではなく、多層防御が望ましい。

対策 重要度 ----------------------------------------- -------- Destination=Bridge Account検証 ★★★★★ Asset / issuer検証 ★★★★★ Amount検証 ★★★★★ Memoとrecipientのbinding ★★★★★ Transaction hash重複防止 ★★★★★ 独立実装Relayer ★★★★☆ Withdrawal rate limit ★★★★☆ 異常検知・自動pause ★★★★★ Bridge reserve監視 ★★★★★ Formal verification / invariant testing ★★★★☆

特に今回、約97分間に94回という規則的な払い出しが続いたとされる。

したがって、未知のコード脆弱性そのものを完全に防げなくても、

短時間にreserveの一定割合以上が流出
            ↓
automatic circuit breaker
            ↓
Bridge PAUSE

という仕組みがあれば、被害上限を制御できる可能性がある。

これはpreventionだけでなくcontainmentを設計するというセキュリティ原則である。


11. 今後の5段階シナリオ

現時点では公式な完全版ポストモーテムが確認できていないため、以下の確率はCGTAによる推定である。

シナリオ 内容 推定確率 ------------- -------------------------------------------------- ---------- S5 最良 完全補填+独立監査+多層検証+自動停止機構を実装 20% S4 被害補填+Destination検証等を修正し再開 40% S3 技術修正して再開するが利用量低迷 25% S2 補填・責任問題が長期化しBridge信用低下 10% S1 最悪 追加脆弱性発覚・再攻撃で事実上Bridge停止 5%

現段階ではS4を中心シナリオと考える。

ただし、正式なpost-mortemが公開されれば評価を更新する必要がある。


12. CGTAの評価

今回の事件を一言で表現するなら、

「XRP Ledgerを破ったのではなく、Coreum Bridgeに"存在しない預金"を信じ込ませた攻撃」

である。

さらに技術的に重要なのは、28キー中17キーによるマルチシグが存在したにもかかわらず防げなかったことである。

これは「分散化すれば安全」という単純な理解が不十分であることを示している。

Consensus
   ↓
正しい情報について合意する
   ↓
安全

Consensus
   ↓
間違った情報について合意する
   ↓
全員で間違える

今回の事件は後者に近い。

したがってクロスチェーン時代のセキュリティでは、

「何人が署名したか」以上に、「署名前に何を、どの独立した方法で検証したか」

が重要になる。

これはCardanoがIBC、Bitcoin DeFi、Midnightなどを含む外部ネットワークとの接続領域を拡大していく際にも適用できる重要な教訓である。


今後確認すべきポイント

正式なpost-mortem公開後には、少なくとも次の点を再評価する必要がある。

  1. Destination検証欠落の正確なコード位置と発生経緯
  2. 既存の監査でなぜ発見されなかったのか
  3. 28 Relayerがどの程度同一実装・同一検証経路に依存していたのか
  4. 被害XRPの追跡状況
  5. 被害補填方針
  6. Bridge再開条件
  7. circuit breakerやrate limitの追加
  8. 独立実装Relayer導入の有無

単なる「1行のチェック漏れ」で終わらせず、なぜ複数の防御層がその欠陥を止められなかったのかを検証することが重要である。


情報源・Fact Check

  • BeInCrypto, Coreum--XRPL Bridge exploit report(2026-08-12)
  • 約199,916 XRPの流出
  • 約97分間・94回の送金
  • RelayerのDestination検証欠落
  • XRPL自体の脆弱性ではないとの整理
  • XRPL / Coreum関連公開資料
  • XRPLとCoreum間のクロスチェーン資産移動・Relayer構造の確認
  • Cross-chain bridge securityに関する既存のセキュリティ研究
  • BridgeがL1とは独立したattack surfaceを形成することの確認
  • ユーザー提示記事
  • BeInCrypto日本語版「Coreumブリッジがハッキング、XRPが1ドル割れ―今年初」
  • Cardano Epoch資料
  • Epoch 649:2026-08-13 06:44:51 JST ~ 2026-08-18 06:44:51 JST

留意事項

  • 公式な完全版post-mortemは本文作成時点で未確認。
  • XRPの1ドル割れとCoreum Bridge事件の直接的因果関係は確認できない。
  • 今後のシナリオ確率はCGTAによる推定であり、公式情報ではない。
  • 正式な技術報告公開後には再評価が必要。

作成:2026-08-13 JST\ BWtake & CGTA