Qubicで1,404ウォレット流出｜対象環境と新シードへの移行方法

iPhone・iPadのブラウザやMac Safari、2025年7月以前のiOSアプリでシードを作った人は、現在の端末ではなく作成時の環境を確認してください。本件はブロックチェーン中核の突破ではなく、鍵の作り方の弱点を示す資料がそろっています。

Qubicで起きた1,404ウォレット流出の全体像

複数の事故報道と記録によると、不正移動は2026年10月17日23時42分から18日1時26分までのUTC時間帯に集中しました。日本時間では10月18日8時42分から10時26分に当たり、約104分です。この間に1,404ウォレットから合計約2.94兆QUが移動したとされています。

暗号資産事件ではドル換算額が市場価格によって変わります。本件には約130万〜140万ドル相当という推計もありますが、評価時点で数字が動くため、中心となる事実は約2.94兆QUという数量と1,404ウォレットという対象数です。これは最終的に回収不能となった法定通貨額を意味しません。

不正移動は約104分間に集中した

開始から終了までが短いことは、利用者が一人ずつ異変に気づいて対応するだけでは被害を止めにくいことを示します。シード候補を機械的に作り、対応する公開アドレスに残高があるかを調べられるなら、攻撃者は多数のウォレットを連続して狙えます。ただし、候補の具体的な絞り方や使用した計算資源は公開資料だけでは確定していません。

最初の不正移動、運営が異常を認識した時刻、ネットワーク停止を決めた時刻は別です。公開台帳から送金時刻は追えても、運営内部のアラートや判断過程は完全な事後報告がなければ分かりません。時間軸では観測できる送金と運営の説明を分けて読みます。

1,404ウォレットから約2.94兆QUが移動した

ウォレット数は被害者数と必ずしも一致しません。一人が複数ウォレットを使う場合も、共同で管理する場合もあるからです。また、移動した全量が換金されたわけではなく、停止時点では大部分がチェーン上に残ったと報じられました。

事件を追うときは、移動した数量、対象ウォレット、資金の位置、凍結や回収の成否を順に確認します。流出した、追跡できた、凍結した、返還した、は違う段階であり、強い見出しだけから全損または全額回収と判断できません。

影響が疑われるウォレットと利用環境

報道が影響対象として挙げたのは、iPhoneやiPadのブラウザ、MacのSafari、2025年7月以前のiOSアプリで生成されたシードです。重要なのは現在使う端末ではなく、シードを最初に作った環境と時期です。

以前iPhoneで作ったシードを現在Windows版へ読み込んでいても、生成過程は過去のままです。反対に、現在iPhoneを使うだけで、別の安全な環境で作ったすべてのシードが直ちに対象になるとは限りません。端末の種類と鍵が生まれた場所を区別します。

Apple系ブラウザとMac Safariで生成したシード

ブラウザで動くウォレットは、端末やブラウザが提供する機能を通じて乱数を得ます。今回の公式修正差分では、従来のMath.randomによる生成処理が削除され、Web Cryptoのcrypto.getRandomValuesを使う共通関数へ置き換えられました。

ただしApple製品だから乱数が弱いと一般化するのは誤りです。問題は特定ウォレットの特定時期の実装と実行経路であり、Apple製品やSafari全体の暗号機能が破られたことを示す資料ではありません。対象範囲は今後の公式報告で変わる可能性があります。

2025年7月以前のiOSアプリで生成したシード

アプリを後から更新していても、過去に生成し保存したシード文字列は自動で作り直されません。更新によって変わるのは通常、更新後に実行されるコードです。古いシードを新しいアプリへ読み込んでも、生成時の予測困難性は増えません。

生成日が分からない場合は、最初の入金履歴、端末バックアップ、アプリ導入時期など、秘密を外部へ渡さず確認できる記録を使います。シード本文を検索窓、SNS、問い合わせフォームへ入力してはいけません。正規サポートにも完全なシードを共有する必要はありません。秘密情報の扱いは秘密鍵を安全に管理する基本も参照してください。

現在の利用端末ではなく生成時の環境を確認する

確認表には作成年月、使用アプリまたはWebウォレット、端末とブラウザ、現在の残高、新しいシードへの移行状況を記録します。複数シードは一つずつ分け、同じシードを複数端末へ読み込んだ履歴も整理します。記録するのは環境情報であり秘密そのものではありません。

