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

共有カードコントラクトの脆弱性が複数のフィンテックへ同時波及——Rain の Solana 実装で Avici 1,685名・Tria 636名に影響

共有カードコントラクトの脆弱性が複数のフィンテックへ同時波及——Rain の Solana 実装で Avici 1,685名・Tria 636名に影響

何が起きたか

Avici は2026年8月28日の告知で、カード発行パートナーである Rain が、ユーザーのカード残高を保持する Solana カードコントラクトのあるバージョンに脆弱性を特定したと開示した。同社によれば、当該コントラクトは既に全プログラムにわたって修正版へアップグレードされ、修正後に追加の不正な活動は観測されていない。影響を受けたのは1,685名、対象残高は50万859ドル（1ドル＝156円換算で約7,813万円。レートは2026年9月3日、Trading Economics の値による）で、全額の返金を表明している。

同じ日に問題を告知した Tria は、9月3日の続報で数値を確定させた。脆弱性は発行パートナー Rain が運用する Solana カードコントラクトにあり、これまでの突合で636名・43万1,945ドル（同レートで約6,738万円）のカード残高が影響を受けたとしている。こちらも全額補填の方針で、Rain およびセキュリティパートナーとの復旧作業を継続中であることを明らかにした。

両社が揃って強調しているのは、資金がどこに置かれていたかによる線引きである。セルフカストディのウォレットに保持されていた残高は影響範囲外だった。ユーザーが Solana 資産でカードにチャージすると、資金はウォレットを離れて別のコントラクトへ移る。脆弱性が触れたのはその移った先だけである。また、カード決済（店頭での支払い）は影響下のプログラムでも継続して動作しており、機能停止が起きたのは出金と残高の整合性の側だったと説明されている。記事時点で、脆弱性の技術的な性質（どのアカウント検証や権限チェックが欠けていたか）は公開されていない。修正が既に配布済みである以上、詳細の非公開は妥当な判断だが、同種の欠陥を自分のコードから探したい開発者にとっては手掛かりが乏しい。

何が本質か——共有コンポーネントという単一障害点

この事案の技術的な要点は、脆弱性の中身よりも影響の広がり方にある。Avici と Tria は別会社であり、それぞれ独自のアプリケーションとブランドを持つ。しかし両社は同じカード発行パートナーの、同じオンチェーンコンポーネントの上に製品を載せていた。結果として、自社のリポジトリを一行も変更していない状態で、同じ日に同じ原因の障害当事者になった。

これは暗号資産に固有の話ではない。決済分野では、BIN スポンサー、プロセッサ、KYCベンダーといった共有依存が古くから存在する。異なるのは、共有部分がオンチェーンのコントラクトである場合、そこに預けられた資金の状態が公開されており、かつ攻撃者にとっても同じコードが複数事業者の資金を同時に守っていることが可視である点である。攻撃対象としての費用対効果が、従来の共有ベンダーより高くなる。

もう一点、責任範囲の設計が明確だったことが被害の限定に効いている。ウォレット残高とカード残高が別のコントラクトに分離されていたため、影響範囲を「チャージ済みの分だけ」と切り出して説明でき、ユーザーも自分が対象かどうかを行動から判断できた。もし単一のプールに両者が混在していれば、同じ脆弱性でも影響範囲の確定に何日もかかっただろう。設計の分離が、事故時の説明可能性という形で価値を生んでいる。

開示されていないことを、どう扱うか

技術者にとって扱いにくいのは、公開情報から再現も自己点検もできない点である。現時点で分かっているのは「Solana 上のカード残高保管コントラクトのあるバージョンに脆弱性があった」「修正版が全プログラムへ適用済み」「追加の不正活動は観測されていない」というレベルまでで、どの検証が欠けていたのかは示されていない。Solana のプログラムで典型的に問題になるのは、渡されたアカウントの所有者プログラムや PDA の導出を検証していない、署名者チェックが抜けている、CPI（クロスプログラム呼び出し）の呼び出し元を信頼している、といったパターンだが、今回がそのいずれかであるという根拠はない。推測で自社の点検項目を作るのは筋が悪い。

