AIセキュリティ on KnightLiブログ

AI脆弱性発見の時代が来た：Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwnはなぜ集中発生したのか

Thu, 21 May 2026 09:30:01 +0800

最近、Linuxカーネル関連の脆弱性が相次いでいます。Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwnが次々にセキュリティ界隈で議論されました。ローカル権限昇格につながるものもあれば、高感度ファイルを漏えいさせるもの、コンテナホストやマルチテナント環境に影響するものもあります。多くの人の第一印象は、「Linuxはなぜ急にここまで危なくなったのか」というものです。

より正確に言えば、Linuxが突然悪くなったわけではありません。長く隠れていた問題が、より速く、より体系的に掘り出されるようになったのです。

今回の波で本当に注目すべきなのは、いくつかのCVE修正だけではありません。脆弱性の発見方法が変わったことです。以前は、少数のトップ研究者が長い時間をかけて、サブシステムをまたぐロジックバグをつなぎ合わせる必要がありました。今では、AI支援監査、自動静的解析、fuzzing、セキュリティ研究プラットフォームがその作業を大きく増幅しています。脆弱性が一夜にして増えたのではなく、発見、再現、拡散の速度が上がったのです。

これらの脆弱性に共通すること

まず、最近の事例を並べて見ます。

脆弱性	主な影響	重要な特徴	リスクの焦点
Copy Fail / CVE-2026-31431	ローカル権限昇格	Linux crypto / AF_ALG関連経路、page cache書き込み問題を含む	一般ユーザーからrootへ。特にコンテナ環境で敏感
Dirty Frag / CVE-2026-43284、CVE-2026-43500	ローカル権限昇格	XFRM/ESP、RxRPCなどの経路におけるpage cache書き込みプリミティブ	チェーン利用可能。ホストとコンテナ境界に影響
Fragnesia / CVE-2026-46300	ローカル権限昇格	XFRM ESP-in-TCPサブシステムのロジック問題	Dirty Fragに近い攻撃面
ssh-keysign-pwn / CVE-2026-46333	ローカルの機密情報漏えいと権限昇格リスク	Linux kernel `__ptrace_may_access()` のロジック欠陥	SSHホスト鍵、`/etc/shadow`などの機密ファイルリスク

これらは完全に同じ脆弱性ではありませんが、いくつかの共通点があります。

従来型のリモートRCEではなく、ローカル権限昇格またはローカル機密情報漏えいである。
攻撃者はまず通常のshell、コンテナ内のコマンド実行、CIタスク権限、低権限アカウントなど、何らかのローカル実行能力を持つ必要がある。
多くのリスクはカーネル境界に集中している。page cache、暗号/ネットワークサブシステム、ptrace権限判定、コンテナ共有カーネルなど。
コンテナは強い安全境界ではなく、ホストカーネルが共通基盤であるため、現代のクラウドネイティブ環境では影響範囲が拡大する。

したがって問題は「パッチがあるか」だけではありません。より深い問題は、なぜこのような低レベルで隠れた、長く潜伏していた問題が短期間に集中して現れたのかです。

第一の理由：多くの脆弱性は新しく書かれたものではなく歴史的負債

脆弱性の公開日を見ると、そのバグが最近のバージョンで入ったものだと思いがちです。しかし実際には、そうでないことが多いです。

Copy Failのような問題の重要点は、脆弱性が何年も潜伏し得ることです。正しい呼び出し経路、権限境界、メモリセマンティクスを誰かがつなげて初めて見つかります。公開情報では、Copy Failは2017年前後のカーネル最適化の歴史と関係があるとされています。Dirty FragやFragnesiaも、ネットワーク、暗号、page cacheといった深い交差経路を指しています。

この種の脆弱性の怖さは、ある一行のコードが明らかに危険に見えることではありません。複数の前提がたまたま重なることにあります。

あるサブシステムが性能のためにインプレース処理を行う。
あるインターフェースが非特権ユーザーにカーネル機能へ到達させる。
ある経路が読み取り専用ファイルページ、page cache、ネットワーク断片、暗号バッファをつなぐ。
ある暗黙の制約が型システム、assert、ドキュメントに書かれていない。
最終的に、一般ユーザーが本来影響できないカーネル状態に影響する経路になる。

