私たちは「脆弱性自動販売機」を作りました。AIトークンを投入すれば、ゼロデイ脆弱性が手に入ります。

AIは脆弱性調査の進め方を変えつつありますが、議論の大部分は依然として理論的なレベルにとどまっています。つまり、モデルが将来的に何ができるようになるかという点に焦点が当てられており、現時点で実際にどのような脆弱性を見つけ出せるかという点についてはあまり語られていないのです。

私たちは、より実践的な疑問に答えたいと考えました。すなわち、現在すでに利用可能なモデルを用いて、本番環境のソフトウェアにおいて、実際に悪用可能な脆弱性を発見する上で、AIはどこまで貢献できるのか、ということです。

本記事では、Intruderのチームが、LLM（大規模言語モデル）を活用し、コードスキャンフレームワークとMythos以前の現行モデルを併用して、新たな脆弱性を発見している手法について詳しく解説します。

ここでは、30万人以上のユーザーを抱えるWordPressプラグインで発見した、リモートかつ多段階のSQLインジェクションゼロデイ脆弱性を例に解説します。このプロセスは、発見から悪用に至るまで完全に自動化されており、人間の介入は一切ありません。

焦点となる問題：なぜAIをコードベース全体に向けるだけではうまくいかないのか

AIとコードスキャナーを組み合わせる際の大きな問題は、「焦点」です。LLMは、コードの小さな断片や特定の問題の説明を受け取り、興味深い解決策を見つけることに優れています。しかし、大規模なコードベースに対してセキュリティ上の問題を見つけ出すよう指示すると、リポジトリ内のすべてのファイルを取り込もうとしてしまいます。

これはトークンの消費が激しいだけでなく、精度の面でも悪影響を及ぼします。モデルが処理の半分を過ぎる頃には、コンテキストが無関係なコードで埋め尽くされ、実際に探しているバグはノイズの中に埋もれてしまいます。

複数のステップを連鎖させる必要があるより複雑なバグの場合、適切なコンテキストをメモリ内に保持したり、必要に応じて賢く取得したりするために、フレームワークに依存することになります。私たちの経験上、それによって得られるのは、現実的で興味深いバグではなく、質の低い出力になってしまいます。

従来のコードスキャンフレームワークは、すでにこの問題を解決しています。 私たちは「プログラムスライス」と呼ぶ手法を採用しています。これは、IDE や LSP ツールが「実装を検索」やコールグラフといった機能を使って、現在の関数から呼び出されているすべての関数を見つけるのと同様の仕組みです。これらは成熟し、十分にテストされたツールであり、コンテキストが希薄化するという問題を完全に回避しています。

当社のパイプライン：コードベースから実用的なエクスプロイトまで

当社は、コードベースを取り込み、コードスキャンエンジン（Joernを使用）で処理し、各発見事項に関連するコードのスライスを生成し、LLMを使用して問題をトリアージして悪用するパイプラインを構築しました。 この設計は、nooperatorによるSliceの取り組みに着想を得たものですが、CodeQLの代わりにJoernを採用し、対象とする特定の脆弱性クラスに対応できるよう、スライシングアルゴリズムを独自に設計しました。 

このパイプラインをWordPressのトップ200プラグインに適用しました。これらはすでにバグ報奨金研究者によって徹底的に精査されているコードであるため、そこで実際に脆弱性を見つけ出せれば、このプロセスが熟練した人間と互角に戦えることを意味します。

まず、Joernはコードベースに対して、大まかに「興味深い」パターンをフラグ付けするように設計されたルールを実行します。これは、ルールが具体的すぎてバグを見逃す可能性を避けるため、意図的に緩く設定されています。いずれにせよ、後でトリアージエージェントによるフィルタリングが行われるため、誤検知（false positive）を多少許容しても問題ありません。

この実験では、認証不要のWordPressプラグインの攻撃対象領域を特定することを目的としていたため、Joernに、スクリプトがユーザー入力の影響を受ける可能性のあるすべての箇所（RESTルート、テンプレートフック、nopriv AJAX呼び出しなど）を特定させました。

