BloomのSolana(SOL)ウォレットから9,408 SOL流出、94秒の署名侵害で48ウォレットが被害

94秒で48ウォレットから資金流出

Solana (SOL)上で動く自動売買サービスBloomの署名経路に10月26日(月曜日)の早朝、異常が発生した。オンチェーンデータによると、同日01:03から01:04(UTC)の間に、サービスに接続していた48の暗号資産ウォレットから外部アドレスへ合計9,408 SOLが送金された。最初の送金から最後の送金まで、流出全体の所要時間は約94秒。流出したウォレットはすべて、サービスの利用者9人のいずれかに紐づいており、手数料の支払い履歴からBloom関連のウォレットと特定された。

取引自体は目立つ特徴のないものだった。Solanaのメインネット上の通常のSOL送金で、各ウォレットの所有者鍵そのもので署名が行われている。回避すべき承認ステップも、偽造すべき追加署名も存在しなかった。つまり署名を作った者は、正規の所有者と完全に同じ権限で資金を動かせた。このため、サービス内部の管理の問題よりも「誰が鍵に触れたのか」というアクセス経路の問題が先に立つ。Bloomは出金先アドレスのロック機能を備え、解除後もアドレス変更まで24時間の待機期間を設けている。アカウント乗っ取りや慌てた出金改変に対しては有効な防壁だ。だが、サービス外の第三者が秘密鍵で直接署名できる段階では、ほぼ意味を持たない。Solanaのネットワーク自体は侵害されておらず、障害は送金を処理したチェーンではなく、一サービスの鍵管理にあった。

Solana(SOL)の価格は本件では副次的な要素だ。動いたのは市場全体ではなく、ユーザー残高から流出した9,408 SOLである。今回の件は、AIトレーディングボット型のサービスがユーザー資金に対してどのように署名権限を保持するのかという問題に、改めて視線を向けさせた。多数のウォレットの上に常時の署名権限を集中させる仕組みは、まさに今回顕在化したリスクを構造的に抱え込む形になる。

48ウォレットのうち24は休止状態

事件を単発の窃盗で済ませられない理由は、被害ウォレットの使われ方にある。オンチェーン上の分析では、48ウォレットのうち24が発生前の1か月間、Bloomの取引手数料を一度も支払っていなかった。さらに5ウォレットは、2025年1月から5月の間が最後の手数料支払いという。ボットの利用を数か月前にやめたユーザーまで資金を失ったのは、ウォレットがサービス側の署名の取り決めを保持し続けていたからだ。自動売買サービスの利用をやめるだけでは露出は消えず、鍵を差し替えるまで署名権限は残る。

Bloomの説明は、単純な鍵の流出とは異なる。同社は10月26日、秘密鍵がコピーされたとする見方を否定し、原因を外部モジュールのリモートコード実行の脆弱性だと主張した。これは攻撃者が署名を実行する環境で任意のコードを走らせられる類の欠陥だ。鍵が実際に複製されたのか、署名権限を持つシステムが悪用されたのか、会社の声明とオンチェーンの記録だけでは判定がつかないまま残っている。

金銭的な面は、少なくとも一応の決着がついた。Bloomは発生日当日、被害を受けた9人の利用者全員に対し、流出した9,408 Solana (SOL)全額を補填した。この支払いは運営者による任意の対応であって、DeFi保険の請求ではない。今後の運営者に同じ対応の義務を課す規則も存在しない。補填の下で開いたままなのは、攻撃者が署名権限をどの経路で手に入れたのかという根本の問いだ。

事後検証が残した未解明点

見極めるべきは、同じ設計が持つ波及範囲だ。出金ロックも24時間の待機期間も、アカウント単位のミスや焦った変更を止めるための装置であって、所有者として既に署名できる者を制約する力はない。したがってこの障害クラスは、休止中のウォレットを含め、ユーザーウォレットの上に恒常的な署名権限を保持するあらゆる運用に当てはまり、鍵がローテーションされるまで続く。Bloomのモジュール脆弱性の説明はチーム自身の事後検証であって独立した検証結果ではないため、未確認のアクセス経路こそ注視すべき事実だ。もし署名素材が漏えていた場合、再犯を防ぐには残高を新しい鍵で管理するウォレットへ移す必要がある。その受け皿の一つが、Tangem Mobile Walletのようなセルフカストディ型のハードウェアウォレットであり、コールドウォレットへの移行が終わるまで、サービスに置かれた休止残高は常時のリスクを抱えたままになる。