これは通常のコードレビューが最も得意とする問題ではありません。あるレビュー担当者はcryptoサブシステムを理解し、別の人はネットワークサブシステムを理解し、第三者はメモリ管理を理解しているかもしれません。しかし脆弱性はその交差点に隠れています。

第二の理由：Linuxカーネルの複雑性は人工レビューの限界を超えている

Linuxの強みは、オープンで汎用的で、幅広いハードウェアに対応し、エコシステムが強いことです。しかしそれらの強みは代償も伴います。

現代のLinuxカーネルは単なる「小さなカーネル」ではありません。スケジューリング、メモリ管理、ファイルシステム、ネットワークプロトコルスタック、暗号フレームワーク、ドライバ、仮想化、コンテナ関連機構、eBPF、LSM、セキュリティモジュール、ハードウェアプラットフォーム対応など大量のサブシステムを含みます。各サブシステムには歴史、メンテナ、性能目標、互換性の負債があります。

問題は、脆弱性が単一モジュール内ではなく、モジュール同士の交点に存在しがちなことです。

splice() はファイルページとpipeをつなぐ。
AF_ALGはユーザー空間とカーネルcrypto APIをつなぐ。
XFRM/ESPはネットワークパケット、暗号、メモリページをつなぐ。
RxRPCやESP-in-TCPのような経路はネットワークスタックをさらに複雑にする。
コンテナは低権限ローカル実行をより一般的な現実の前提にする。

エンジニアリングの観点では、Linuxカーネルはもはや「十分な目があれば全部見られる」規模ではありません。オープンソースは問題の修正と検証を容易にしますが、すべての隅が継続的かつ安全にレビューされることを意味しません。サブシステム横断の脆弱性を本当に理解できる人は少なく、そうした脆弱性ほど大きな影響を生みやすいのです。

第三の理由：性能最適化は安全境界を薄くしがち

今回の脆弱性群では、性能のためにコピーを減らし、バッファを再利用し、データをインプレース処理するというテーマが繰り返し出てきます。

この種の最適化は非常に合理的です。カーネルはインフラであり、少しの性能低下がクラウド事業者、データベース、ネットワーク、ストレージ、コンテナ基盤に影響します。コピーを一回減らす、暗号化/復号を速くする、メモリ割り当てを減らすことは、実運用で価値があります。

しかし安全上の代償も明確です。「読み取り専用データ」「共有ページ」「ユーザー制御入力」「カーネルバッファ」「暗号出力」の境界が薄くなると、あるサブシステムが入出力契約を誤解しただけで、不正な書き込みや読み取りにつながります。

つまり、性能最適化自体が悪いわけではありません。しかし、より壊れやすい組み合わせを作ります。

インプレース暗号化/復号はコピーを減らすが、入力/出力バッファの正しい隔離により強く依存する。
page cacheはファイルアクセス性能を高めるが、攻撃面にもなり得る。
ゼロコピーはスループットを高めるが、異なるサブシステムが同じメモリオブジェクトを共有する。
コンテナはデプロイ効率を高めるが、共有カーネルによりローカルLPEの爆発半径を大きくする。

安全境界は「みんながミスしないことを覚えている」だけでは維持できません。型、権限チェック、不変制約、テスト、fuzzing、継続監査によって強制される必要があります。そうでなければ、性能最適化と暗黙の仮定が増えるほど、脆弱性はいずれ掘り出されます。

第四の理由：コンテナがローカル脆弱性の価値を高めた

以前は「ローカル権限昇格」は、攻撃者がすでにローカルアクセスを必要とするため、リモート脆弱性より低リスクに見られがちでした。クラウドネイティブ時代はこの判断を変えました。

今日の「ローカル実行」の入口は多くあります。

Webアプリケーションが通常のshellを取られる。
CI/CDタスクが信頼できないコードを実行する。
コンテナ内でユーザーアップロードのタスクが走る。
マルチテナント平台がnotebook、プラグイン、スクリプト、ビルドタスクの実行を許す。
AIコード実行環境、サンドボックス、オンライン評価平台が増えている。

