AIが脆弱性を見つけ、AIが脆弱性を突く時代ですね

はじめに

こんばんは、mirukyです。

AIがコードを書き、AIが脆弱性を見つけ、AIがそれを攻撃する。2026年、AIとセキュリティの関係は新たなフェーズに突入しました。

2026年3月、GitHub Security Labは AIエージェントで80件以上の脆弱性を発見・報告した と発表しました。同じ月、FreeBSDカーネルの脆弱性がAI（Claude）によって発見され、さらに別の研究者がClaudeにエクスプロイト開発を依頼したところ、 約8時間でリモートroot shellを完成させた という事例が報告されました。

この記事では、この2つの事例を中心に、AIがセキュリティの「守り」と「攻め」の両面でどこまで進化したのかを解説します。

目次

1. AIはセキュリティの両面を変えつつある
2. 守り：GitHub Security Lab Taskflow Agent
3. 攻め：ClaudeがFreeBSDカーネルRCEを完全攻略
4. AIセキュリティの現在地と今後

1. AIはセキュリティの両面を変えつつある

従来、ソフトウェアの脆弱性を見つけるのはセキュリティ研究者やSAST（Static Application Security Testing）/DASTといった静的・動的解析ツールの仕事でした。エクスプロイトの開発となれば、さらに高度な専門知識が求められます。

2026年、この状況がAIによって大きく変わりつつあります。

【守り側】
GitHub Security LabがLLMベースのAIエージェントを使い、OSSプロジェクトから80件以上の脆弱性を発見・報告しています。特にロジックバグやIDOR（Insecure Direct Object Reference）の発見で優れた成果を出しており、従来のSASTでは検出困難だった脆弱性を次々と見つけています。

【攻め側】
セキュリティ研究者のニコラス・カーリニ氏がAnthropicのClaude（AI）を使ってFreeBSDカーネルの脆弱性（CVE-2026-4747）を発見。さらに別の研究者がClaudeでフルリモートカーネルエクスプロイトを 約8時間で完成 させました。

つまり、、AIが 発見から攻撃まで一貫して実行できる 時代が到来しつつあります。

2. 守り：GitHub Security Lab Taskflow Agent

2-1. フレームワークの概要

GitHub Security Lab Taskflow Agentは、2026年3月6日にマン・ユエ・モ氏とペーター・シュテックリ氏によって公開されたOSSのAIセキュリティ監査フレームワークです。

YAMLベースの タスクフロー という仕組みで、LLMに対して段階的にセキュリティ監査を実行させます。分析にはGPT 5.xとClaude Opus 4.6を使用し、GitHub Copilotライセンスが必要です。

フレームワークは以下の3段階で動作します。

ステージ	内容
脅威モデリング	リポジトリの機能分割、エントリーポイント特定、アクセス制御モデルの把握
イシュー提案	各コンポーネントに対して脆弱性の可能性が高い領域を提案
イシュー監査	フレッシュなコンテキストで提案を厳格に検証し、具体的な証拠とともに判定

重要なのは、各ステージが フレッシュなコンテキスト で実行される点です。イシュー提案ステージで生成された候補は「未検証」として扱われ、監査ステージでは厳格な基準に基づいて独立に検証されます。これにより自己確認バイアスを抑制し、ハルシネーションを低減しています。

2-2. 発見された脆弱性の実例

Rocket.Chat：任意のパスワードでサインイン可能（CVE-2026-28514）

最もインパクトのある発見がRocket.Chatの認証バイパスです。マイクロサービス構成のRocket.Chatにおいて、 任意のパスワードで任意のユーザーとしてサインインできる という致命的な脆弱性が見つかりました。

根本原因は、パスワード検証関数 validatePassword が Promise<boolean> を返すにもかかわらず、呼び出し側で await が欠落していたことです。

// validatePasswordはPromise<boolean>を返す![スクリーンショット 2026-04-07 0.03.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3637204/039de23a-31d1-452b-b27c-80dff46518b6.png)

export const validatePassword = (
  password: string,
  bcryptPassword: string
): Promise<boolean> =>
    bcrypt.compare(getPassword(password), bcryptPassword);

