Rejetto HFS CVE-2026-61500推測できる署名鍵、公開後すぐ悪用

概要

• Horizon3のZach Hanleyは、Anthropicの脆弱性研究向けモデル Mythos（Project Glasswing）を使い、HFS 3.xのセッション署名に Math.random()（V8の xorshift128+）が使われ、かつログイン処理が同じPRNGの生出力をCookie経由で漏らすことを突き止めた。鍵を復元して管理者セッションを偽造し、組み込みの管理機能で任意コード実行まで実証した、と2026-09-30に公表した。
• 修正そのものは 2026-07-13 の 3.2.1 で出荷済み。しかし詳細と検証材料が秋に公開された直後、2026-10-01夕からVulnCheckのセンサーが実在の脆弱ホスト向け悪用を検知。対象に米国と日本のホストが含まれ、翌2日も米プロキシ疑いのIPから追加ヒットがあった（The Register、2026-10-03）。
• HFSは過去にもKEV入り（CVE-2024-23692等）した実績がある「手軽な公開ファイルサーバ」であり、パッチ適用遅れがそのままスキャン対象になる典型例でもある。

この記事では、ベンダー・公的機関・研究者・報道で確認できた内容を「事実」、筆者の推測や意見を「考察」として分けて書いています。再現用の手順やソルバー入力は書きません。

何が起きたか（時系列）

CISAのKEVに本CVEが入ったかは、2026-10-03時点の報道では未掲載とされている。VulnCheck独自のKEVには載せた、との整理がある。

技術的な問題点（根本原因）

事実（Horizon3 / NVD整理 / 修正差分の報道）

• COOKIE_SIGN_KEYS 未設定時、Koaの keygrip 用キーが randomId(30) になり、内部で Math.random() を複数回消費して文字列化する。
• ログインの初期ハンドシェイクで Math.random() の値がセッションCookie（署名はあるが暗号化ではない base64 JSON）に入り、クライアントが同じPRNG系列の出力を読める。
• V8の Math.random() は xorshift128+ ベースで、十分な連続観測があれば内部状態の復元が学術的・ツール的に知られている。MDNもセキュリティ用途への使用を明示的に否定。
• 管理者セッションを偽造できれば、HFSの管理API（カスタムエンドポイントでJavaScript実行など）へ到達し、RCEになる、というのがHorizon3の実証結果の要約。
• 修正は「観測可能な Math.random() から再構成できない乱数」へ鍵生成を切り替えたこと、およびログイン側も randomUUID() へ変更したこと。

考察

個々の部品（弱いPRNG、Cookieへのsid格納、管理APIの強力なスクリプト実行）はどれも「あるある」だが、漏洩した観測値と起動時キー生成が同一ストリームであることまでつなぐと、認証回避が現実の攻撃手数に落ちる。Mythosの話の核心は「脆弱性クラスの新規発明」より、数学的に面倒な連鎖を人が諦めやすいところで自動化した点にある、というHorizon3の自己評価は、防御側には「Math.random() を鍵やトークンに使っていないか」の機械的監査を優先せよ、という教訓に翻訳できる。パッチから公開まで約11週間空いていたのに、詳細公開の翌日にセンサーが鳴った事実は、未更新ホストのインターネット露出がまだ残っていたことも示す。

攻撃・侵入経路

flowchart TD
    A[未認証の攻撃者] -->|ユーザー列挙等| B[admin等の存在確認]
    B -->|ログイン初期処理| C[同一PRNG出力の観測]
    C --> D[署名鍵の復元<br/>非暗号PRNGの性質]
    D --> E[管理者セッションCookie偽造]
    E --> F[管理API / server_code 等]
    F --> G[ホスト上でのコード実行]

事実（Horizon3 / VulnCheck報道）

• 悪用観測は「脆弱ホストへの到達試行」が中心で、本番侵害の確定件数は公開されていない。
• 探索元は当初中国ホスト1IP、その後米同一サブネットの2IP（プロキシ疑い）。対象に日本のホストが含まれる。

防御記事の範囲を超えるソルバー手順・リクエスト列は記載しない。公開PoCの存在自体は報道で確認できる。

なぜ防げなかったか・構造的要因の考察

ここからは筆者の考察である。

1. 「簡単公開」ソフトウェアの長期放置: HFSは手軽さゆえにホーム／中小／一時共有でインターネットに残りやすく、7月の静かなパッチが届かない。
2. セキュリティ用途への Math.random(): 言語ランタイムが長年警告してきた用法が、フレームワークの「デフォルトの便利な乱数」経由で本番鍵になる。
3. 詳細公開がスキャンのトリガ: 修正済みでも、書きぶりとPoCが出た瞬間にインターネット全体が再スキャンされる。パッチ適用のSLAを「リリース日」ではなく「悪用可能性の公開日」でも測る必要がある。
4. AI発見CVEの運用: Mythos関連CVEの実害率はまだ低い、という第三者トラッカーの見方もある。一方で「数学的に重いが影響がクリティカル」なクラスが現実のKEV候補になる速度は上がり得る。

運用者向けの具体的な対策と検知ポイント

対策

• 3.2.1以上へ更新し、可能なら最新のセキュリティ修正入りリリースへ。
• 管理面をインターネットに出さない。admin_net で許可網を絞る。
• 暫定で COOKIE_SIGN_KEYS に十分な長さの秘密を設定（アップグレード代替にはしない）。
• ファイル共有が終わったインスタンスは停止・破棄する。

検知ポイント

• 短時間に繰り返されるログイン初期リクエスト、未知IPからの管理API呼び出し。
• server_code やプラグインの予期しない変更、新規管理者セッション。
• VulnCheckが挙げた探索元IP／同一サブネットからの到達。
• （考察）HFS以外でも、Nodeアプリで Cookie署名・CSRF・招待トークンに Math.random() / randomId 系を使っていないかのコード検索。

参考リンク

• Horizon3 — Anthropic Mythos Finds Rejetto HFS RCE
• The Register — Mythos vuln under attack (2026-10-03)
• SXZ.io — Exploitation timeline and patch diff summary
• NVD — CVE-2026-61500
• GitHub Advisory — GHSA-xxrm-3f86-v97j