攻撃者がコンテナ内で実行能力を得ると、カーネルLPEはもはや「そのマシンだけの小問題」ではありません。コンテナはホストカーネルを共有するため、カーネル脆弱性はコンテナ境界を越え、ホストや他のテナントに影響し得ます。

これが、Copy FailやDirty Fragのような脆弱性がクラウド、セキュリティ、コンテナチームから強く注目される理由です。それらは「低権限ローカルコード実行」を「ホスト級リスク」に引き上げる可能性を高めます。

AIの影響：脆弱性発見コストが下がった

今回の波で最も時代性がある部分は、AI支援の脆弱性発見です。

Copy Failの公開資料では、TheoriのXint Codeが発見過程に関与したことが言及されています。具体的なツール能力がどうであれ、これは一つの傾向を示しています。AIは必ずしも脆弱性を「無から発明する」わけではありませんが、研究者が検索経路を短縮するのを非常に得意とします。

AIが脆弱性研究に与える影響は主に次の点にあります。

見慣れないコードをより速く読む
カーネルサブシステムのコード量は非常に大きく、研究者がすべての経路を手で読むことはできません。AIは関数、呼び出しチェーン、入出力関係、怪しいパターンを素早く要約できます。
モジュール横断の接続を見つけやすくする
多くの脆弱性は「ユーザー空間入口 -> ネットワークスタック -> 暗号フレームワーク -> メモリページ -> ファイルキャッシュ」のような連鎖に隠れています。AIはファイル、ディレクトリ、サブシステムをまたぐ経路整理を補助できます。
監査仮説を生成しやすくする
たとえば「どの経路がユーザー制御データをpage cacheに書くのか」「どのAPIが非特権ユーザーにcryptoサブシステムへ到達させるのか」「どの関数が入力と出力バッファは重ならないと仮定しているのか」。以前は経験で少しずつ考える問題でしたが、今はより体系的に列挙できます。
再現可能な例へ変えやすくする
AIはカーネル研究者の判断を代替できませんが、検証コード、PoCの整理、誤った経路の説明、テストケース生成を助けられます。

結果として、脆弱性発見の単位コストが下がります。

以前なら、高品質なカーネル脆弱性を発見するにはトップ研究者が長い時間を使う必要がありました。今は、システムを理解する人がAIツールを使えば、疑わしい経路をより速く絞り込めます。脆弱性供給の上限が上がり、集中公開が起きやすくなっています。

ただしAIだけが原因ではない

もう一つの極端、すべてをAIのせいにすることも避けるべきです。

AIは加速器であり、根本原因ではありません。根本原因は依然として次の通りです。

歴史的コードの長期蓄積。
性能最適化における暗黙契約が強制されていない。
サブシステム横断の複雑性が高すぎる。
デフォルトで露出するカーネル機能が多すぎる。
セキュリティテストがすべての組み合わせ経路を覆っていない。
コンテナ、マルチテナント、自動実行環境がローカル脆弱性の価値を高めた。

これらの基盤条件がなければ、どれほど強いAIでもこれほど多くの高影響脆弱性を掘り出すことはできません。逆に、これらの条件が存在する限り、AIが成熟するほど、脆弱性はより体系的に見つかりやすくなります。

防御側にとっての意味

運用、セキュリティ、プラットフォームチームにとって、今回の波には直接的な示唆があります。

第一に、「ローカル権限昇格」を低優先度として扱わないこと。
環境にコンテナ、CI、オンライン実行、プラグイン、notebook、マルチテナントタスクがあるなら、ローカル権限昇格はホストリスクになり得ます。

第二に、カーネルパッチのペースを上げること。
重要なホスト、Kubernetesノード、CI Runner、AIサンドボックス、仮想化ホストを古いカーネルに長期間置くべきではありません。カーネル更新、再起動ウィンドウ、live patch、段階的ロールバックの明確なプロセスが必要です。

第三に、不要なカーネル攻撃面を減らすこと。
不要なプロトコル、モジュール、ユーザー名前空間、特殊socket、デバッグインターフェースは、業務要件に応じて絞るべきです。デフォルトで有効であることは、デフォルトで露出すべきことを意味しません。