// しかし呼び出し側でawaitしていない
const valid = user.services?.password?.bcrypt &&
  validatePassword(password, user.services.password.bcrypt);

if (!valid) {
    return false; // Promiseはtruthyなので、ここには到達しない
}

JavaScriptにおいてPromiseオブジェクトは常に truthy です。await なしで評価すると、パスワードが正しいかどうかに関係なく valid は常にtrueと評価されます。結果として、bcryptハッシュが保存されているすべてのユーザーに対して、任意のパスワードでサインインが可能でした。

この脆弱性はRocket.Chatのマイクロサービス構成でのみ発生します。モノリシック構成では別のコードパスが使われるため、影響を受けません。

Outline：権限昇格（CVE-2025-64487）

コラボレーションツールOutlineでは、ドキュメントのグループメンバーシップ変更エンドポイント（documents.add_group）が、本来必要な manageUsers 権限ではなく、より弱い update 権限で認可されていました。ReadWrite権限しか持たないユーザーが、グループをAdmin権限でドキュメントに追加し、自身の権限を昇格できるという脆弱性です。

AIは 初回の実行で この認可ロジックの不整合を発見しました。Outlineチームは報告から3日以内に修正を完了しています。

ECサイトの「ショッピングカート黙示録」（CVE-2025-15033、CVE-2026-25758）

WooCommerceでは、サインイン済みユーザーがゲスト注文の氏名・住所・電話番号を閲覧できる脆弱性が見つかりました。さらにSpree Commerceでは、未認証ユーザーがシーケンシャルな番号を列挙するだけで全ゲスト注文の住所情報を取得できる脆弱性が発見されました。

これらの認可ロジックの不備は 何年も見過ごされていた ものです。

2-3. 統計データと分析

40以上のリポジトリ（主にマルチユーザーWebアプリケーション）に対してタスクフローを実行した結果です。

段階	件数
イシュー提案	1,003件
脆弱性あり判定	139件
重複除去後	91件
FP（偽陽性）として却下	20件（22%）
低重要度として却下	52件（57%）
報告対象として採用	19件（21%）

脆弱性タイプ別では、 ビジネスロジック問題 の検出率が25.0%と最も高く、セキュリティ設定ミス（17.3%）、認証問題（16.5%）、IDOR/アクセス制御（15.8%）が続きます。

主要な脆弱性タイプ別の内訳は以下の通りです。

脆弱性タイプ	提案数	脆弱性判定数	検出率
IDOR/アクセス制御	241	38	15.8%
XSS	131	17	13.0%
CSRF	110	17	15.5%
認証問題	91	15	16.5%
セキュリティ設定ミス	75	13	17.3%
パストラバーサル	61	10	16.4%
ビジネスロジック	24	6	25.0%

注目すべきは誤検知の質です。ハルシネーション（根拠のない報告）は ゼロ でした。すべてのFPには根拠のある証拠が含まれており、人間の監査者でも同様の判断ミスをしうるケースばかりでした。

3. 攻め：ClaudeがFreeBSDカーネルRCEを完全攻略

3-1. CVE-2026-4747の概要

2026年3月26日、FreeBSDはセキュリティアドバイザリ FreeBSD-SA-26:08.rpcsec_gss を公開しました。カーネルモジュール kgssapi.ko のRPCSEC_GSS認証処理にスタックバッファオーバーフローの脆弱性があり、NFSサーバー経由でリモートからカーネルコード実行が可能です。

発見者として「ニコラス・カーリニ氏、Claudeを使用、Anthropic」がクレジットされています。この脆弱性は AIによって発見された ということです。

脆弱性の根本原因は単純です。svc_rpc_gss_validate() 関数が128バイトのスタックバッファにRPCヘッダを再構築する際、クレデンシャルボディのサイズを チェックせずにコピー していました。修正パッチ（14.4-RELEASE-p1）では境界チェックが追加されました。

  int32_t rpchdr[128 / sizeof(int32_t)];  // 128バイトのスタックバッファ

  // ... 32バイトの固定ヘッダ書き込み後 ...

  if (oa->oa_length) {
+     // 修正パッチ：境界チェックを追加
+     if (oa->oa_length > sizeof(rpchdr) - 8 * BYTES_PER_XDR_UNIT) {
+         client->cl_state = CLIENT_STALE;
+         return (FALSE);
+     }
      // 残り96バイトのスペースに対して、最大400バイトまでコピーされる
      memcpy((caddr_t)buf, oa->oa_base, oa->oa_length);
  }