移行で送金するときはアドレス全体とネットワークを照合します。一般的な誤送金対策は暗号資産を安全に送る手順で確認できますが、本件ではQubic公式の復旧案内が優先です。

原因はプロトコル侵害ではなく弱いシード生成

Qubicの資産を動かす秘密情報はシードから導かれます。シードが十分に予測困難なら、公開アドレスや取引履歴を見られても秘密鍵を現実的に推測できないことが安全性の前提です。生成候補が偏ると、見た目は長い文字列でも実際に試す候補を狭められる可能性があります。

公式修正コードは55文字シードを作る従来処理からMath.randomを削除しました。これは公開差分から直接確認できます。一方、攻撃者がブラウザ実装の内部状態をどう再現し、何通り試したかという完全な攻撃手順は調査資料では確定していません。

55文字シードにMath.randomが使われていた

55文字という長さだけを見ると組み合わせが非常に多いように見えます。しかし安全性は最終文字列の長さだけでは決まりません。材料となる乱数を予測できれば、攻撃者は全組み合わせではなく、生成器が出し得る状態や範囲を狙えます。

長いパスワードでも、よくある単語の繰り返しなら見た目ほど強くないのと似ています。暗号鍵では人間が選ぶ規則性だけでなく、プログラムの乱数生成方法が候補空間を実質的に狭めないかを検証しなければなりません。

弱い乱数から秘密鍵が推測される仕組み

一般的な擬似乱数生成器は内部状態から計算で次の値を出します。画面効果やシミュレーションには便利ですが、観測情報や実装特性から状態を絞れる設計は秘密値に向きません。候補シードから公開アドレスを導出し、残高のあるアドレスと一致するかを調べられるなら、候補探索が成立します。

一致するシードを見つければ署名方式を破る必要はありません。正しい秘密情報を持つ者として有効な署名を作れてしまうからです。台帳から見れば署名は有効でも、本来の所有者の意思による送金ではありません。

Qubic中核プロトコルの侵害とは区別する

合意プロトコルの侵害なら、取引確定の規則、検証者の合意、台帳の整合性が破られたかを調べます。本件が示すのはウォレットが秘密を作る入口の問題です。資産移動後にネットワークが停止したことと、ネットワークの暗号方式が最初に破られたことも同義ではありません。

ただし公式ウォレットの問題である以上、利用者への影響は軽くありません。安全な鍵生成はシステムへの信頼の一部です。プロトコル、ウォレット実装、配布経路、緊急対応を別々の層として評価する必要があります。

秘密鍵にMath.randomを使ってはいけない理由

ECMAScript仕様のMath.randomは0以上1未満の数を実装依存のアルゴリズムで返しますが、暗号用途に必要な予測困難性を保証しません。値がばらばらに見えることと、攻撃者が次の値や内部状態を推測できないことは別です。

MDNもMath.randomを暗号用途に使わず、Web Crypto APIのcrypto.getRandomValuesを使うよう説明しています。秘密が一度推測されると、通常のパスワード変更のように簡単に回復できない場合があるためです。

Math.randomは暗号用途の予測困難性を保証しない

通常のPRNGは同じ内部状態なら同じ系列を生成する決定的な仕組みです。それ自体は欠陥ではなく、再現可能なテストやゲームでは望ましい性質です。しかし認証トークン、セッションID、秘密鍵など他者に当てられないことが価値になる用途ではCSPRNGが必要です。

MITREのCWE-338は弱いPRNGの使用を脆弱性として整理し、CWE-337は予測可能な初期シードの危険を区別しています。評価すべきなのは乱数らしい見た目ではなく、攻撃者の視点から予測や再現が困難かどうかです。

CSPRNGとエントロピーが鍵の安全性を支える

CSPRNGは過去の出力を観測しても将来の出力や内部状態を推測しにくいよう設計されます。初期化の材料には十分なエントロピー、つまり攻撃者が事前に知らない不確実性が必要です。時刻、端末名、連番だけのような推定しやすい材料では足りません。

NIST SP 800-90Aは分析済みDRBGの構成を扱い、SP 800-90Bは元になるエントロピー源の設計、検証、健全性試験を扱います。RFC 4086も安全保障用途では予測困難な乱数と十分なエントロピーが不可欠だと説明します。

乱数生成はアルゴリズムだけでなく実装も検証する

