プロンプトが「シェル」になる日

AIエージェントに「ファイルを検索して」と入力するだけで、サーバー上の任意のコードが実行される——そんな脆弱性が、広く使われているLLMフレームワークで発見された。

2026年5月7日、Microsoftは Semantic Kernel フレームワークに存在する2件の深刻な脆弱性（CVE-2026-26030 と CVE-2026-25592）を公開した。どちらも、プロンプトインジェクションという「テキスト操作」が起点となり、最終的にホストマシン上での**リモートコード実行（RCE）**に至るという攻撃パスをたどる。

「プロンプトインジェクションはコンテンツの問題」というのが今まで多くの開発者の認識だった。しかし今回の脆弱性は、その前提を大きく覆す。

情報源: Microsoft Security Blog「When prompts become shells: RCE vulnerabilities in AI agent frameworks」（2026年5月7日発表）

発表内容の概要

Microsoftが公開したブログ記事のタイトルは「When prompts become shells（プロンプトがシェルになるとき）」。この一文が今回の脆弱性の本質を正確に言い表している。

Semantic Kernel は、LLMとツール（関数）を組み合わせたAIエージェントを構築するためのMicrosoftのOSSフレームワークだ。Python版と.NET版が広く使われており、Azure OpenAI / OpenAI / Claude などの複数のモデルと連携できる。RAGエージェントや自律型エージェントの開発に採用する企業が急増している。

今回の2件の脆弱性は、どちらも「AIモデルがツールを呼び出す経路」を通じて攻撃が成立する点が共通している。攻撃者がプロンプトインジェクションのベクターを持っていれば、ユーザーの入力やRAG文書内の悪意あるテキストから、ホスト環境の完全な制御を奪える可能性がある。

2件のCVEの技術的な仕組み

CVE-2026-26030：eval()に流れ込むフィルタ式（CVSS 9.8）

影響バージョン: Python SDK semantic-kernel < 1.39.4

InMemoryVectorStore はSemantic Kernelのデフォルトのベクターストアのひとつだ。検索クエリにフィルタを指定できる機能があり、内部でフィルタ条件を Python の lambda 式として組み立てていた。問題は、その lambda 式を eval() で実行していた点にある。

フィルタ式はユーザー入力（または AIモデルが生成したパラメータ）から構築されるため、悪意ある文字列が混入すると、任意の Python コードが eval() に渡されてしまう。

# 脆弱な内部動作（概念的な例）
filter_lambda = f"lambda item: item['city'] == '{user_input}'"
result = list(filter(eval(filter_lambda), data))

user_input の部分にコードを注入すると、そのコードがホストの Python 環境で実行される。Microsoftの実証では、この脆弱性だけで calc.exe の起動が可能だった。ブラウザエクスプロイトも、悪意ある添付ファイルも、メモリ破壊も不要だ。

攻撃が成立する条件は2つ:

1. プロンプトインジェクションのベクター（ユーザー入力・RAG文書・外部APIレスポンスなど）が存在する
2. Search Plugin が InMemoryVectorStore のデフォルト設定で公開されている

修正内容: バージョン 1.39.4 で、eval() を使わない安全なフィルタ評価に置き換え。

CVE-2026-25592：AIツールとして公開されてしまったファイル書き込みメソッド

影響バージョン: .NET SDK Microsoft.SemanticKernel.Plugins.Core < 1.71.0

SessionsPythonPlugin は、Azure Container Apps のサンドボックス環境でPythonコードを実行するためのプラグインだ。サンドボックス内で生成したファイルをホストにダウンロードする DownloadFileAsync メソッドが用意されており、これが [KernelFunction] 属性で装飾されていた。

[KernelFunction] はSemantic Kernelがそのメソッドを 「AIモデルが呼び出せるツール」 として公開するデコレーターだ。つまり、AIモデルが自らの判断でこのメソッドを呼び出すことができる。

さらに、DownloadFileAsync が受け取る localFilePath パラメータには、ディレクトリの正規化もバリデーションも実装されていなかった。その結果、AIモデルが悪意あるプロンプトの指示に従って任意のパス（例：../../etc/passwd や C:\Windows\System32\config\SAM）を指定した場合、ホストの任意のファイルを上書きできてしまう。

# 脆弱な設計の概念図
[KernelFunction]  // ← AIモデルがこのメソッドを自由に呼び出せる
public async Task DownloadFileAsync(
    string remoteFilePath,
    string localFilePath  // ← パス検証なし：AIが自由に指定できる
)

修正内容: バージョン 1.71.0 で、DownloadFileAsync の [KernelFunction] 属性を除去。AIモデルが自律的にこのメソッドを呼び出せなくなった。

実務への影響：まず確認すること

即時対応手順

Python の場合:

pip install --upgrade "semantic-kernel>=1.39.4"

アップグレード後、pip show semantic-kernel でバージョンを確認する。コンテナや仮想環境を使っている場合は、イメージのリビルドも忘れずに行う。

C# / .NET の場合:

NuGet でパッケージを更新する:

dotnet add package Microsoft.SemanticKernel.Plugins.Core --version 1.71.0

または .csproj を直接編集:

<PackageReference Include="Microsoft.SemanticKernel.Plugins.Core" Version="1.71.0" />

アーキテクチャの再設計は不要

Microsoftは「エージェントのアーキテクチャを書き換える必要はない。バージョンアップでセキュリティ修正が適用される」としている。ただし、InMemoryVectorStore を本番環境で使用している場合は、代替のベクターストア（Azure AI Search, Qdrant, Chromaなど）への移行を検討することも推奨されている。

設計上の教訓：プロンプトインジェクションは「コンテンツ問題」ではない