影響を受けるバージョンは FreeBSD 13.5（p11未満）、14.3（p10未満）、14.4（p1未満）、15.0（p5未満）です。

3-2. AIによるエクスプロイト開発の全容

脆弱性の公開3日後の3月29日、セキュリティ研究者がClaudeにエクスプロイト開発を依頼しました。

結果は驚異的でした。 約8時間（うちClaudeの稼働時間は約4時間） で、フルリモートカーネルRCEエクスプロイトが完成しました。人間からの指示は合計45回で、その多くは簡単な修正やヒントでした。Claudeは 2つの異なる戦略 でエクスプロイトを開発し、どちらも 初回で動作 しました。

エクスプロイトは15ラウンドの攻撃で構成されます。各ラウンドでNFSサーバーとフレッシュなKerberos GSSコンテキストを確立し、オーバーサイズのRPCSEC_GSSクレデンシャルを送信してスタックオーバーフローを引き起こします。

ラウンド	内容
1	ROPチェーンで pmap_change_prot() を呼び出し、カーネルBSSセクションをRWX（読み書き実行可能）に変更
2〜14	1ラウンドあたり32バイトずつ、合計416バイトのシェルコードをBSSに書き込み
15	残り16バイトを書き込み、シェルコードにジャンプ

シェルコードは kproc_create() で新しいカーネルプロセスを生成し、kern_execve() で /bin/sh に変換、P_KPROC フラグをクリアしてユーザーランドに遷移するという手順で、 uid 0（root）のリバースシェル を確立します。

全15ラウンド、所要時間は約45秒です。

"To our knowledge, this is the first remote kernel exploit both discovered and exploited by an AI."
（私たちの知る限り、これはAIによって発見され、かつAIによってエクスプロイトが開発された初のリモートカーネルエクスプロイトです。）

3-3. Claudeが自律的に解決した6つの課題

このエクスプロイト開発で特筆すべきは、Claudeが以下の6つの技術的課題をほぼ自律的に解決したことです。

1. ラボ環境の構築

FreeBSD VM、NFSサーバー、Kerberos KDCの設定を指示。RPCSEC_GSS認証が必要なため、完全なKerberos環境が前提条件でした。

2. マルチパケット配送戦略

400バイトのクレデンシャルサイズ制限（XDRレイヤのMAX_AUTH_BYTES）で432バイトのシェルコードを配送するため、15ラウンドに分割する戦略を考案しました。

3. クリーンなスレッド終了

各ラウンドの最後に kthread_exit() を呼び出してNFSワーカースレッドを正常終了させ、カーネルパニックを回避しました。

4. オフセットのデバッグ

リターンアドレスの初期仮定（クレデンシャルボディのバイト168）が32バイトずれていることを、De Bruijnパターンとクラッシュダンプ分析で特定し修正しました。GSSヘッダの16バイトコンテキストハンドルとXDRアラインメントが原因でした。

5. カーネルからユーザーランドへの遷移

カーネルスレッドにはtrapframeがないため直接 execve() を呼べないという問題を、kproc_create() → kern_execve() → P_KPROC フラグクリアという手順で解決しました。P_KPROC フラグが残っていると fork_exit() が kthread_exit() を呼んでプロセスを終了させてしまうため、このフラグのクリアも不可欠でした。

6. ハードウェアブレークポイントバグ

カーネルデバッガ（DDB）が過去のパニック時に設定したデバッグレジスタ（DR0〜DR7）が kproc_create() 経由で子プロセスに継承され、trap 1（デバッグ例外）でクラッシュする問題を、シェルコード内でDR7をゼロクリアすることで解決しました。

FreeBSD 14.xにはKASLR（カーネルアドレス空間配置のランダム化）が実装されておらず、int配列に対するスタックカナリアもありません。カーネルベースアドレスは 0xffffffff80200000 で固定されており、ROPガジェットのアドレスが一意に確定します。現代のLinuxカーネルと比較すると、エクスプロイト開発のハードルは低い環境でした。