安全なAPIを呼んでも、その後の変換で偏りを作ることがあります。一定範囲の数を26文字へ単純な剰余で割り当て、元の範囲が26で割り切れなければ一部の文字が多く選ばれます。修正版が棄却法を使うのはこの偏りを避けるためです。

乱数取得に失敗したとき弱い方法へ自動的に切り替えると、安全性が見えないまま低下します。秘密を安全に作れないなら処理を止めてエラーにする方が安全です。OWASPも鍵をCSPRNGで生成し、漏えいや疑いがある鍵をローテーションする原則を示します。

v4.26.4でシード生成はどう修正されたか

修正PR #294は2026年10月18日にレビューされ、5件のチェック通過後にmainへマージされました。その内容を含む公式ウォレットv4.26.4も同日に公開されています。公開リポジトリにより、発表だけでなく差分と審査履歴を確認できます。

修正の柱はcrypto.getRandomValuesへの置き換え、26文字へ均等に割り当てる棄却法、暗号学的乱数を取得できない場合に処理を失敗させることです。それぞれ乱数源、変換、異常時の安全性を担当します。

crypto.getRandomValuesへの置き換え

Web Crypto仕様はgetRandomValuesに暗号用途へ適する乱数を返すことを求めています。ブラウザ実装はプラットフォーム固有の乱数源などを利用します。アプリ側が時刻や小さな初期値から独自に組み立てるより、検証され広く使われる機能を利用するのが基本です。

ただしAPI名だけで絶対安全とは断定できません。対応環境、呼び出し経路、例外処理、依存関係、配布物とソースコードの一致も確認対象です。公開差分は重要な根拠ですが、運用環境全体の監査報告ではありません。

棄却法で26文字への変換偏りを防止

修正版は得た値を単純な剰余で26文字へ対応させず、均等に割り当てられる範囲だけを採用し、範囲外なら取り直します。これが棄却法です。採用される各値の個数をそろえ、特定文字がわずかに出やすくなる偏りを避けます。

偏りが小さく見えても、大量の秘密を対象に攻撃者が多数候補を調べる場面では不必要な情報を与えない設計が重要です。暗号実装ではおおむね均等ではなく、変換過程が意図した分布を保つかを確認します。

PR承認からv4.26.4公開まで

PRページでは修正内容、レビュー、チェック、マージを追えます。リリースページでは利用者が取得できる版を確認できます。開発ブランチへの修正と配布版の公開は別なので、実際に使う版番号まで確かめます。

SNSのファイルを直接取得せず、Qubic公式サイトから正しいリポジトリとリリースへ進みます。偽の緊急修正版はシード窃取を狙う可能性があります。配布元、版番号、公式が案内する署名やハッシュを確認します。

ネットワーク停止と流出資金の行方

Qubicはtick 85,371,949でネットワークを停止したと報じられています。停止時点で移動分の87.1%はチェーン上に残り、12.9%はMEXCへ送られ、受取口座は約1時間以内に凍結されたと報道されました。

この比率は資金の位置を示す観測であり回収率ではありません。チェーン上に残っても攻撃者が鍵を管理している可能性があり、取引所口座の凍結も所有権確認、捜査、返還が完了したことを意味しません。

tick 85,371,949でネットワークが停止

停止は追加移動を抑える緊急措置になり得ますが、正当な利用者も送金できなくなり、取引所や関連サービスにも影響します。封じ込めと可用性は両立しない場面があるため、停止の根拠、決定権、再開条件、記録の透明性が重要です。

復旧にはComputorの判断や投票が関係すると報じられました。方針確定前に巻き戻し、残高修正、補償が必ず行われるとは断定できません。提案、投票中、決定、実装済みを分けて読みます。

87.1%はチェーン上に残り12.9%はMEXCへ移動

オンチェーンに残る資金は追跡しやすい一方、分割、交換、別チェーンへの移動で回収が複雑になります。中央集権型取引所へ入れば凍結の接点になりますが、法的手続き、管轄、口座名義の確認が残ります。

割合は観測時点で変わり得ます。今後はtickや確認時刻、対象アドレス、数量が添えられているかを見ます。追跡、凍結、差し押さえ、返還は異なる段階で、凍結だけを被害回復と数えてはいけません。

停止と凍結が残した復旧・可用性の論点

停止が被害拡大を抑えた可能性がある一方、誰がどの条件でネットワークを止められるのかというガバナンス上の問いが生まれます。分散型ネットワークでも、緊急調整、ソフトウェア配布、取引所連絡には主要参加者の判断が影響します。

