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

cosmos/evm の残高処理欠陥で6チェーンから約572万ドル流出 ― 「サイレントパッチ」から攻撃まで20時間

cosmos/evm の残高処理欠陥で6チェーンから約572万ドル流出 ― 「サイレントパッチ」から攻撃まで20時間

何が起きたか

cosmos/evm は、Cosmos SDK ベースのチェーンが Ethereum 形式のスマートコントラクトを動かすための共有モジュールである。Cosmos Hub 自身は使っていないため影響を受けていない。影響を受けたのは、これを組み込んだ独立チェーン群である。

Cosmos Labs のポストモーテムによれば、攻撃は2026年8月20日 19:06 UTC に始まり、8月25日 15:20 UTC まで続いた。6つのチェーンで悪用が確認されており、うち公開の場で名前が出ているのは MANTRA、TAC、KiiChain の3つで、残る3つは非公表である。

被害額は換金ベースで約572万ドル。分散型取引所での売却がおよそ287万ドル、中央集権型取引所での売却がおよそ285万ドルとされる。前者は2026年8月19日時点の価格に基づき、影響チェーン側から提供された数値で独立監査は受けていないと、ポストモーテムに明記されている。中央集権型取引所のアカウントは当局の調査を待って凍結された。

チェーンごとの内訳は基準が揃っていない。MANTRA はプロジェクト管理下の2ウォレットから 7億2,090万トークン、名目およそ360万ドル相当が動いたとし、ユーザー残高は無事だとしている。KiiChain は同一手法が18回繰り返され 148,326,583.15 KII が流出したと報告し、額面ではおよそ900万ドル相当だが、売却で攻撃者が得たのはおよそ160万ドルと報じられている。名目額と換金額は別の量であり、足し合わせてはならない。

脆弱性は Cosmos Labs によって Critical と評価されているが、CVE 番号も CWE 分類も CVSS スコアも付与されずに公開された。影響バージョンは v0.6.2 未満、および v0.7.0 以上 v0.7.2 未満。修正は8月19日に v0.6.2 と v0.7.2 として公開された。この更新は状態破壊的（state-breaking）であり、協調的なネットワークアップグレードを要する。直ちに更新できない運用者に対しては、ガバナンス提案による協調アップグレードを試みるのではなくチェーンを停止せよ、と案内されている。

攻撃が成立した条件を時系列で

技術的な成立条件は、二つの設計判断の交差点にある。ひとつは、Cosmos SDK 側でアカウントに後からベスティング（段階的解除）属性を付与できること。もうひとつは、EVM 側で残高が bank モジュールとは別の経路でも書かれることである。

KiiChain の報告によれば、攻撃者はコントラクトのデプロイ先アドレスを事前に確定させたうえで、そのアドレスをベスティングアカウントに変換し、後からコントラクトをそこへ配置した。ベスティングアカウントは「保有しているが使えない」残高を持つため、使える残高より 1 wei だけ多く委任する操作が、ミラーされた EVM 側の残高を符号なし整数の下限で回り込ませ、およそ 2^256 という値を生んだ。総供給量は増えておらず、各回の吸い出しは被害者の実残高が上限になる。通常のウォレットは委任できる額が使える残高を超えないため、この経路に到達できない。

言い換えれば、これは「無から資産を生む」型の攻撃ではなく、「一つの残高が二か所に記録され、その二か所が別々に書かれる」設計から生じた不整合である。v0.6.2 と v0.7.2 の変更履歴には、コントラクト生成時に送信者のノンスを進めること、SetAccount がノンスと残高を同時に永続化すること、EVM のコミット経路がモジュールアカウントの残高を書かない場合があること、が並ぶ。修正の形が、原因の形を示している。

ベスティングアカウントが有効になっているすべての cosmos/evm チェーンが同じ露出を持つ、と KiiChain は述べている。MANTRA と TAC が同じ週に同種の攻撃を受けたのはそのためだという主張である。

日程はこうなる。2026年4月25日、バウンティ経由で報告。Cosmos Labs のテスターは既知の本番構成に対して再現できず、稼働中ネットワークの資金にリスクはないと結論づけた。この評価に基づき、影響チェーンへ個別配布するのではなく、セキュリティ上重要と明示しない公開パッチとして処理された。8月上旬、独立研究者の報告ですべての cosmos/evm チェーンが影響を受けると確認される。8月19日、逆解析を避けるため意図的に判別しにくくした形で修正版を公開。リリースノートは「重要なセキュリティ修正を含む」とだけ述べ、変更履歴に当該バックポートを載せていない。8月20日 07:16 UTC、Push Chain のフォークの公開プルリクエストが脆弱性と悪用経路を詳述した状態で公開され、どのリリースタグが脆弱なままかの一覧まで含んでいた。同日 19:06 UTC、最初の攻撃。

同種事例との比較と、設計上の一般化