第四に、コンテナセキュリティではカーネルが破られる可能性を前提にすること。
コンテナ内でnon-rootを使い、capabilitiesを最小化し、seccomp、AppArmor/SELinux、読み取り専用ファイルシステム、機密マウントの隔離を使うことは今も重要です。すべてのカーネル脆弱性を止められるとは限りませんが、前提条件と後続被害を減らせます。

第五に、監視では権限昇格チェーンに注目すること。
リモート入口だけでなく、異常プロセス、機密ファイル読み取り、カーネルモジュール読み込み、コンテナ脱出兆候、CI Runner異常、/etc/shadow、SSH host keyなど高価値ファイルへのアクセスを見る必要があります。

オープンソースコミュニティにとっての意味

Linuxコミュニティや大規模オープンソースプロジェクトにとって、AIによる脆弱性発見は二重の圧力をもたらします。

一方で、AIは防御側が古い問題をより速く見つける助けになります。より多くの潜伏脆弱性が公開修正されることは、長期的には良いことです。

他方で、AIはノイズも生みます。低品質な自動報告、誤検知、重複報告、文脈のない「AIがbugを見つけた」という主張は、メンテナの時間を消耗します。本当の課題は「AIを使うか」ではなく、AIの出力を責任あるセキュリティプロセスへどう組み込むかです。

報告には最小再現が必要。
影響範囲と脅威モデルを明確にする必要がある。
理論上の問題、発火可能なbug、悪用可能な脆弱性を区別する必要がある。
embargo、ディストリビューション調整、修正ウィンドウを尊重する必要がある。
メンテナにはより良い自動テスト、fuzzing、静的解析、回帰検証が必要。

AIは脆弱性発見を速くします。同時に、修復と調整の仕組みもより成熟する必要があります。そうでなければ、セキュリティ研究の生産性向上は、メンテナの負担とユーザーの不安に変わります。

結論：神話崩壊ではなく、セキュリティ現実が変わった

Linuxは今も、主流OSインフラの中で最も透明で、制御可能で、修復と強化が可能な基盤の一つです。問題はLinuxが突然「安全でなくなった」ことではありません。現代カーネルの複雑性、クラウドネイティブな使われ方、AI支援の脆弱性発見が、脆弱性露出の速度を変えていることです。

今後も似た事件は起きる可能性が高いでしょう。毎回新しい災害が起きているからではなく、過去に蓄積された複雑な経路が、より高効率に探索されるようになったからです。

本当に変えるべきなのは、私たちの安全仮定です。

「脆弱性が公開されていない」を「脆弱性がない」と見なさない。
「ローカル権限昇格」を低リスクと見なさない。
「コンテナ隔離」を強い安全境界と見なさない。
数千万行級のシステムソフトウェアを人工レビューだけで守れると思わない。
パッチを待つだけでなく、攻撃面を縮小し、パッチ速度を上げ、多層防御を作る。

AIは脆弱性発見を高い生産能力の時代へ押し出しました。攻撃者にとっても、防御者にとっても同じです。違いは、防御側がこの能力をより速い監査、より早い修正、より安定したインフラ治理へ変えられるかどうかです。

参考資料

APT45 が AI で脆弱性を大量検証：ゼロデイ攻撃のハードルは下がっている

Sun, 17 May 2026 19:52:39 +0800

Google Threat Intelligence Group は 2026 年 5 月 11 日、新しい AI Threat Tracker を公開した。重要なのは「攻撃者が AI を使い始めた」ことだけではない。使い方が、文章作成、翻訳、偵察支援から、脆弱性研究、PoC 検証、マルウェア難読化、自動化された攻撃編成へ移っている点だ。

まず、混同しやすい二つの点を分けておきたい。

第一に、Google は AI の支援で開発されたとみられるゼロデイ exploit を初めて確認したと述べている。この事例は、名前が明かされていないサイバー犯罪グループによるものだ。対象は人気のあるオープンソースの Web ベース管理ツールで、有効な認証情報を持っている場合に 2FA を回避できる。Google は影響を受けるベンダーと協力して責任ある開示を進め、大規模悪用を防いだ可能性があるとしている。