今回の脆弱性が示す最も重要な教訓は、**「LLMへの入力経路は、コード実行の経路になりうる」**という点だ。

従来のWebアプリケーション開発者は、SQLインジェクションやXSSを防ぐためにユーザー入力を信頼しないという原則を持っている。LLMを組み込んだアプリケーション開発でも、同じ原則が適用される。

具体的には:

1. ツールの公開は最小限に

[KernelFunction] のようなデコレーターでメソッドを公開する際は、「このメソッドがAIモデルに悪用されたら何が起きるか」を常に検討する。ファイル書き込み・外部コマンド実行・ネットワーク送信につながるメソッドは、原則として公開しないか、厳格な入力バリデーションを実装する。

2. eval() / exec() はLLMパラメータの通り道に置かない

eval() や exec() で動的コードを評価する設計は、LLMエージェントのコンテキストでは特に危険だ。フィルタ式や計算式が必要な場合は、事前定義された許可リスト方式か、安全な式評価ライブラリ（simpleevalなど）を使う。

3. プロンプトインジェクションを「外部入力」として扱う

RAGで取り込む文書も、外部APIのレスポンスも、ユーザーのメッセージも——すべてが信頼できない入力だ。LLMがそれらを処理してツールを呼び出す場合、呼び出し先のツール側でも入力バリデーションを行う（多層防御）。

公式情報の確認ポイント

今後の関連情報は以下の公式チャンネルで確認できる:

• Microsoft Security Blog: AIエージェントフレームワークの脆弱性情報を定期的に公開している。semantic-kernel タグで追うと効率的。
• NVD（米国NIST脆弱性データベース）: CVE-2026-26030 と CVE-2026-25592 のページをブックマークして、ステータス変化（修正パッチの確認・スコア更新）を追う。
• semantic-kernel GitHub リリースページ: バージョン変更のチェンジログで、セキュリティ修正を確認できる。

よくある質問（FAQ）

FAQ

Semantic Kernel RCE脆弱性 FAQ

CVE-2026-26030 / CVE-2026-25592に関するよくある質問

Q InMemoryVectorStore を使っていないPython SDKのユーザーも影響を受けますか？

A

CVE-2026-26030 の直接的な影響は受けません。この脆弱性は InMemoryVectorStore とそのデフォルトフィルタ機能の組み合わせに起因します。ただし、他のコンポーネントにも潜在的な問題がある可能性があるため、最新バージョンへのアップグレードは推奨されます。

Q Azure OpenAI や Azure AI Foundry を通じて使っている場合も影響を受けますか？

A

Semantic Kernel はクライアント側のフレームワークです。どのLLMプロバイダー（Azure OpenAI、OpenAI、Claude など）を使っていても、脆弱なバージョンのSDKをローカルまたはサーバーで動かしている場合は影響を受けます。プロバイダー側の問題ではなく、SDKのバージョンが重要です。

Q 本番環境で InMemoryVectorStore を使っていた場合、侵害されていないか確認する方法はありますか？

A

ログに不審なコマンド実行やファイルアクセスのパターンがないか確認してください。また、ホスト上の予期しないプロセス起動（特にエージェント実行中の時刻帯）や、サーバーへの予期しない接続記録も確認ポイントです。具体的な侵害確認はインシデントレスポンス担当や専門家に相談することを推奨します。

Q プロンプトインジェクション対策として、入力フィルタリングだけでは不十分ですか？

A

不十分です。プロンプトインジェクションを完全に検出・遮断するフィルタリングは現時点では技術的に困難です。入力フィルタリングに加えて、ツールの最小公開原則・eval()などの危険関数をLLM入力経路から排除する設計・ツール呼び出しのサンドボックス化・異常検知、という多層防御が必要です。

Q 今回の脆弱性はLangChain や LlamaIndex など他のフレームワークでも同様の問題がありますか？

A

今回Microsoftが開示したのはSemantic Kernel固有の実装上の問題です。ただし、「ユーザー入力がツールパラメータとして安全に処理されているか」「evalを使った動的評価がないか」「KernelFunctionとして公開しているメソッドの権限が適切か」という問いは、他のフレームワークでも同様に確認すべきです。LangChainやLlamaIndexを使っている場合も、同様の観点でコードレビューを行うことを推奨します。

まとめ

今回の脆弱性が示したのは、「LLMフレームワークも従来のソフトウェアと同じく脆弱性を持つ」という当然の事実だ。しかし、その攻撃パスは従来のWebアプリとは異なる——自然言語のプロンプトがツールパラメータを経由してコード実行につながるという、LLM特有の経路がある。

対応は明快だ。まずバージョンを確認し、影響バージョンを使っていれば即アップグレード。その上で、ツールの公開範囲・eval系関数の使用・入力バリデーションの多層化という設計原則を改めて点検してほしい。

セキュリティパッチを当てるだけで防げる問題と、アーキテクチャレベルで考える問題は分けて考えるべきだ。前者は今すぐできる。後者は次のスプリントの設計課題として取り上げる価値がある。

次に読むおすすめ

AIエージェントの脆弱性について「仕組みは分かった、次は実際にどう設計すればいいのか」と思った方へ——LLMアプリの安全設計の実践的な考え方を、もう少し踏み込んでまとめた記事をnoteで公開しています。

noteで続きを読む → AI時代の開発者が知っておくべきセキュリティ設計の考え方

参考リンク

• Microsoft Security Blog: When prompts become shells: RCE vulnerabilities in AI agent frameworks（2026年5月7日）
• NVD: CVE-2026-26030（InMemoryVectorStore / Python SDK）
• NVD: CVE-2026-25592（SessionsPythonPlugin / .NET SDK）
• GitLab Security Advisory: CVE-2026-26030
• semantic-kernel GitHub Releases