Anthropic Mythos HFS脆弱性は修正されたが、その後攻撃者が動き始めた
AnthropicのMythosは重大なHFSの欠陥発見に貢献したが、研究者が完全な攻撃チェーンを公開して間もなく、悪用が始まったと報告されている。Anthropic Mythos HFS脆弱性により、認証されていない攻撃者はサーバーの秘密情報を再構築し、管理者セッションを偽造して、リモートコード実行に到達できる。
CVE-2026-61500として追跡されるこの欠陥は、Rejetto HTTP File Serverのバージョン3.0.0から3.2.0に影響する。Rejettoは2026年7月にバージョン3.2.1で修正した。Horizon3は9月30日に詳細な技術分析を公開し、VulnCheckは翌日に悪用の試みを検知した。
この時系列は、単なるAI支援による脆弱性発見の事例ではない。Mythosは疑わしい関数を指摘しただけではなかった。Horizon3によれば、複数の弱点を結び付け、可逆的な乱数生成器をモデル化し、必要な制約を構築して、実際に動作するエクスプロイトを作成した。
不穏なのは公開後の展開だ。防御側には2か月以上前にパッチが提供されていたにもかかわらず、エクスプロイトの仕組みが公開された時点でも脆弱なシステムが到達可能な状態にあったとみられる。したがって中心となる競争は、Mythosと別のAIモデルの対決ではない。加速する脆弱性研究と、公開ソフトウェアを特定し、更新し、検証する遅いプロセスとの競争である。
Anthropic Mythos HFS脆弱性は乱数を管理者アクセスへ変える
CVE-2026-61500は、弱い乱数源を完全な管理者権限へ至る、認証不要の経路へ変えてしまう。
Rejetto HFSは、Web経由でファイルを共有するためのオープンソースサーバーである。現行の3.x系はNode.js上で動作し、JavaScriptのWebフレームワークであるKoaを使ってWebリクエストとセッションを管理する。
セッションCookieは、どの認証済みユーザーがWebアプリケーションにリクエストしているかを示す。サーバーは秘密鍵でそのCookieに署名するため、攻撃者は署名を無効にすることなくユーザー名や権限を改ざんできない。
HFSは、JavaScriptのMath.random()関数でデフォルトの署名鍵を作成していた。この関数は通常のランダム化処理には適しているものの、暗号学的な秘密情報を生成するためには設計されていない。
問題は、生成器の初期選択だけにとどまらなかった。HFSはログイン処理の一部で、同じ疑似乱数生成器から得られた別の値も公開していた。疑似乱数生成器、すなわちPRNGは、内部状態から決定論的なシーケンスを生成する。
Horizon3の技術的開示によると、Mythosはこの関係の両側を特定した。弱い署名鍵生成と、同じシーケンスから観測可能な出力を露出させる別の認証不要の経路を発見した。
モデルはその後、十分な数の出力があれば生成器の状態を再構築できると推論した。そこから攻撃者はシーケンスをさかのぼり、HFSが署名鍵を作成した際に使った値を再現できる。
これは、ログイン試行を繰り返してパスワードを推測することとは異なる。攻撃者はその代わりに、決定論的システムの内部状態を解く。いったん状態が判明すれば、秘密であるはずの鍵は再現可能になる。
Horizon3が実証したチェーンは、組み込みの管理者ユーザー名が存在するかを確認するところから始まる。続いて攻撃者はログイン操作を繰り返し要求し、露出したMath.random()の出力を収集する。
研究者らは、説明されたエクスプロイトにおいて脆弱なエンドポイントを12回サンプリングした。これらの観測結果は、Microsoftが開発した充足可能性判定モジュロ理論ソルバーであるZ3の制約となった。
SMTソルバーは、論理的・数学的条件の集合を満たす値を決定する。今回の場合、観測された乱数出力とHFSの既知の挙動に整合する状態の復元に役立った。
その後、攻撃者は復元した状態をサーバーの起動シーケンスまでさかのぼることができる。これにより、Cookie署名鍵を構築するために使われた値が明らかになる。
その鍵を使い、攻撃者は管理者を表すと主張する正しく署名されたCookieを作成する。実際の管理者が攻撃者を認証していなくても、HFSは署名が有効であるため偽造セッションを受け入れる。
管理者アクセスが最後のつながりとなる。HFSはカスタムのサーバーサイドコードをサポートしているため、管理者はホスト上で動作するJavaScriptを設定できる。Horizon3は、この正当な機能を用いて任意コマンド実行を実証した。
この違いは重要だ。危険な挙動は、偶発的なパーサーバグを通じて不正なコードを注入することに依存していない。偽造されたIDと、意図的に管理者へ提供されている機能を組み合わせたものだ。
Rejettoの修正は、予測可能性の両方の要因に対処している。パッチ済みバージョンでは、署名鍵に暗号学的に安全な乱数バイトを使い、露出するログイン識別子にはランダムなUUIDを使用する。
運用者はHFS 3.2.1リリースまたはより新しい安定版を導入すべきである。強力な明示的署名鍵を設定すればリスクの一部は軽減できるが、アップグレードは文書化された攻撃チェーンを排除するため、適切な対応であり続ける。
Mythosは人間のレビュアーなら断念したかもしれないチェーンを見つけた
重要なMythosの成果は`Math.random()`を特定したことではなく、一見ありふれた複数のミスが実用的なエクスプロイトを形成していると証明したことだ。
静的解析ツールは、弱い乱数生成器について長年にわたり開発者へ警告してきた。スキャナーは認証コードの近くにあるMath.random()を検索し、その行をレビュー対象としてフラグ付けできる。
しかし、この観察だけでリモート侵害が成立するわけではない。研究者は、攻撃者が関連する出力を観測できるか、生成器を再構築できるか、正確な鍵を復元できるか、正しいCookie形式を偽造できるか、そして認証を意味のある影響へ転換できるかを判断する必要がある。
各段階で作業と不確実性が増す。そのため、特に研究者が多数の可能性のある手掛かりから選ばなければならない場合、発見をさらに調査するかどうかが変わることが多い。
Horizon3は、Mythosがこの長い推論経路を処理したとしている。その専門的な暗号解析エージェントは、HFSが起動時に署名鍵を作成する際、3つの乱数出力を消費することに気付いた。
モデルは同時に、同じ生成器が生成した完全精度の値を返すログイン経路も特定した。Cookieは署名されているが暗号化されていないため、クライアントは自身のセッションデータを読み取れることも認識した。
Mythosは次に、これらの事実をV8のxorshift128+実装と結び付けた。V8はNode.jsで使用されるJavaScriptエンジンであり、xorshift128+は可逆的な内部状態を維持する。
可逆性があるからといって、この生成器を使うすべてのアプリケーションが自動的に悪用可能になるわけではない。攻撃者には、十分に有用な観測結果と、それを秘密生成シーケンスに関連付ける手段が依然として必要だ。
HFSは両方の条件を満たしていた。ログインフローを通じて連続した値を露出させており、署名鍵はプロセス開始時に同じ生成器から作られていた。
モデルは、可能なすべての鍵を単純に探索するのではなく、Z3を使って状態を復元することを提案した。また、既存のCookieと署名をオフラインの検証手段として特定した。
この検証段階は重要である。復元された候補は、正規のCookieのメッセージ認証コードと照合してローカルでテストできる。攻撃者はすべての候補を標的に送信し、目立つ失敗リクエストを発生させる必要がない。
Horizon3によると、Mythosは動作する概念実証を作成し、任意コマンド実行を実証した。モデルの分析には微妙な誤りが含まれる可能性があるため、公開前に人間の研究者が結果をレビューしたことは不可欠である。
Anthropicのより広範なMythos能力レポートは、完全な悪用に対する同様の重視を説明している。同社は、動作するエクスプロイトを作成することが、重大な脆弱性と、実際的な影響を欠くクラッシュや疑わしいコードとを区別する助けになると主張している。
このアプローチは、防御側のトリアージを改善しうる。管理者アクセスへ至ることが確認された経路は、到達可能なトリガーのない孤立した警告とは異なる扱いに値する。
同時に、珍しい脆弱性クラスを追究する経済的障壁も下げる。Horizon3の研究者は、暗号学的な発見は、実証に専門的な数学知識と相当な時間を要するため、優先順位を下げられる場合があると述べた。
こうした段階を完了できるAIシステムは、従来は採算に合わなかった研究を実行可能にしうる。エクスプロイトを構築・検証する限界コストが下がるにつれ、調査する価値のあるバグの集合は拡大する。
MythosによるHFSエクスプロイトは、この変化を明確に示している。個々の要素はいずれも前例のないものではなかった。弱い乱数、露出した生成器出力、署名付きCookie、特権的な管理機能はいずれも確立されたセキュリティ概念である。
変化は統合にある。報告によればMythosは、研究者が各中間段階を指示しなくても、ファイル、フレームワーク、数学的挙動、アプリケーション機能にまたがる関係を追跡した。
だからこそ、AIが「バグを見つけた」という単純な主張では本当の圧力を見落としてしまう。発見には価値があるが、その発見が緊急の運用上の問題となるかどうかを決めるのは、エクスプロイトの構築である。
公開情報は遅いパッチサイクルと衝突した
完全なエクスプロイト分析より前にパッチは存在していたが、手法の再現が容易になった時点でも、インターネット公開のHFSシステムは脆弱なままだったと報告されている。
Rejettoは2026年7月13日にバージョン3.2.1をリリースした。CVEレコードでは、バージョン3.0.0から3.2.0が影響対象とされている。
Horizon3は詳細な分析を公開するまで9月30日まで待った。この遅延により、攻撃者へ脆弱性の完全な説明を渡すことなく、管理者に更新の時間を与えた。
開示には重要な仕組みが含まれていた。乱数漏えい、状態再構築、鍵の復元、偽造された管理者セッション、そしてコード実行への移行が説明されていた。
観測された攻撃トラフィックによれば、VulnCheckは10月1日に悪用の試みを検知し始めた。初期の活動では、中国でホストされたインフラが米国の脆弱なシステムを標的にしていたと報じられている。
その後のリクエストは、プロキシとして動作しているように見える同一サブネット内の2つの米国アドレスから送信された。研究者らは日本のシステムに対する標的化も報告した。
これらの観測は積極的な悪用の試みを裏付けるものだが、攻撃者の身元や政府との関係を立証するものではない。ホスティング場所とプロキシの場所は、弱い帰属シグナルである。
また、どれだけのシステムが侵害されたかも明らかにしない。検知は、誰かがエクスプロイト関連のトラフィックを送信したことを示せるが、標的が偽造セッションを受け入れた、あるいはコマンドを実行したことまでは証明できない。
こうした限界があっても、タイミングは重要である。最初に観測された活動は、技術的説明の公開からおよそ1日後に続いた。
これは、攻撃者がその期間にすべての数学的手順を独自に再現したことを証明するものではない。彼らは以前から手法を開発していた可能性も、公開資料を応用した可能性も、既存の脆弱性レコードから十分な情報を得た可能性もある。
運用上の教訓は変わらない。詳細なエクスプロイト情報が公開されたなら、防御側は能力ある攻撃者がそれを迅速にスキャンや攻撃トラフィックへ転換できると想定すべきである。
Anthropicの開示ポリシーは、こうした相反するニーズの均衡を図るものだ。一般的には、保守担当者への通知、90日間の開示期間、AI起点の報告に対する人間のレビューを想定している。
同ポリシーによれば、Anthropicは通常、パッチ公開から45日後に完全な技術的詳細を公表する。この猶予は、下流の利用者が修正を展開する時間を確保するためのものだ。
CVE-2026-61500では、7月のパッチ公開からHorizon3による9月の分析まで、より長い間隔があった。その後も脆弱なシステムが確認されたことは、資産の可視性が不完全であれば、開示タイミングだけでは補えない理由を示している。
短期的なファイル転送のために展開されたサーバーが、インベントリに登録されないまま見落とされることがある。コンテナが古いイメージに固定されたままの場合もある。セルフホスト型サービスが、忘れ去られたポートフォワーディングのルールの背後に残っていることもある。
HFSはまさにこうした軽量なユースケースに適している。手軽さによってファイル共有は容易になるが、一元管理されたインフラの外での展開を促す可能性もある。
ソフトウェアの履歴は、この懸念を具体的に裏付けている。旧2.x系に影響した過去のHFSの脆弱性は、2024年にCISAのKnown Exploited Vulnerabilitiesカタログに登録された。
この旧来の問題は、異なるコードベースに存在した別の脆弱性だった。HFS 3.xはTypeScriptで書き直されている一方、2.x系はDelphiを使用していた。
この前例は、すべてのHFSインストールが侵害されていることを意味しない。しかし、インターネットに公開されたファイルサーバーが魅力的な標的であること、特に悪用が直接コード実行につながる場合にはなおさらであることを示している。
したがって、パッチ適用には検証の工程が必要だ。セキュリティチームは、更新が割り当てられた時点でチケットを閉じるべきではない。到達可能なすべてのインスタンスが修正版を報告していること、古いコンテナやバイナリがもはやリクエストに応答しないことを確認すべきだ。
真の競争はAIによる発見と修復速度の間にある
Mythosはセキュリティ研究のテンポを上げるが、組織のエクスポージャーは依然としてシステムをどれだけ迅速に特定・更新できるかに左右される。
セキュリティプログラムは、脆弱性管理を件数で測ることが多い。チームは、起票した検出事項の数、展開したパッチの数、サービスレベル目標を満たした割合などを報告する。
CVE-2026-61500は、より重大な時間間隔を浮き彫りにしている。重要な時計は修正が利用可能になった時点で始まり、公開されている脆弱なすべてのインスタンスが更新、隔離、または削除される時点で止まる。
AI支援による研究は、ソースコードを検証済みの攻撃経路へ変換するまでに必要な時間を短縮する。公開開示は、その経路を追加の研究者や攻撃者が再現するコストも下げる。
一方で、パッチ適用プロセスが同じ速度で自動的に加速するわけではない。依然として、所有者情報、保守時間帯、テスト、承認、展開、確認に依存している。
これにより非対称な競争が生じる。研究者はリポジトリ全体で分析を並列化できるのに対し、防御側は影響を受ける本番システムをそれぞれの事業文脈の中で扱わなければならない。
Anthropic MythosによるHFS脆弱性は、深刻度スコアだけでは不十分である理由も示している。クリティカル評価は潜在的な影響を示すが、その脆弱なアプリケーションがインターネットから到達可能かどうかは分からない。
逆に、小規模なファイル共有サーバーは少数の利用者しか支えていないため、ほとんど注目されないかもしれない。認証なしのリモートコード実行を許すなら、その控えめな事業上の位置付けは侵入経路としての有用性を低下させない。
適切な対応は発見から始まる。チームは、ソフトウェアインベントリ、コンテナレジストリ、クラウドワークロード、エンドポイントへの展開、外部からアクセス可能なサービスからRejetto HFSを探すべきだ。
修正内容と脆弱性の仕組みが異なるため、3.x系と旧バージョンのHFSを区別すべきである。サポート対象の3.xインストールはすべてバージョン3.2.1以降を実行すべきだが、最新の安定版が望ましい。
ネットワーク制御も追加の防御層となる。限定されたグループ向けのHFSインスタンスは、VPN、許可リスト、または認証済みゲートウェイでアクセスを制限できるなら、インターネット全体に公開したままにすべきではない。
こうした制御はアップグレードの代替にはならない。信頼されたエンドポイントの侵害、設定ミス、将来のネットワーク変更によって、管理者が隔離されていると考えていたサービスが露出する可能性がある。
チームは公開開示日の前後について、サーバーログも確認すべきだ。認証エンドポイントへの繰り返しの呼び出し、予期しない管理者セッション、設定変更、見覚えのないサーバーサイドコードは調査に値する。
攻撃が成功した場合、攻撃者は目に見えるHFS設定以上を変更する可能性がある。リモートコード実行により、OSアカウント、スケジュールタスク、起動スクリプト、追加サービスを通じた永続化が可能になる。
このため、侵害が確認されたホストにパッチを適用するだけでは不十分だ。対応担当者はホストを隔離し、証拠を保全し、関連する認証情報をローテーションし、接続先リソースを評価し、システムの完全性を確認できない場合は再構築すべきである。
防御上の意味合いはHFSを超える。開発者は、汎用の疑似乱数生成器を認証用シークレット、リセットトークン、暗号学的ノンス、セッション識別子の許容できない生成元として扱うべきだ。
コードレビューでは、個々の呼び出しだけでなく、共有状態の関係を調べる必要がある。安全なシークレットであっても、同じ生成器が他の場所で相関する出力を漏らせば予測可能になる。
フレームワークのデフォルトにも同様の精査が必要だ。開発者は、ライブラリが安全でない入力を安全にしてくれると想定することがある。署名フレームワークがCookieの完全性を保護できるのは、提供される署名鍵が秘密で予測不能なままである場合に限られる。
AI支援分析は、こうした複数ファイルにまたがる関係を追跡するのに適している。モデルは呼び出し箇所を検索し、データフローを追跡し、フレームワークの挙動を比較し、理論上の弱点が特権操作に到達するかを検証できる。
ただし、その利点によって人間による検証の必要性がなくなるわけではない。生成されたエクスプロイトはバージョンを読み違えたり、環境上の前提を省いたり、テストハーネスを超えて一般化しない挙動を示したりする可能性がある。
最も強力なワークフローは、機械の規模と説明責任を伴うレビューを組み合わせるものだ。AIが攻撃チェーンを提案・検証し、経験豊富な研究者が結果を再現し、深刻度を評価し、修復を調整し、開示を管理する。
MythosによるHFSエクスプロイトが証明していないこと
1つの成功したエクスプロイトチェーンは意味のある能力を示すが、Mythosがすべての重大な脆弱性を確実に見つけることを証明するものではない。
Horizon3の報告は、AnthropicのProject Glasswingに参加する組織によって作成されたケーススタディだ。研究者らは、HFSコードベース全体で専門エージェントを並列実行するカスタムハーネスを使用した。
この文脈は重要である。この結果は、支援のない一般利用者向けチャットボットにリポジトリを渡し、即座に侵害できたことを示すものではない。
このハーネスは、特定の脆弱性クラスにエージェントを割り当てることで調査を方向付けた。人間の研究者も標的を選定し、検出事項をレビューし、責任ある開示を扱った。
それでもMythosは、オートコンプリートや一般的なセキュリティチェックリスト以上の貢献をしたように見える。研究者らによれば、弱いPRNG、出力漏えい、セッション形式、過去の状態の復元、管理者向けコード実行機能を独自に結び付けたという。
公開された証拠は、動作するエクスプロイトがこのチェーンを実証したため、HFSの検出結果を裏付けている。一方で、偽陽性、総計算量、失敗した実行、より広範な分析で破棄された検出事項についての情報は少ない。
こうした分母の欠落は、広範な生産性比較を制約する。多額のコストを伴う多数の試行の末に例外的な脆弱性を1件見つけるモデルと、継続的に成功するモデルでは、運用上の価値提案が異なる。
この事例は、AIだけが迅速な悪用を引き起こしたことも示していない。攻撃者は以前から、概念実証コードや技術的な解説が公開された後、迅速に動いてきた。
従来のスキャナー、差分解析ツール、エクスプロイトフレームワーク、人間によるリバースエンジニアリングは、すでにそのワークフローを支えている。AIは速度と利用しやすさを加えるが、既存の攻撃ツールチェーンに加わる存在である。
また、ソースの所在地だけで帰属を確立することはできない。報告された攻撃では中国と米国のインフラが使われていたが、プロキシや侵害ホストは運用者の所在を日常的に隠す。
国家支援型キャンペーンに関する主張には、ツールの重複、インフラの履歴、被害者の選定、アクセス後の行動など、追加の証拠が必要になる。
悪用成功の規模にも不確実性がある。公開報道では、実際の脆弱なシステムに対して検出されたリクエストは少数と説明されていた。
これは緊急のパッチ適用を正当化するには十分である。しかし、世界規模の感染件数を推定したり、広範なキャンペーンを主張したりするには不十分だ。
防御側は両極端を避けるべきである。Mythosをマーケティングだとして退けることは、検証済みで技術的に興味深いエクスプロイトを無視することになる。1件の事例を普遍的な自律ハッキングの証明として扱うことは、公開証拠が支持する範囲を誇張する。
均衡の取れた結論はより限定的でありながら重要だ。AI支援の研究システムは、専門家が微妙な暗号設計上の欠陥を、リモートコード実行に至るエンドツーエンドのエクスプロイトへ変換するのを支援した。
この能力は、研究者が経済的に追求できる検出事項の範囲を広げる。また、パッチの利用可能化から検証済み展開までの遅延を短縮する価値も高める。
防御側が追い付けるかを示す3つのシグナル
次の試金石は、悪用が拡大するか、パッチ適用が改善するか、AI起点の開示がソフトウェア保守担当者にとって管理可能なままであるかだ。
第1のシグナルは、観測された攻撃の範囲である。より多くの送信元アドレス、エクスプロイトのバリエーション、侵害後のペイロード、影響を受けた組織が確認されれば、CVE-2026-61500が日和見的なテストを超えたという結論を強めるだろう。
単純なプローブが引き続き散発的に見られるだけなら、より限定的な解釈を支持する。それは、攻撃者が持続的なキャンペーンをまだ構築せずに公開技術を試していることを示唆する。
第2のシグナルは、Rejetto HFSの運用者が実際に脆弱なバージョンを削除するかどうかだ。インターネット測定やインシデント報告は、警告が広まった後も3.0.0から3.2.0を実行するインストールが残っているかを明らかにできる。
急速な減少は、保守担当者、セキュリティベンダー、管理者が開示を行動に変えたことを示す。長期にわたる露出は、インベントリと展開が依然として制約要因であることを裏付けるだろう。
第3のシグナルは、その後のProject Glasswing開示の品質と量である。Anthropicによれば、AI起点の脆弱性報告は公開前に人間によるレビューと協調的な処理を受ける。
再現可能で影響の大きい検出結果が安定して流れれば、Mythosが研究経済を変えるという主張を支持する。反対に低価値の報告が大量に押し寄せれば、オープンソースの保守担当者に負担をかけ、プロセスへの信頼を弱めることになる。
これがAnthropic MythosによるHFS脆弱性のより大きな帰結だ。より優れた発見が防御上の価値を生むのは、保守担当者が報告を受け止め、利用者が得られた修正を展開できる場合に限られる。
セキュリティチームは、影響を受けるHFSサーバーを今すぐ更新し、展開済みのバージョンを検証し、不必要な公開を制限し、9月30日以降の不審な活動を調査すべきである。そのうえで、より難しい問いを投げかけるべきだ。次のAI支援エクスプロイトが同じ圧縮されたタイムラインで到来した場合、自組織の資産インベントリは攻撃者より先に答えを出せるだろうか？