代わりに実務で効くのは、影響の広がり方から逆算した確認である。第一に、自社の資金フローで外部パートナーのプログラムに残高が滞留する区間があるか。第二に、その区間に置かれる金額の上限と滞留時間を制御できているか。第三に、パートナー側が脆弱性を修正した際、自社が「修正済みバージョンが適用されたこと」を独立に確認する手段があるか。三つ目は見落とされやすい。プログラムの実行可能データアカウントは更新の履歴を追えるため、パートナーの申告に依存せずにアップグレードの事実を確認できる。

なお、この開示は Solana 周辺で同時期に起きた別の事象——8月20日のRustクレート汚染によるビルドパイプライン汚染懸念——とは独立した事案である。時期が近いために同じ文脈で語られることがあるが、因果関係は確認されていない。

想定される落とし穴

第一に、「自社コードは監査済み」は共有依存には及ばない。監査の対象範囲は通常、自社がデプロイしたプログラムである。パートナーが運用するプログラムのIDが自社の資金フローに現れているなら、それは監査の空白地帯である。

第二に、アップグレード権限の所在が説明できるかが問われる。今回、修正版は「全プログラムにわたってアップグレードされた」と説明されている。裏返せば、パートナー側がユーザー資金を保持するプログラムを差し替える権限を持っていたということである。これは迅速な修正を可能にする一方、同じ権限が悪用または誤用された場合のリスクでもある。事業者側は、自社ユーザーの資金を預けている先のアップグレード権限が誰にあり、タイムロックや多重署名がかかっているかを把握しておく必要がある。

第三に、「決済は動いていた」という事実が、影響なしの根拠として一人歩きしやすい。今回、店頭でのカード決済は影響下のプログラムでも継続していた一方、壊れていたのは出金と残高の整合性である。ユーザー体験上は正常に見える経路が残っていると、社内の障害検知も外部からの通報も遅れる。監視対象を「サービスが使えるか」ではなく「残高の帳簿が合うか」に置いているかどうかが分かれ目になる。

第四に、補填の表明は完了ではない。Tria は突合と補填作業の継続を明言している。ユーザー側の実務としては、返金額が事故前の残高と一致するかの確認が残る。事業者側は、この突合の基準時点（どのブロック・どのスナップショット時点の残高を正とするか）を明示できるかが問われる。

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

  1. 自社が一行も書いていないオンチェーンコンポーネントが、自社ユーザーの資金を保持していることがある。脆弱性の所在がベンダー側でも、ユーザーから見た障害当事者は自社である。ここは監査範囲と契約上の責任範囲がずれやすい領域である。 ［プロダクト側・コントラクト開発者］ 今月中に、自社の資金フローに登場するプログラムIDを列挙し、それぞれについて「誰がデプロイし、誰がアップグレード権限を持ち、直近の監査はいつか」を一覧化する。
  2. 資金の置き場所を用途ごとに分離しておくと、事故時に影響範囲を即座に切り出せる。今回、ウォレット残高とカード残高が別コントラクトだったことが、開示の速さと説明の明確さに直結した。分離は平時のコストだが、事故時の説明可能性という形で回収される。 ［コントラクト開発者］ 次の設計レビューまでに、単一のプールに用途の異なる資金が混在している箇所を洗い出し、分離した場合の影響範囲確定にかかる時間を見積もって比較する。
  3. 迅速な修正を可能にするアップグレード権限は、同時に単一障害点でもある。「すぐ直せる」と「勝手に差し替えられる」は同じ機構の裏表であり、タイムロックや多重署名の有無で性格が変わる。 ［インテグレーター・リスク管理］ 今四半期内に、資金を預けている外部プログラムのアップグレード権限（単独署名か多重署名か、タイムロックの有無）を確認し、条件を満たさない場合の預入上限を社内基準として設定する。

【引用：出典】

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