4. AIセキュリティの現在地と今後

4-1. AIが得意なこと、まだ苦手なこと

2つの事例から、AIのセキュリティにおける強みと限界が見えてきます。

領域	評価
ロジックバグの発見	非常に得意（ビジネスロジック問題の検出率25%）
IDOR/認可不備の発見	得意（最多発見カテゴリ、38件）
脅威モデリング	得意（意図された機能とバグの区別が可能）
誤検知の抑制	良好（ハルシネーションによる報告はゼロ）
エクスプロイト開発	条件付きで可能（緩和策が少ない環境では成功）
メモリ安全性の問題	まだ弱い（ファジングが優位）

GitHub Security Labの統計では、SASTでは検出困難な IDOR/アクセス制御 がAIの最多発見カテゴリです。AIはコードの文脈と意図を理解した上で、「この操作はこのユーザーには許可されるべきではない」という判断ができます。これは従来のパターンマッチングでは困難でした。

一方で、FreeBSDのエクスプロイト事例は冷静に評価する必要があります。KASLRなし、スタックカナリアなしという条件は、1990年代のエクスプロイト開発環境に近いものです。現代のLinuxカーネルに対して同様の成果を出せるかは未知数です。

4-2. 防御こそAIを活用すべき

AIの攻撃能力が向上しているなら、防御側こそAIを積極的に活用すべきです。

GitHub Security Lab Taskflow Agentはオープンソースで公開されており、自分のプロジェクトに対して実行できます。GitHub Copilotライセンスがあれば、Codespaceを起動してコマンド1つで監査を開始できます。

重要なのは、AIを 人間のセキュリティ研究者の代替ではなく、補完として 位置づけることです。GitHub Security Labのデータでも、AIが発見した91件のうち最終的に報告されたのは19件（21%）でした。AIの出力を検証し、実際のリスクを判断するのは依然として人間の仕事です。

ただし、今回の事例が示しているのは、AIの「目」がこれまで見落とされてきたロジックバグを照らし出す力を持っているということです。SASTでは拾えない、人間でも見逃しやすい認可ロジックの不備を、AIが体系的に発見できる。この事実は、ソフトウェア開発におけるセキュリティレビューのあり方を変えていく可能性があります。

おわりに

ここまでお読みいただきありがとうございます。

2026年3月、AIとセキュリティの関係は新たな段階に入りました。GitHub Security Lab Taskflow Agentは、LLMが従来のSASTでは困難だったロジックバグやIDORを高い精度で発見できることを実証しました。Rocket.Chatの await 欠落による認証バイパス、Outlineの権限昇格、ECサイトのPII漏洩など、いずれも人間でも見逃しやすい脆弱性ばかりです。

一方で、ClaudeによるFreeBSDカーネルエクスプロイトの開発は、AIが複雑な攻撃チェーンを自律的に構築できることを示しました。KASLR非搭載という条件付きではあるものの、発見から攻撃までをAIが一貫して実行したという事実は重いものです。防御側にとっては、AIのセキュリティ活用を加速させる必要性がこれまで以上に高まっています。

AIが脆弱性を見つけ、AIが脆弱性を突く。この現実を前提として、どう向き合い、どう活用するかが問われる時代になりました。

ではまた、お会いしましょう。

参考リンク

GitHub Security Lab

• How to scan for vulnerabilities with GitHub Security Lab's open source AI-powered framework - GitHub Blog
• seclab-taskflows - GitHub
• seclab-taskflow-agent - GitHub

CVE-2026-4747（FreeBSD カーネルRCE）

• MAD Bugs: Claude Wrote a Full FreeBSD Kernel RCE - Calif
• CVE-2026-4747 Write-up - Calif Publications

脆弱性アドバイザリ

• Rocket.Chat CVE-2026-28514 - GitHub Advisory
• Outline CVE-2025-64487 - GitHub Advisory
• WooCommerce CVE-2025-15033 - GitHub Advisory
• Spree Commerce CVE-2026-25758 - GitHub Advisory