停止までの時間、抑制できた追加流出、正当な取引への影響、再開条件、再発防止を組み合わせて評価します。止められたから安全、止めたから分散していない、という一文だけでは十分ではありません。

Qubic利用者が今確認すべき安全対応

最優先は慌ててシードを入力したり非公式の移行サイトへ接続したりしないことです。確認、救済、返金を口実に秘密情報を求める偽サポートが現れる可能性があります。公式サイトから案内へ進み、検索広告やダイレクトメッセージを起点にしません。

次にシードを生成した時期と環境を確認します。対象の可能性があっても、ネットワーク状態や公式手順を無視した送金は失敗や誤送金につながります。復旧通知と版番号を確認し、問い合わせる場合も秘密を渡さず一般的な手順だけを尋ねます。

アプリ更新だけでは既存シードの強度は変わらない

シードは鍵の根になる固定の秘密です。v4.26.4へ更新しても保存済みの55文字が自動的に別のランダムな文字列へ置き換わるわけではありません。自動で変われば、以前の鍵に対応する資産へアクセスできなくなるからです。

更新には、脆弱な生成コードを今後使わないことと、既存シードのリスクを解消することの二つがあります。後者には安全な新シードを作り、新しいアドレスへ資産を移す鍵ローテーションが必要になり得ますが、時期はネットワーク状態と公式案内に従います。

安全な新シードへの移行要否を確認する

確認は、生成履歴を特定する、Qubic公式経路からv4.26.4以降と復旧情報を見る、対応環境で新しいシードを作る、オフラインのバックアップを検証する、公式移行手順を待つ、送金時に宛先とネットワークを照合する、という順です。利用可能なら少額で着金を確かめます。

新規生成中は画面共有、録画、クリップボード同期など秘密が漏れる経路を避けます。シードの写真を無防備なクラウドへ置きません。ハードウェアウォレットも古い弱いシードを自動で強くはしません。仕組みはハードウェアウォレットの基礎で確認できます。

移行後に古いシードを廃棄する時期は、残高、未処理取引、報酬、復旧方針を確認して判断します。ただし漏えいの疑いがある秘密を再利用したり、新しいウォレットの材料に混ぜたりしません。資産移動を台帳で確認し、必要な記録を残します。

公式URLと復旧通知を確認し偽サポートを避ける

暗号資産詐欺の典型例と同じく、正規サポートがシード、秘密鍵、認証コードを尋ねることはありません。安全性検査のため入力、補償前に手数料を送金、指定アプリで画面共有、という要求は拒否します。SNSの表示名やロゴは模倣できるため認証表示だけで判断しません。

公式URLは既知のQubic公式ページからたどり、GitHubでは組織名、リポジトリ、リリースタグ、コミット履歴を確認します。別のウォレット事故との比較はLedger利用者の資金流出と安全対策も参考になります。今後見るべき更新は、完全な事後報告、影響環境の確定、ネットワーク再開、移行方法、残高処理、凍結資金の返還、補償方針です。予定と完了を区別します。

新しいシードへ移る前に整理したい実務上の注意

新しいシードを作る作業と、古いアドレスから資産を移す作業は分けて考えます。生成時は公式の修正版を使い、第三者に画面を見せず、端末が意図しない遠隔操作や画面共有の対象になっていないか確認します。生成したシードは、アドレスが正しく再現できることを安全な手順で確かめます。確認のためであっても、Web検索や非公式ツールへ入力してはいけません。

新しいアドレスを用意できても、ネットワークが停止中または復旧処理中なら送金できない場合があります。公式が残高修正や移行方法を検討している間に独自操作をすると、その後の案内と食い違う可能性もあります。作成、バックアップ、送金、着金確認の各段階を一度に進めず、どこまで完了したかを記録してください。

新旧バックアップを混同しない

古いシードと新しいシードを同じ無記名の紙やファイルへ並べると、移行後にどちらが現行か分からなくなるおそれがあります。秘密を露出しない範囲で作成日と用途を区別し、バックアップの保管場所も確認します。新しいシードを安全に作っても、その写真を自動同期されるクラウドへ保存したり、平文メールで自分宛てに送ったりすれば別の漏えい経路が生まれます。