第二に、APT45 はこのゼロデイ事例の帰属先ではない。GTIG は別件として、北朝鮮関連の APT45 が AI モデルに大量の反復プロンプトを送り、複数の CVE を再帰的に分析し、PoC exploit を検証していたと述べている。つまり APT45 は、AI を単なるフィッシングメール作成ツールではなく、脆弱性研究と exploit 武器庫の整理ツールとして使っている。

AI ゼロデイ事例が示すもの

このゼロデイは、典型的なメモリ破壊、入力検証ミス、単純な設定ミスではない。GTIG はこれを高レベルの意味論的ロジック欠陥として説明している。開発者が認証フロー内に信頼の前提をハードコードし、その結果、2FA enforcement ロジックと例外条件の間に矛盾が生じた。

この種の脆弱性は従来型スキャナーが苦手とする。静的解析や fuzzing は、クラッシュ、危険な sink、入出力経路、既知パターンの発見に強い。しかし「開発者が何を保証したかったのか」「どの例外がその保証を破っているのか」を理解するのは簡単ではない。

大規模言語モデルのリスクはそこにある。専門のセキュリティ研究者より強いとは限らないが、文脈を読み、意図を説明し、似たコード経路を比較し、業務ロジックの不整合を指摘することは得意だ。この能力が攻撃者の自動化フローに組み込まれると、熟練研究者が長時間かけて読む必要があったロジック脆弱性を、より大規模にふるい分けられる可能性がある。

GTIG は exploit コード内に AI 生成の痕跡も確認している。教育的な docstring、幻覚された CVSS スコア、教材のような Python 構造などだ。Google は Gemini が使われたとは考えていない一方で、攻撃者が何らかの AI モデルを使って脆弱性の発見と武器化を支援した可能性には高い信頼を置いている。

APT45 の変化は長期的に注目すべき

APT45 は、北朝鮮関連の脅威グループとして長く追跡されてきた。活動目的はスパイ活動、金銭獲得、戦略的情報収集にまたがる。今回 GTIG が強調したのは、APT45 の AI 利用方法だ。大量かつ反復的に CVE を分析し、PoC exploit を検証し、より信頼できる攻撃能力として蓄積している。

これは「AI に短いスクリプトを書かせる」話とは違う。

組織が AI を脆弱性の選別、PoC 検証、payload 調整、テスト環境に接続できるなら、人手のボトルネックは変わる。以前は、チームが同時に調査できる脆弱性の数は、研究者の人数、経験、時間に依存していた。今は、AI が反復的な読解、要約、変種テスト、初期判断の一部を担い、人間は標的選定、悪用可能性の確認、実運用への投入に集中できる。

防御側にとって、これは既知脆弱性の猶予期間が短くなることを意味する。

CVE が公開された後、攻撃者はアドバイザリを一から読み、パッチ diff を調べ、環境を作り、PoC を修正する必要がなくなる。AI は影響範囲の理解、テスト案の生成、失敗原因の調査、対象バージョン差分の整理を助ける。人間による修正が必要でも、全体の処理量は上がる。

これは「AI が何でも自動で侵入する」という話ではない

この件を、AI がすでに完全な侵入を単独で実行できる証拠と読む必要はない。

GTIG の報告が示すのは、攻撃チェーンの複数段階が AI によって加速しているということだ。脆弱性研究、マルウェア難読化、偵察、ソーシャルエンジニアリング、情報操作、モバイル UI 自動化、サプライチェーン汚染に AI の関与が見え始めている。

ただし AI はまだ失敗する。脆弱性を幻覚したり、悪用可能性を誤判定したり、動かないコードを生成したり、複雑な企業認可ロジックで迷ったりする。危険なのは AI が完璧なことではない。攻撃者が低コストで試行錯誤できることだ。大量試行が十分に安くなれば、誤った出力は捨てられ、使える出力だけが攻撃フローに入る。

APT45 のような事例が重要なのはこのためだ。国家級または国家に近い組織には標的も忍耐もある。AI が反復作業を減らせば、より高価値な標的に多くの資源を投じられる。

防御の焦点は「ゼロデイの有無」から「猶予期間の短さ」へ

多くの企業はこれまで、既知脆弱性はパッチ管理で、ゼロデイは多層防御で対応する、とリスクを分けてきた。AI が脆弱性研究に入ると、この境界は曖昧になる。

