RHELのスペシャリストソリューションアーキテクトの田中司恩(@tnk4on)です。
この記事はRed Hat Blogの Navigating the Mythos-haunted world of platform security を、許可を受けて翻訳したものです。
2026年4月28日追記: MythosおよびProject Glasswingによって発見された脆弱性に対するRed Hatの分析・対応状況は、Navigating Mythos and Project Glasswing Findingsのナレッジにまとめられています。
Claude Mythosのプレビュー版の登場は、ITセキュリティの専門家にとって大きな課題であると同時に、（それを導入できる組織にとっては）一つの好機でもあります。Mythosは、レガシーコードに潜む複雑なメモリ安全性や論理的な欠陥を特定できるだけでなく、それらをますます巧妙な手法で悪用することさえ可能な、新しいカテゴリーのフロンティアモデルです。
これにより、企業内のITセキュリティチームやオープンソースコミュニティにおいてAI駆動の脆弱性スキャンが担っている突出した役割が、劇的に強化・拡大されることになります。しかし、Mythosがもたらすのは単なるAIによる脆弱性レポートの洪水ではありません。それはサイバー攻撃を工業化する可能性を秘めた道筋であり、高度なバグ調査や関連する脆弱性の連鎖攻撃への参入障壁を下げる存在です。我々業界は、この変化に対してパニックで反応すべきではありません。むしろ、コンテキスト（文脈）とスキル、そして最終的には我々自身がAIを活用することを通じて、システムの回復力を強化する必要があるのです。
マシンの中のゴースト
悪意のある攻撃者がどのようにMythosを悪用する可能性があるか議論する前に、この新時代の最初の課題はS/N比（シグナル対ノイズ比）の急激な変化です。Mythos以前のAIエージェントであっても、コード内の膨大な潜在的問題を特定することは可能でしたが、発見は戦いの半分に過ぎません。残りの半分は、これらのバグを大規模に検証し、緩和し、最終的に修正するプロセスです。
- これらは実際の脅威か？
- どうやって優先順位（トリアージ）をつけるか？
- どうやって修正するか？
例えば、2025年後半から2026年前半にかけて、AISLEの自律型AIシステムがOpenSSLとcurlの内部で複数のセキュリティ脆弱性を発見しました。さらに最近では、2026年4月3日にAnthropicの研究者がClaude Code（Opus）を使用して、Linuxカーネルに23年間潜んでいた脆弱性（合計5つの潜在的なCVE）を発見しました。これは「脆弱性発見のためのAI時代」の到来を告げる出来事です。
額面通りに受け取れば、これは恐ろしいバグの山のように聞こえます。しかし、この脆弱性発見モードにはS/N比という課題が存在します。我々の見解では、実際に悪用可能で本番環境に影響を与える真の脆弱性を発見する唯一の方法は、継続的な監視と実際のコード精査しかありません。
コンテキスト（文脈）こそがすべて
Red Hat Product Securityは、Claude Codeのスキャンによって提示された5つの潜在的問題を評価しました。これは単なる証明のためではなく、我々のチームが常に脆弱性を監視、分析、追跡、トリアージしているという業務の一環であり、Red Hatサブスクリプションの価値を如実に示す例です。
以下は、これらのLinuxカーネルの脆弱性がもたらすリスクについての初期評価です：
- NFSDのヒープオーバーフロー修正: これはNFSプロトコルの実装問題であり、根本的な問題は、確保された小さなスペースにそれより大きなバッファを書き込もうとすることです。この脆弱性はカーネルのNFSデーモン内にあり、ユーザー空間のセキュリティアーキテクチャとは異なるため、SELinuxのような制御は適用されません。このサービスはデフォルトでは内部ネットワークの外側に公開されていないため、悪用の実際のリスクは大幅に低くなります。最悪のシナリオではnfsdがクラッシュし、サービス拒否（DoS）につながります。Red Hatの製品エコシステム内では、このバグは現状「Low（低）」リスクと見なされますが、さらなる攻撃ベクトルが発見されれば「Moderate（中）」に評価される可能性があります。
- IO_URING SQE_MIXEDのラップチェック: このカーネルバグから、重大な悪用につながる可能性はありません。根本的な欠陥は、破損したSQE（送信クエリエントリー）の判定が誤っていることであり、悪用された場合の最悪のシナリオは、下流のSQEエラーによるシステム不安定化です。これはセキュリティ問題というよりも、機能または安定性のバグです。さらに、このバグを悪用するために必要な混在型64b/128b SQEリングのサポートをRed Hat製品では提供していないため、Red Hat製品においてはCVEや機能バグとして扱われません。
- Futex Requeueの問題: このバグには間違いなくローカルアカウントが必要であり、特権アカウントが必要かどうかを判断するにはさらなる調査が必要です。元の報告ではuse-after-free（解放済みメモリの使用）のバグとされていますが、文脈から判断すると、その「use-after-free」のシナリオをどのように引き起こすのかは不明確です。Red Hat製品において、私たちはこの問題をModerate（中）のバグと評価します。主な理由は、悪用に成功するための前提条件が複雑であるためです。最悪の場合、悪用によってカーネルパニックを引き起こす可能性がありますが、現時点で判明している情報に基づくと、リモートコード実行は不可能です。
- KSMBD Share_Confのuse-after-freeの問題: この問題をネットワーク経由で悪用することに成功すればカーネルパニックを引き起こせますが、デフォルトではこのカーネルデーモンへのアクセスは内部ネットワークに限定されています。さらに、解放後にアクセスされるデータは、ユーザーが意味のある形で制御できるものではないため、システムが不安定になる以上の悪用価値や影響は低下します。この状況を考慮し、Red Hat製品ではこれをModerate（中）のCVEとして分類します。
- KSMBDのsmb_direct_prepare_negotiationにおける符号の問題: これはNFSのヒープオーバーフロー修正バグと同様で、攻撃者は悪意のあるデータかどうかにかかわらず、データを送信する前に認証を完了させる必要があります。潜在的な悪用につながる可能性のある事態を防ぐため、私たちは、ユーザーが信頼できるエンティティと見なされる場合を除き、カーネル内でのネットワークファイル共有を使用しないことを強く推奨します。Red Hat製品において、デフォルトの設定ではKASLRなどの保護機能が有効となっており、脆弱なコードが存在する場合でもこのバグの影響は低減されます。前提条件や基本構成を考慮し、私たちはこのバグを当社の製品エコシステムにおいてLow（低）の重大度と分類しています。
これらは明らかに5つの脆弱性に過ぎませんが、私たちはAIがソフトウェアサプライチェーンの根幹において、このような欠陥の発見を飛躍的に加速させることを予想しています。特にMythosのような強力なフロンティアモデルを含むAIモデルの悪用と組み合わさることで、悪意のある攻撃者は未知の欠陥を発見し、さらには同じワークフローの中でそれを悪用することさえ可能になるでしょう。これらすべては壊滅的な事態のように思えますが、それは私たちが業界としてそれらから目を背けたり、その能力を過小評価したりした場合に限った話です。
Red Hatは、このようなAI駆動のコード監査の到来を見据えて備えていました。私たちはすでに、Red Hat Enterprise Linux（RHEL）の構築・保守方法の検証として、またプラットフォームを保護する方法を拡張する手段として、AIを用いた脆弱性発見を積極的に取り入れています。
AIの対抗策としてのAI
理想的な世界であれば、AIが数億行のコードをスキャンして複雑なバグを特定できる能力は、オープンソースコミュニティへの贈り物と見なされるはずです。なぜなら、それはオープンなコードをより多くの人の目でチェックできることを意味するからです。しかし、現実はそれほど単純ではありません。
発見は戦いの半分に過ぎません。AIスキャナーによって特定された膨大な数の潜在的なセキュリティバグのうち、ごく一部でも検証されれば、セキュリティの世界は激震に見舞われるでしょう。今や課題は「脆弱性の発見」から「それらを大規模に吸収し、修復すること」へと移行しています。AIが多くの潜在的な脆弱性を発見するのと同様に、Red HatはAIツールを活用してそれらの脆弱性を迅速かつ正確にトリアージし、この急激な変化によって生じるS/N比の問題を改善しようと努めています。
AIエージェントがアップストリームのLinuxカーネルで問題を発見すると、すべてのディストリビューションが何らかの形で影響を受けます。その違いは、オペレーティングシステムを支えるインフラストラクチャにあります。つまり、専門家、プロセス、そして脆弱性が発見された際に対処する姿勢です。Red Hatは何十年にもわたってこれを行ってきており、AI主導による発見の波に対しても本質的な優位性を持っています。
制限のない反応ではなく、コンテキストこそが、Red HatがAIによる脆弱性スキャンやMythosのような最も高度なAIモデルによってもたらされるリスクに対処する際の方針を定義しています：
- コンテキストがバグを無力化する：RHELの標準構成に含まれるASLRやSELinuxのような機能は、脆弱なコードであっても、本番環境において意味のある攻撃を成功させることを困難にします。
- 機能性とセキュリティ：AIが特定した脆弱性の中には、実際には攻撃経路が存在せず、単なる機能上の不具合に過ぎないものも含まれています。
- 運用の現実：NFSプロトコルに見られるような多くの問題は、Red Hatの製品エコシステム内ではLow（低）リスクと見なされます。なぜなら、適切なセキュリティアーキテクチャが構築されていれば、影響を受けるデーモンがインターネットにさらされることはほとんどないからです。
攻撃が横行する闇を照らす光
AIが加速する世界において、堅牢なプラットフォームと脆弱なプラットフォームを分かつものは、OSの背後にあるインフラストラクチャです。ここに、Red Hat Enterprise Linux（RHEL）サブスクリプションの真価があります。
Claude Mythosが脆弱性を連鎖させて攻撃コードを作成できる一方で、RHELは以下を通じて進化し続ける防波堤を提供します：
- 先を見越したキュレーション：当社のProduct Securityチームは、単にコードをパッケージ化するだけではありません。アップストリームの研究開発に深く関与し、トリアージ、検証、そして修正パッチのバックポートを行っています。
- インテリジェントなツール群：私たちは安全なソフトウェアサプライチェーンの原則に基づいた自動化ワークフローを用い、AIにはAIで対抗しています。また、Red Hat Lightspeedのようなツールを通じて、新たな脆弱性が発見された際にハイブリッドクラウド全体で修復の優先順位付けができるよう、社内の専門知識を顧客に提供しています。
- 時代を越えた専門性：Red HatはすでにAIツールを導入し、独自の知見をエージェントに統合することで、Mythosのような次世代モデルがもたらす潜在的な問題に対して一歩先んじています。RHELのクローン版を含む他のディストリビューションとは異なり、当社は独立したセキュリティ研究能力と、アップストリームプロジェクトに対する深い専門性を維持しており、膨大な量の課題に対応可能です。AI主導の現代において、アップストリームからの修正が下流で再パッケージされるのを待つことは、ビジネスにとって明確なリスクの空白期間を生み出します。
AIの嵐に対するレジリエンス
Mythosの登場は、オープンソースの基盤が崩壊しつつあることを意味するのではなく、プラットフォーム保守の基準が引き上げられたことを意味します。Red Hatはこの変化を見据えて備えており、セキュリティ修復にAIを活用する以上の対策を講じています。
RHELのサブスクリプションは、単なるソフトウェアの提供にとどまりません。それは現代の脅威のスピードに対するダイナミックな対応です。社内の専門知識を通じたコンテキストは、実際のリスク評価と密接に関係しています。AIスキャンによって発見された問題を、それがあなたの環境にとってほとんど懸念がないものであっても、すべて修正すべきでしょうか？何千ものバグが見つかったとしても、実際に悪用可能な脆弱性がごくわずかであれば、優先順位付けとトリアージこそが重要になります。
Red Hatの製品エコシステムにおいて、今回新たに発見されたバグのほとんどは、サービスに影響を与えるような問題を引き起こすことはありません。厄介ではありますが、ビジネスを破壊するようなものではありません。
私たちは、Linuxコミュニティにおける新たな規範と標準にコミットしています。自動化ツールとAIを活用した独自のスキルを駆使し、オープンソース全体およびLinuxの強力なセキュリティ体制を維持する道をリードしていきます。オープンソースはイノベーションの出発点であり、私たちはこの強固な基盤を守り続ける決意です。
