Cabinet
テクノロジーインサイト一覧へ戻る
2026.08.22

TAC、ボンド済みステーキングプールが1トランザクションで空に——供給の28.6%が流出し12日超の停止、上流パッチは3日前に配布済みだった

TAC、ボンド済みステーキングプールが1トランザクションで空に——供給の28.6%が流出し12日超の停止、上流パッチは3日前に配布済みだった

何が起きたか

TAC は2026年8月22日の告知で、Cosmos ベースの EVM 側に影響する脆弱性が悪用されたとして、バリデータと協調した一時停止を数分以内に実施すると通知した。エクスプローラAPIで確認できる最終ブロックは高さ24,671,475、タイムスタンプは同日23時58分11秒（UTC）である。以後、9月4日時点まで正常なブロック生成は再開しておらず、停止は12日を超えている。この間、ブリッジは双方向で停止しており、BNB Chain 上の TAC はネイティブトークンとの償還ができない状態にある。

9月1日に公表されたポストモーテムで、流出額が 2,985,651,403.40 TAC、総供給の28.6%にあたると明らかにされた（比率から逆算すると総供給はおよそ104億3,900万 TAC となる）。TAC の説明では、単一のトランザクションがボンド済みプールをゼロにしたが、トークンの総供給量そのものは変化していない。つまり新規発行ではなく、既存トークンの移動である。結果として、チェーンのデリゲーション記録だけが残り、それを裏づけるトークンが存在しない状態になった。

注目すべきは、監視が正常に機能していたのに検知に至らなかった点である。TAC のブリッジ監視は「ミラーされたトークンに裏づけがあるか」を見る設計だった。今回の窃取はトークンがブリッジに届く前の段階で成立しており、ブリッジ側の不変条件は最後まで満たされていた。大口移転のアラート自体は稼働しており、最初のブリッジ移動はプール枯渇からわずか32秒後に始まっている。にもかかわらずブロック生成の停止は、プールが空になってから4時間以上のちであった。

上流の欠陥と、周知の時系列

上流の Cosmos EVM 勧告は、攻撃経路を2つの残高記録の不整合に帰している。EVM の StateDB はアカウントの使用可能（spendable）トークンのみを追跡していた。一方 Cosmos SDK の台帳は、デリゲートに使えるロック済みのベスティングトークンも保持していた。使用可能額を超える委任を行うと、未チェックの減算が 2^256 に近い巨大な値へラップする。整数のアンダーフローという古典的な欠陥が、2つの状態モデルを橋渡しする層に残っていた形である。

時系列が重い。Cosmos Labs のポストモーテムによれば、この不具合は2026年4月25日にバウンティプログラムへ報告され、5月15日に main ブランチで修正され、8月19日にリリースへバックポートされた。報告から main の修正まで20日、main からリリースへの反映まで96日である。そして8月20日、Push Chain のフォークがこの経路を公に記述し、その2日後の8月22日に TAC が攻撃を受けた。TAC 側は別途、7月に関連する2件の欠陥の分析をメンテナへ送ったが応答がなかったとしている。

ここから読み取れるのは、「修正済み」と「配布済み」と「適用済み」が3つの別の状態だということである。共有モジュールを使う下流チェーンにとって、上流の main ブランチが直ったことは自分の安全を意味しない。さらに、バックポートのリリース公開そのものが攻撃者への告知になる。パッチの差分は脆弱性の場所を示すため、リリースからダウンストリームの適用までの時間差が、そのまま露出期間になる。今回はその窓が3日だった。

TAC は復旧策として、ロールバックではなく状態編集（state edit）を提案している。ボンド済みプールを事故前の残高へ戻し、委任者の記録上のステーキング持ち高を回復させ、停止時点で攻撃者関連アドレスに凍結された6,510万 TAC を除去する。市場に流出した不足分は、財団のトレジャリー準備から約12億5,800万 TAC（流出額の約42%）で補填するとしている。この額は BNB Chain と TON を経由して売却された分に相当し、公開市場の買い手の残高を巻き戻さない限りオンチェーンでは除去できない。攻撃者は BNB Chain 上で 1,208,329,197 TAC を950,293 USDT（1ドル＝156円換算で約1億4,800万円。レートは2026年9月3日、Trading Economics の値による）で売却しており、なお16億6,200万 TAC が攻撃者関連アドレスに残っている。いずれの手順も未完了で、バリデータによるパッチ適用と状態編集の実行、そして再開が必要である。