より現実的な問いは次の通りだ。

新しい CVE が公開された後、外部攻撃者が実用的な exploit を作るまでにどれくらいかかるか。
資産台帳は同じ日に影響を受けるシステムを答えられるか。
WAF、EDR、ログ、ID システムは異常な試行を検知できるか。
高リスクシステムで MFA、最小権限、ネットワーク分離が標準になっているか。
オープンソース部品、AI agent プラグイン、第三者 connector がサプライチェーン審査に含まれているか。

AI ゼロデイは基礎的なセキュリティを無効化するわけではない。むしろ、基礎を長く放置した環境を罰する。

パッチサイクルが遅い、資産台帳が不明確、インターネット公開面の責任者がいない、ログを検索できない、アカウント権限が過大なままなら、攻撃者が AI を使うかどうかは効率の違いにすぎない。問題はいずれ表面化する。

AI サプライチェーンも攻撃面になっている

GTIG は、攻撃者が AI ソフトウェアエコシステム自体にも注目していると述べている。agent skill、第三者データ connector、オープンソース wrapper ライブラリ、自動化フレームワークなどだ。リスクはモデルそのものが破られることだけではない。モデル周辺のツールチェーンが汚染されることからも生じる。

これは AI coding、AI Agent、自動化プラグインを使う人にとって重要だ。

悪意ある skill、バックドア入り依存関係、過剰権限の connector は、AI システムを「作業を助けるもの」から「攻撃者のために動くもの」へ変えてしまう。agent がファイルシステム、ブラウザ、端末、クラウドアカウント、企業データへアクセスできるなら、サプライチェーン審査は従来アプリの範囲にとどめられない。

最低限、次の対応が必要だ。

出所不明の agent skill やプラグインを安易に入れない。
コマンド実行、ファイル読み取り、秘密情報アクセスができるツールは権限分離する。
本番環境で未レビューの AI 生成スクリプトを直接実行しない。
AI プロジェクトの依存関係、GitHub Actions、PyPI / npm パッケージをスキャンする。
モデル API Key、クラウド秘密情報、GitHub Token に最小権限と漏えい監視を適用する。

セキュリティチームへの実務的な提案

第一に、脆弱性対応を前倒しする。高リスク CVE は月次パッチを待たせるべきではない。特に VPN、ゲートウェイ、管理パネル、ID システム、CI/CD、リモート管理ツールのような境界資産はそうだ。

第二に、検索可能な資産台帳を作る。AI が攻撃者の標的探索を速くするなら、防御側も「このシステムはあるか、どのバージョンか、どこに公開されているか」に素早く答えられなければならない。

第三に、署名検知を行動検知で補う。AI 生成の exploit やマルウェアは表面的特徴を変えるかもしれないが、認証回避、異常ログイン、大量探索、失敗リクエストのパターン、権限昇格の経路には行動痕跡が残る。

第四に、AI ツールをセキュリティガバナンスに入れる。社内の coding agent、browser agent、document agent、自動化スクリプト、プラグインマーケットには、承認、レビュー、ログ、ロールバックが必要だ。

第五に、AI 防御を「セキュリティ大模型を買うこと」だけにしない。実際に役立つのは、脆弱性優先順位付け、ログ分析、パッチ影響評価、コードレビュー、設定ベースライン確認に AI を組み込み、防御側の速度も上げることだ。

まとめ

GTIG の今回の報告は、AI が攻防の速度を上げていることをはっきり示している。

AI 支援のゼロデイは、ロジック欠陥や認証回避がモデルによって見つけやすくなる可能性を示した。APT45 の事例は、成熟した脅威組織がすでに AI を使って CVE を大量分析し、PoC を検証していることを示している。PROMPTSPY、AI 生成の難読化コード、agent サプライチェーン攻撃は、AI が攻撃者のチャットツールではなく攻撃ツールチェーンに入りつつあることを示す。

これは終末ではないが、普通のニュースでもない。

企業にとって実務的な対応は、恐れることではない。パッチ、資産、ログ、ID、サプライチェーン、AI ツール権限を、より速く、明確に、検証可能にすることだ。AI は攻撃者の試行速度を上げる。防御側も発見、判断、修復の速度を上げなければならない。