この事案が個別のバグ以上の意味を持つのは、開示プロセスの設計が争点になっているからである。

MANTRA はポストモーテムで、20時間は現実的な猶予ではないと述べている。38の独立したバリデータに対して状態破壊的なアップグレードを評価・ビルド・テスト・調整するには、脆弱性固有の告知なしでは足りない、という主張である。同社は保守側にこの遅延を正式に提起し、より明確な開示慣行とバックポート期待値の明文化を求めた。KiiChain は、パッチ自体より指示のほうが重要だったと述べる。パッチの展開には数日かかるが、停止は数分で済む、という理屈である。

Cosmos Labs 側の言い分も記録されている。同社はポストモーテムで、過去13か月に37件の脆弱性をサイレントに修正してきたが、下流の開発者が悪用経路を公開の場で詳述したことはなかったと述べている。ただし、パッチ公開が8月19日、公開記述が8月20日 07:16 UTC、最初の攻撃が同日 19:06 UTC という順序は変わらない。

一般化するとこうなる。サイレントパッチは、その依存を使う実装が少なく、更新が非破壊的で、更新に要する時間が短いときに機能する。cosmos/evm はこの三条件をどれも満たしていない。Cosmos エコシステムには115以上の公開チェーンがあり、Cosmos Labs 自身が完全な登録簿を持たない。今回の対応の過程で、把握されていなかった cosmos/evm の導入が11件見つかっている。更新は状態破壊的で、バリデータ集合の協調が要る。この条件下では、パッチの公開は防御ではなく逆解析の起点になりうる。

なお、対応自体は無効ではなかった。Cosmos Labs は40チェーンと連携し、13ネットワークは攻撃前にパッチ適用または停止を完了している。失われたのは、連携を始めるタイミングだった。

想定される落とし穴

第一に、脆弱性は共有モジュール側にあり、各チェーンのコードにはない。自社のコードベースを監査しても検出できない。KiiChain も、脆弱性は自社ではなく無改変で動かしている共有モジュールにあると明言している。無改変で使っているという事実は、免責ではなく露出の説明である。

第二に、KiiChain の報告によれば、三つの根本欠陥のうち二つは上流で未修正のままである。v0.6.2 / v0.7.2 への更新は必要条件であって十分条件ではない可能性がある。更新済みという状態を、対応完了と読み替えないほうがよい。

第三に、リリースノートに「重要なセキュリティ修正」とだけ書かれ、変更履歴に該当プルリクエストが載っていないケースは例外ではない。37件という同社自身の数字がそれを示している。依存ライブラリの更新判断を変更履歴の内容だけで行う運用は、構造的に取りこぼす。

第四に、緊急時にガバナンス提案経由の協調アップグレードを前提にした設計は、この種の事案では間に合わない。Cosmos Labs 自身が、直ちに更新できないなら提案ではなく停止せよと案内している。停止手順が未整備のチェーンは、選べる選択肢がひとつ少ない。

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

  1. 共有モジュールの脆弱性は、下流の実装数・更新の破壊性・更新所要時間の三つが揃うと、「修正の公開」が「攻撃の起点」に反転する。サイレントパッチが機能するのは、この三条件がいずれも小さいときだけである。自社が無改変で使っている依存ライブラリは、監査対象から外れやすいうえに、上流の開示ポリシー次第でこの反転に巻き込まれる。 ［プラットフォーム／インフラ責任者］ 9月中に、本番で無改変利用している外部依存を列挙し、それぞれについて「上流はセキュリティ修正を私的配布するのか公開パッチにするのか」「セキュリティアドバイザリを別途出すのか」を確認し、出さない依存を高リスクとして分類する。
  2. 残高のような単一の値が二つの表現で保持され、それぞれ別の書き込み経路を持つ設計は、片方だけが更新される状態を必ず作りうる。今回の修正が「ノンスと残高を同時に永続化する」形になったのは、その一貫性を書き込み単位で保証する必要があったからである。EVM 互換レイヤーを別のステートマシンの上に載せている実装は、すべて同じ構造を抱えている。 ［プロトコル／コントラクト開発者］ 自社スタックで同一の値が複数の表現を持つ箇所（残高、ノンス、権限フラグ）を洗い出し、書き込みが原子的に行われているか、片側だけが更新されうる経路がないかを、次の定例リリースまでにレビューする。
  3. セキュリティ告知のない更新に対しては、リリースノートの文言以上の情報を得られない。したがって、更新判断の速度は「告知の質」ではなく「自社の停止・更新に要する時間」でしか改善できない。20時間で状態破壊的アップグレードを回せる体制があれば結果は変わっていた。 ［ノード運用者・バリデータ］ 緊急停止と状態破壊的アップグレードの所要時間を実測し、24時間以内に完了できない場合は、ガバナンス提案を経ない緊急停止手順を先に整備して、バリデータ集合と合意しておく。

【引用：出典】

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