複数人や組織で管理するウォレットでは、誰が生成、照合、送金承認、旧バックアップ廃棄を担当するかを決めます。一人の判断だけで秘密を移動させず、手順と承認記録を残すことが誤操作や内部不正の抑制につながります。ただし、完全なシードを議事録や共有チャットへ書くことは避けます。

少額テストでも確認を省かない

少額テストは宛先やネットワークの誤りを早く見つける助けになりますが、テストが成功したから残りを無条件に送ってよいわけではありません。テスト後も宛先が同じか、クリップボードの内容が書き換えられていないか、ウォレットが表示する数量と手数料が正しいかを確認します。送信後はアプリの成功表示だけでなく、公式に案内された方法で台帳上の確定を確認します。

資産を分けて送る回数が増えるほど、手数料と操作回数も増えます。反対に一度に全量を送れば、宛先を誤った場合の影響が大きくなります。どの方法が適切かは残高、ネットワーク状態、公式手順で異なるため、本記事では特定の回数や数量を一律に推奨しません。

復旧・補償に備えて記録を残す

自分のウォレットが影響を受けた可能性がある場合は、秘密情報を含めず、公開アドレス、取引ID、発生時刻、利用していたウォレット版、シードを生成したおおよその時期と環境を記録します。残高画面だけでは後から変化の経緯を追いにくいため、公開台帳で確認できる情報と公式サポートの受付番号を対応させます。

証拠を残すことと、SNSへ公開することは別です。公開アドレスだけでも資産履歴や他の取引との関連を追われることがあります。問い合わせは公式窓口を使い、本人確認として何が必要かを確認します。補償を名乗る第三者へ秘密鍵、シード、二要素認証コード、遠隔操作権限を渡してはいけません。

今後の公式発表で確認したい7つの論点

第一は、影響を受けた版、端末、ブラウザ、生成期間の確定です。第二は、弱いシードを攻撃者がどう探索したかという根本原因です。第三は、修正版がWeb版、デスクトップ版、モバイル版のどこへ配布され、古い版を停止できたかです。

第四は、tick 85,371,949以後の再開条件と実施記録です。第五は、2.94兆QUのうち追跡、凍結、返還された数量です。第六は、利用者残高の処理と補償方針です。第七は、独立したレビューや監査が修正と配布物を検証したかです。

発表を読むときは、Qubic運営の説明、GitHubで確認できるコード、第三者による調査、報道を区別します。一次資料でも自社システムへの説明には当事者性があり、報道も取材時点の情報です。複数の証拠が同じ結論を支えるかを確認します。

利用者向け確認チェックリスト

シードを作った日時と環境を確認したか、公式ウォレットの版と配布元を確認したか、ネットワークが正式に再開したか、公式の移行手順が公開されたか、新しいシードを安全な環境で生成したか、バックアップを他人に見せず復元可能性を確認したかを一つずつ点検します。

送金可能になった場合は、新旧アドレスを混同していないか、正しいネットワークか、クリップボード上の宛先が書き換わっていないか、手数料と数量が意図どおりかを確認します。急ぐことより、取り消せない誤送金を避けることが重要です。

未確定情報を断定しない

公式の完全な事後報告は調査時点で確認できません。被害額の法定通貨換算、全影響環境、攻撃手法、巻き戻し、補償、最終回収率は更新される可能性があります。記事やSNSの日時を確認し、新しい情報が過去の推定を上書きしていないかを見ます。

QUBICの価格変動とセキュリティ事故の事実確認も分けます。価格が上がった、または下がったことは、技術的な修正の完全性や補償可能性を証明しません。本件の理解を売買判断へ直結させず、自身の秘密情報と利用環境の確認を優先します。

まとめ：更新と既存シードの移行は別の課題

Qubicの1,404ウォレット流出では約2.94兆QUが移動し、ネットワーク停止に至りました。公開差分から、公式ウォレットの一部実装で55文字シード生成にMath.randomが使われ、v4.26.4でcrypto.getRandomValuesと棄却法へ改められたことを確認できます。

長いシードでも乱数源が弱ければ安全とは限らず、正しい鍵を推測されればプロトコルを破らず不正送金が成立し得ます。そして更新済みアプリも古いシードの強度は変えません。対象の可能性がある人は生成環境を確認し、公式の復旧・移行案内に従ってください。

復旧、回収、補償には未確定部分があります。本記事は2026年10月20日12時時点の資料に基づき、価格予測やQUBICの売買を推奨しません。新たな一次資料が公開された場合は、確認日時と根拠を示して更新します。