5月の事案との違いと、状態編集という選択

TAC にとって今回が初めてのインシデントではない。2026年5月11日にはブリッジ侵害が発生しており、5月20日のポストモーテムで、シーケンサのソフトウェアが TON の jetton（トークン）ウォレットのコードハッシュと、その背後にある想定ミンターの双方を検証していなかったと説明されている。偽の入金メッセージが受理され、裏づけのない等価物が TAC 上で発行され、TON 側にロックされていた本物の資産が通常の返却経路で引き出された。プロトコル全体の損失は5月12日時点で約285万4,486ドル（1ドル＝156円換算で約4億4,500万円）とされている。このときは EVM 層が稼働を続けたまま封じ込めが行われており、チェーン全体を止めた今回とは対応の範囲が異なる。

短期間に性質の異なる2つの欠陥が別々の層（ブリッジのメッセージ検証と、EVM／SDK 間の残高整合）で表面化した点は、単一のバグ修正では説明のつかない構造的な問題を示唆する。共通しているのは、いずれも「2つの世界の間で状態を突き合わせる箇所」で起きていることである。

復旧手段としての状態編集には、技術的可否とは別の論点がある。ロールバックは合意された履歴を巻き戻すが、状態編集は履歴を残したまま特定の残高を書き換える。後者のほうが影響範囲を絞れる一方、「誰が、どの残高を、どの根拠で書き換えてよいのか」という正当性の問題が前面に出る。今回、公開市場で TAC を購入した第三者の残高は巻き戻せないため、財団のトレジャリーで穴を埋める設計になっている。これはチェーンの不変性を守るためにオフチェーンの資力を使うという判断であり、財団の準備が尽きた場合に同じ手が使えるとは限らない。

想定される落とし穴

第一に、この事案の教訓は「Cosmos EVM を使っているか」で判定できない。問うべきは、2つ以上の状態モデル（EVM の残高と SDK の残高、L1とL2の残高、オンチェーンとオフチェーンの台帳）を橋渡ししている箇所が自社にあるか、である。不整合はモジュール内部ではなく境界に出る。

第二に、監視が「異常なし」と言い続けることがある。ブリッジ側の裏づけ検査は最後まで満たされていた。監視の不変条件が資産のライフサイクルのどの区間を守っているのかを、明示的に書き出さないとこの穴は見えない。

第三に、停止は封じ込め手段であって解決ではない。TAC は12日以上停止したまま再開日を示せていない。停止中は上場先・ブリッジ・アプリケーションのすべてが凍結され、しかも状態編集の合意形成という、通常のインシデント対応にはない工程が発生する。緊急停止機構を持つ設計を採るなら、停止後に誰がどの手順で再開を決めるかまで含めて事前に定義しておく必要がある。

【技術インサイトとアクション】

  1. 共有モジュールを使う下流チェーンにとって、上流の「修正済み」は防御にならない。main での修正からリリースへのバックポートまで96日、バックポート公開から攻撃まで3日という時系列は、パッチ公開が攻撃者にとっての発見手段でもあることを示している。依存する上流のセキュリティ勧告は、リリース通知ではなくコミット単位で追う必要がある。 ［ノード運用者・プロトコル開発者］ 今週中に、自社チェーンまたはノードが依存する上流リポジトリのセキュリティ勧告・リリース通知を購読し、バックポート公開から自社適用までの目標時間（例：72時間以内）をSLOとして定義する。
  2. 監視の不変条件は、それが守っている区間の外では沈黙する。裏づけ検査型のブリッジ監視は、資産がブリッジに到達する前の窃取を検知できない。 ［インフラ・セキュリティ担当］ 次回の設計レビューまでに、資産のライフサイクル（発行→委任→移転→ブリッジ→償還）を図示し、各区間にどの監視が効いているかを対応づけ、空白区間を洗い出す。
  3. 緊急停止は時間を買う手段であり、再開の手順が定義されていなければ停止そのものが最大のコストになる。状態編集による復旧は、技術的可否よりもバリデータ間の合意形成が律速になる。 ［プロダクト側・運用責任者］ 今四半期内に、依存するチェーンが長期停止した場合の自社サービスの縮退運用手順（入出金停止の判断基準、顧客告知、代替経路）を文書化し、停止が1週間を超えるケースまで想定する。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。