NEAR Intentsが2026年10月1日にBNB Chainで約380万USDTの脆弱性を公開
NEAR Intentsは、2026年10月1日にBNB Chain上で約380万USDTの流出事件を発表し、その原因はOmni預託と引き出しインフラストラクチャとNEAR Intentsスマートコントラクトとの相互作用にあるバグに起因すると特定しました。
この事件は、NEAR Intentsのクロスチェーン層に影響を及ぼしたものであり、NEAR Protocolのレイヤー1そのものではありません。NEARはネットワークがダウンタイムなしにブロックを生成し続け、取引処理を行っていた一方で、NEAR Intentsはサービス停止とコントラクト側の脆弱性修正を実施しました。正確なバグの種類や発生したコンポーネントは2026年10月2日時点では公開されていませんが、入手できる情報からは、ブリッジアカウンティングと引き出し承認の境界に関する深刻な問題であることが示唆されています。
重要ポイント： NEAR Intentsの約380万USDTの流出事件は、「ブリッジのセキュリティは、すべての資産解放が他の接続されたチェーンでの実在かつ未消費の入金または引き落としに対応している証明が必要である」ことの重要性を示しています。修正済みのスマートコントラクトは必要ですが、守るべき防御範囲はリレイヤー、ブリッジインフラ、署名コントロール、照合ロジックまで及びます。
NEAR Intentsの流出事件の概要
NEAR Intentsは、攻撃者がOmni預託と引き出しインフラとNEAR Intentsスマートコントラクト間のバグを突いてBNB Chainの約380万USDTを流出させました。この資金流出はパブリック公開前に確認でき、NEAR Intentsはサービスを停止し、コントラクトの脆弱性を修正、影響を受けたユーザーには全額補償すると発表しました。
オンチェーン活動からは、9月30日の米東部標準時間の午後に、10 USDTと11 USDTの小規模な送金が漏洩したコントラクトに到達したことが確認されており、この段階は、攻撃者が次に大きな資金を引き抜く前に検証段階として行っていたと考えられます。
その後、9月30日23:54UTCから10月1日06:08UTCにかけて、合計5回の大きな送金が行われ、それぞれおよそ3万5千ドルから150万ドルの範囲だったと推定されます。セキュリティ分析ではBNB Smart Chainのホットウォレットから約3.865百万ドルの損失と算定され、別のオンチェーン追跡では漏洩コントラクトから約3.87百万USDTが収集されたことが明らかになっています。
NEAR Intentsは、10月1日12:53UTCころに公開でこの脆弱性を明かし、「異常な活動を検知したSHIELDによりサービス停止」とし、約1時間以内にコントラクトの修正を完了しました。11のネットワークの預託・引き出しはインフラ修復まで約12時間続き、利用できない見込みです。
| 事件段階 | 日付または時間 | 具体的なイベント | セキュリティ上の重要性 |
|---|---|---|---|
| 初期調査 | 9月30日、午後（米東部時間） | 10 USDTと11 USDTが漏洩コントラクトから発信 | 小規模の送金でエクスプロイトの可能性を検証できる |
| 大規模流出開始 | 9月30日23:54UTC | 5つの大規模送金が開始 | 侵害は検証段階から抽出段階へと進行した |
| 大規模流出終了 | 10月1日06:08UTC | 5つ目の大規模送金完了 | 取り出し期間は数時間に及ぶ |
| 公開発表 | 10月1日12:53UTC頃 | NEAR Intents がサービス停止とバグを公開 | オンチェーン流出の後に事象を説明 |
| 返金期限通知 | 10月2日00:18UTC | 48時間以内に資金返還を呼びかけ | 期限は10月4日00:18UTCまで設定 |
公開された被害資産はBNB Chain上のUSDTでした。その範囲の重要性は、アプリケーションとブリッジインフラの事故と、NEARの核となるネットワークのハッキングや全資産喪失の事故とを区別する点にあります。
NEAR Intentsは約35のブロックチェーンを跨いで300億ドル超を処理し、2023年9月22日時点で総取引量は314億ドル超のダッシュボードも公開しています。これほどの規模のシステムには、安全なスマートコントラクトだけではなく、チェーン間の状態整合性、ブリッジ運用、決済コントラクト、監視システム、運用停止手順などが求められます。
NEAR Intentsは通常、資産をどのように移動させているのか
NEAR Intentsは、intents.near検証コントラクトを通じて、ユーザ指向のクロスチェーン結果を決済します。これにより、預託トークンの残高を記録し、スワップ発生時に記録を更新、引き出しやブリッジ経由でだけ資産を解放します。この仕組みは、預託と引き出しインフラと決済層との境界における脆弱性を含みます。
ユーザは、NEAR Intentsに対して直接的に実行ステップを指定するのではなく、最終的な結果に署名します。解決者とマーケットメイカーは、その結果を実現してオンチェーンに settle させるために競合します。このモデルはクロスチェーンの実行性を向上させますが、その反面、信頼と検証の範囲が拡大します：決済台帳は、何が預託されたか、何が交換されたか、何を引き出すことができるかを正確に認識する必要があります。
NEAR Intentsのドキュメントには、異なる信頼モデルを持つ3つのブリッジシステムが示されており、それらは以下の通りです。
- Omni Bridge（Near One運営）
- POA Bridge
- HOT Bridge
特に、事件分析に重要なのはHOT Bridgeの設計です。公開分析によって、漏洩したBNB Chainのコントラクトは、NEAR Intentsのドキュメントに記載されたHOT Bridgeの財務管理アドレスであり、主要なNEAR Intentsの金庫ではなかったことが判明しました。ただし、これは分析結果であり、最終的な根本原因の正式認定ではありません。NEAR Intentsは10月2日時点でどのコンポーネントが失敗したかの確定をしていません。
HOT Bridgeの設計では、各サポートされるチェーン上のロッカコントラクトがネイティブ資産を管理し、NEARのコントラクトが対応するomniトークンをと一対一でミントします。バリデータのMPC署名が預託と引き出しを認証し、各ノンスは一度だけ使用される設計です。
このアーキテクチャには、以下のセキュリティ特性が絶対的に求められます。
- BNB Chainのリリースは、実在のロックやデビットに対応する必要がある
- 預託メッセージは再再生できないこと
- 署名者の承認は正確なチェーン、資産、受取人、金額、ノンスに bound されていること
- 引き出しリクエストは外部の主張だけで承認されてはならない
- 財務管理アドレスのバランスは常に台帳と監査されたブリッジ状態と一致させる必要がある
私たちSokenの監査経験によると、最も危険なブリッジの故障はシステム境界において発生します。コントラクトはローカルのルールを正しく強制しつつも、上流のメッセージやオフチェーンのサービス、クロスチェーンの帳簿前提を十分な独立検証なしに受け入れることで資産をリリースしてしまうことがあるのです。
NEAR Intentsのドキュメントに記載された11ネットワークの停止リストは、HOT Bridgeのチェーンリストと一致しています：BNB Chain、Polygon、TON、Optimism、Avalanche、Stellar、Monad、X Layer、ADI、Scroll、Plasma。Ethereum、Base、Arbitrum、Solana、Bitcoinは停止されていません。これらの一致するチェーンリストは、HOT Bridgeに特化した仮説を支援しますが、脆弱なコンポーネントを確定するわけではありません。
バグの詳細、未解明の部分
NEAR Intentsは、Omni預託と引き出しインフラとNEAR Intentsコントラクト間の相互作用に脆弱性が存在したことを確認していますが、2026年10月2日時点でどの具体的なコンポーネントや脆弱性タイプかは公表していません。署名バイパスやリプレイ脆弱性、帳簿エラー、バリデータの妥協といった説明は証拠の範囲を超えた憶測に過ぎません。
重要なポイントは、「相互作用」という表現にあります。これは、単純なコントラクト関数のコードミスだけでなく、クロスチェーンシステムが複数の合理적인コンポーネント間で状態の意味性や最終性、一意性について意見の食い違いが生じた場合に失敗することを示唆しています。
例えば、ブリッジのリリース経路は、オフチェーンコンポーネントが未最終の承認を出す、コントラクトが永続的に消費されていない引き出しメッセージを受諾する、帳簿レイヤーが実際に受領していない資産をクレジットするなどの状況により失敗することがあります。これらは技術的な仕組みは異なりますが、共通点は「資産が、正当なロックまたはデビットに対応しないままリリースされてしまう」セキュリティ失敗です。
NEAR Intentsの事象は、主要なブリッジ事故の一般的なパターンと類似していますが、詳細な状況は異なっています。
| 事件 | 日付 | 被害額 | 失敗の明確な形態 |
|---|---|---|---|
| Wormhole | 2022年2月 | 約3.25億ドル | 署名検証のバグにより、ガーディアン承認の偽造と120,000wETHの無担保発行 |
| Nomad | 2022年8月 | 約1.9億ドル | 信頼できるルートをゼロに設定し、全メッセージを証明済みと扱う |
| Kelp DAO over LayerZero | 2026年4月 | 約2.92〜2.93億ドル | 1対1の検証器設定により、Ethereum上でのファントムバーンを許容 |
| Liquid Network | 2026年9月6日 | 約3.2億ドル | 範囲証明検証キャッシュのバグによる未担保のL-BTCの連動失敗 |
| NEAR Intents | 2026年10月1日 | 約380万ドル | Omni預託・引き出しインフラとNEAR Intentsコントラクトの脆弱性 |
これらの事故の共通点は、「信頼できるロックやデビットに対応しない信用、証明、メッセージを橋が受け入れたこと」にあります。NEAR Intentsについては、その当該脆弱性の具体的な仕組みは未検証ですが、ブリッジや財務管理アドレスの性質から、このパターンが最も妥当な仮説となります。
Ronin Bridgeは対照例です。2022年3月のRonin事件は、9つの検証キーのうち5つの破損によるものであり、これは本質的には鍵管理と検証者閾値の問題です。これに対し、コントラクトが無担保のクレジットを不正に正当化したケースではありません。
NEAR Intentsは、正式な検証導入を約束しています。ブリッジの不変条件をエンコードし、例えば「有効な引き出しはユーザの決済済み権利を超過しない」「引き出しメッセージは二重実行されない」「集約リリースは検証済みの裏付けを超えない」といった安全性を担保するためです。
同様のインフラを設計する場合、技術的セキュリティレビュは、各コントラクト、サービス、署名者の領域を個別の安全境界と見なすのではなく、「預託からリリースまでのライフサイクル全体」を検証することが推奨されます。
対応と封じ込めの決定が重要だった理由
NEAR Intentsは、SHIELDによる異常活動検知後にサービスを停止し、コントラクト側の脆弱性を約1時間で修正、11の影響ネットワークで預託・引き出しを一時停止する迅速な封じ込めを行い、被害拡大を防ぎました。この迅速な対応により、さらなる資金流出や被害の拡大は抑えられましたが、完全な回復には追跡調査や法的措置、修正された安全性を満たす証明が必要です。
まず、異常活動を検知した段階でサービス停止したのは適切な判断です。クロスチェーンの引き出し経路が未最終の資産解放を生む可能性がある場合に運用を続けると、限定的な攻撃がより広範な財務喪失となるリスクを伴います。したがって、ブリッジの一時停止は、詳細かつ事前にリハーサルされた制御と観測性が必要です。
NEAR Intentsは、警察やセキュリティ・ブロックチェーン分析と連携し、資金追跡や回収の取り組みを進めています。公開情報によると、盗まれた資金はKuCoinに送金され、Bitcoinにブリッジされた事例もあります。別途追跡調査では、約150万USDTがCoW Protocolの決済コントラクトを通じて動いていることも判明しています。
また、資金返還のために、NEARの共同創設者Illia Polosukhinは、攻撃者に48時間の返金期限を設け、Bitcoin、BNB Chain、Solanaに返金先を公開し、報奨金についての明確な表明は出していません。2023年10月2日時点では、返金や返済の報告はありません。
補償のコミットメントも重要です。NEARの共同創設者のIllia Polosukhinは、「全ての被害ユーザに補償を約束」という声明を出しています。このコミットメントは、顧客への影響を抑える狙いですが、技術的には、被害からの早期復旧とともに、正確な事後報告と再発防止策の公表が求められます。
理想的な事後対応パッケージには、次の内容が含まれるべきです。
- 正確な脆弱性コンポーネントとバグの種類の特定
- 脆弱性を除去するためのコントラクトとインフラの変更内容
- メッセージ、ノンス、台帳、署名、整合性に関わる不整合の有無
- 修復のための独立監査結果
- それぞれのチェーンごとに復旧計画
- 同様の異常引き出しを早期に検知できる監視ルール
また、技術以外の観点では、返金アドレスの公開、資金追跡、取引所との調整、ユーザーへの補償、法執行機関への通報などは、法的・開示上の判断を伴います。ブリッジ回復策を策定するチームは、法的・コンプライアンス支援と連携すべきです。
クロスチェーンチームはNEAR Intents事件後に何を変える必要があるか
クロスチェーンチームは、すべてのブリッジ引き出しを「価値保存証明」として扱うべきです：リリースは、検証済みのロックやデビット、あるいは一意なメッセージと特定の宛先、そして上限金額に紐付く必要があります。NEAR Intentsの事件は、監視と緊急停止の重要性を示しますが、それを防止する最も効果的な手法は、「無効なクロスコンポーネント状態の承認を不可能にする」ことです。
最初のエンジニアリング目的は、ブリッジのコア不変条件をビジネスと技術の観点で定義することです。HOT Bridgeのようなシステムでは、不変条件は「この引き出しは一度だけ承認されるもので、対応する最終化済みかつ未使用の預入や帳簿のデビットに基づき、正当化される」というものです。
この不変条件は、以下の失敗シナリオで検証される必要があります。
- 重複メッセージやノンスの再利用
- チェーンIDの不一致
- トークンアドレスや小数点の不一致
- 古くなった署名者承認
- 部分的なインフラの停止
- 盤簿とロッカの残高の不一致
- 緊急停止フェーズの遷移
- アップグレードやコントラクト移行後のリプレイ試行
次に、検知と信頼の分離も重要です。NEAR Intentsの事例では、SHIELDが異常を検知しましたが、監視だけでは帳簿誤差による資金損失を防げません。コントラクトとブリッジの検証ルールは、不正な資産移動を許可する前に拒否すべきです。
また、資産の照合作業を行い、ソースチェーンのロック、決済帳簿のクレジット、宛先チェーンでのリリース、未処理の引き出し承認を比較し、不一致があれば自動的に範囲を制限したり、そのルートを停止したりすべきです。特にホットウォレットや財務管理ルートでは、この制御が不可欠です。
さらに、形式的検証は、「資産預託、ソルバー決済、ブリッジメッセージ作成、引き出し実行」などの重要な性質に焦点を当てるべきです。少なくとも、一つのコントラクト関数に対する形式的証明だけでは不十分で、外部インフラから許容できない誤った前提が入力されるのを防ぐ必要があります。
Sokenの調査拠点は、スマートコントラクトやプロトコルの継続的な失敗パターンや、ローカルチェックとシステム全体のセキュリティ保証の違いも検討しています。ブリッジチームにとっては、監査範囲に含めるべきポイントは次の通りです。
- コントラクトとメッセージ形式
- 署名者のポリシー
- 運用コントロール
- 監視Telemetry
- 回復手順
NEAR Intentsは、事後分析を「検証可能な復旧計画」に転換し、「相互作用の不具合箇所の特定」「修復された経路が未担保USDTをリリースできない理由」「すべてのHOT Bridgeルートの再検証」を目指す必要があります。導入予定の検証手法は、各引き出し承認をその基盤となるロックまたはデビットにリンクさせ、それがリトライや遅延、アップグレード、悪意のあるメッセージの順序変更に耐えて生存できるかをテストすべきです。