各WordPressフックについて、Joernは「スライス」を生成します。これは、フックが呼び出す関数、その関数が呼び出すすべてのメソッド、そしてその連鎖を下っていくすべての要素を含みます。 基本的なテイント追跡により、既知の安全なサニタイザーを通過するSQLやXSS入力など、明らかに安全な関数は除外されます。コードの実行が安全であることを静的に検証できる場合は、LLMへの処理対象から除外します。

各スライスは、軽量なトリアージモデル（当社のテストではSonnet）に送られ、明らかに無関係なもの（例えば、公開を意図しており副作用のないフックなど）がフィルタリングされます。

残った部分は、より高負荷なモデル（Opus）に送られ、悪用可能性が評価されます。この際、関連する呼び出しコンテキスト全体がメモリ内に保持されるため、無関係なソースコードをくまなく検索する必要はありません。

悪用可能と判断されたものは、最終的なエクスプロイト生成エージェントに送られ、エクスプロイトの作成が試みられます。このエージェントは、ターゲットを絞った検索で関連コードを見つけられるため、（必要に応じて）再び完全なソースコードにアクセスでき、開発中にテストを行うためにソフトウェアを実行するDockerコンテナを起動することもできます。

最初の脆弱性：人気のあるWordPressプラグインにおけるブラインドSQLインジェクション

このパイプラインが最初に検出したバグは、Creative MailプラグインのSQLインジェクション脆弱性であるCVE-2026-3985でした。この脆弱性が注目された理由はいくつかあります： 

• 影響度が非常に高く、攻撃者にデータベースへの読み取りアクセス権（管理者アカウントのハッシュやシークレットトークンを含む！）を与える

• 悪用するには複数のリクエストを連鎖させる必要があり、従来のツールでは検出されにくい

• 根本的な原因は、コード内のミスによって、開発者自身の静的解析ツールから隠されていた

悪用には、Creative Mailに加えてWooCommerceがインストールされている必要がありますが、WooCommerceはWordPressを利用する一般的な理由の一つ（アクティブインストール数は700万以上）であるため、この組み合わせは一般的です。

攻撃者は、動作する概念実証（PoC）を即座に作成し、問題の存在を確認するためのチェック機能と、データベースからパスワードハッシュを抽出できる完全な抽出手法を実装しました。

この脆弱性は、CleanTalk Inc.のDmitrii Ignatyev氏によっても独立して発見され、同氏はWordfenceに報告しました。

このプラグインは審査待ちのためWordPressストアから削除されています。WooCommerceとCreative Mailを併用している場合は、パッチが提供されるまでCreative Mailを無効にしてください。

技術的な詳細については、当社のレポートをご覧ください。

脆弱性の発見は加速しています。検知技術もそれに追いつかなければなりません

これは、このパイプラインが発見した最初の脆弱性に過ぎません。すでにさらに多くの脆弱性を発見しており、影響を受けるベンダーに報告しています（これらはまだ開示段階にあります）。 

脆弱性研究において、AIが果たす役割は明らかに拡大しており、現在の課題は、既存のモデルを最大限に活用するためのフレームワークを構築することです。攻撃者もすでに同様のツールを使用してAIに高精度な入力を与えているため、ここで実証したような速度上の優位性は、防御側だけに限った話ではありません。

当社の「自動検出システム」によって発見された脆弱性は、Intruderプラットフォームの検知チェック項目として組み込まれるため、次回のスキャンでそれらを検出して報告します。

Intruderを無料で今すぐお試しください。

著者： 

サム・ピジー（Sam Pizzey）、Intruder セキュリティエンジニア

サム・ピジーは、Intruderのセキュリティエンジニアです。以前はリバースエンジニアリングにややこだわりすぎたペネトレーションテスターでしたが、現在はアプリケーションの脆弱性をリモートで大規模に検出する方法に注力しています。

Intruderによる提供・執筆。