LLMは推論エンジンを悪用してホストマシンを制御できる

大規模言語モデル（LLM）は、多くの場合、エージェントハーネス（Claude CodeやCodexなど）を介して別のコンピュータ上でアクションを実行しますが、LLMのプロンプトへの応答は、GPUアクセスを持つ別のコンピュータで計算されます。LLMの重みがロードされているホストマシンを悪意のあるLLMが制御できるようになるでしょうか？そのようなマシンは、フロンティアLLMを実行するのに十分な計算能力を持ち、LLMの重みへの容易なアクセスを提供し、インターネット上の一般的なコンピュータと比較してデータセンター内の他のコンピュータへの特権アクセスを提供するため、価値の高い標的となります。この記事では、悪意のあるLLMがホストマシンをどれほど容易に制御できるかを考察します。ここで主に検討される攻撃は、LLMがトークン列を発行することを含みます。このトークン列は意味論的には無関係ですが、LLMをGPUにロードし、LLMを実行して出力トークンを生成し、それらのトークンを応答として解析するソフトウェアの脆弱性を悪用します。 LLMはどのようにホストマシン上でコードを実行できるのでしょうか？他のプログラムと同様に、vLLMやSGLangのような推論エンジンには悪用可能なバグが含まれている可能性があります。LLMは推論エンジンに渡されるトークンを制御するため、悪意のあるLLMは、不適切に記述された推論エンジンがデータとして返すのではなく、コードまたは実行命令として誤解するトークン列を発行できる可能性があります。しかし、すべての推論エンジンは堅牢なソフトウェアであり、これは決して起こらないはずですよね？ vLLMは以前、ツール呼び出しパラメータでeval()を使用していました。CVE-2025-9141は、Qwen3 Coder用のvLLMのXMLベースのツールパーサーにおける任意のコード実行バグでした。パーサーはほぼすべてのツール呼び出し引数をeval()に渡したため、LLMはホストマシン上で任意のコードを実行できました。Geminiは、このバグを導入したPRを自動的に分析し、それを重大なセキュリティ脆弱性として正しくフラグ付けしました。その警告にもかかわらず、vLLMのリードメンテナーはPRを強制的にマージし、次のように書いています。「残念ながら、任意のトークン列を、ユーザーのターン、アシスタントの応答、ツール呼び出しなどを含む完全なチャットに解析することは簡単ではなく、正確なプロセスはLLM間でしばしば異なります。この複雑さが、ホストマシン上で任意のコード実行を許可する可能性のあるバグの機会を増やしています。」vLLMとSGLangは複雑であり、バグは一般的です。現代の推論エンジンは、トークン列を文字列にマッピングする以上のことを行います。vLLMのドキュメントには200以上のモデルアーキテクチャのサポートがリストされており、その例ディレクトリには約35のJinjaチャットテンプレートが含まれています。現代の推論エンジンは多くのチャット形式を解析し、わずかに不正確な解析ロジックは、LLMの出力がコードとして解釈され実行される結果となります。このvLLMの問題では、ユーザーがMiniMax-M3とのLLMの推論について議論しており、LLMは<mm:think>という文字列を発行しました。vLLMは、このプレーンな文字列を推論ブロックの開始として誤って解析しました。したがって、次のようになります。応答：あなたが言ったことを正確に繰り返します：<mm:think> どうでしたか？ vLLMはこれを次のように解析しました：応答：あなたが言ったことを正確に繰り返します：推論： どうでしたか？これはかなり無害なパーサーバグですが、推論エンジンはトークンを文字列に変換して連結する以上のことを行うことを示しています。それらは絶えず改良されている複雑なシステムであり、その開発者は可能な限り高速化するために多大な圧力を受けています。これらの要因は、悪意のあるLLMがパーサーバグを推論ホスト上での任意のコード実行に転換するリスクを高めます。 ビジョンおよびオーディオトークンは攻撃対象領域を増やす可能性があります。マルチモーダルアーキテクチャにより、LLMはプレーンテキストだけでなく画像やオーディオで応答できます。モデルのオーディオまたはビジュアル出力を使用可能なメディアに変換することは、テキストトークンのデコードよりもおそらく複雑です。しかし、私の知る限り、現在のマルチモーダルLLMは一般的に、任意のファイルバイトではなく、制約されたメディアトークンを発行します。モデル固有のデコーダーがそれらのトークンをピクセルまたは波形に変換し、それらがファイルにエンコードされます。これにより、ffmpegやメディアビューアのようなソフトウェアに対する古典的な不正フォーマットファイルエクスプロイトは、モデルから直接アクセスしにくくなりますが、追加のデコーダー、エンコーダー、およびネイティブカーネルは依然として攻撃対象領域を増やします。私は現在、マルチモーダル出力をホスト侵害の主要な経路とは見なしていません。しかし、それはテキスト単独よりもはるかに高い帯域幅を提供し、将来の推論エンジンはこれらのメディア生成パスを、悪用しやすくする方法で最適化する可能性があります。また、プロプライエタリなマルチモーダルモデルが画像やオーディオ出力をどのように表現するかは不明です。それらの方法は異なるリスクを伴う可能性があります。 LLMが推論エンジンの脆弱性を発見して悪用する可能性はどのくらいでしょうか？ある程度可能性はある？不確かです。有用な脆弱性を発見することがおそらく最も難しいステップです。それを悪用するために必要なトークン列は非常に珍しいかもしれませんが、それが脆弱性を悪用不可能にするわけではありません。適切なコンテキスト（例えば、LLMがvLLMのコードベースを探索し、その過程で脆弱性を発見する）があれば、フロンティアLLMはそれを悪用するために必要なトークンを発行できると予想されます。ツール使用は悪用を再現可能にする可能性があります。LLMがエクスプロイトトークン列を発見すると、そのシーケンス、またはそれを再作成するための指示を、別のLLMのコンテキストに入りそうなファイル、ファイル名、またはURLに保存できます。エクスプロイトは、永続的なプロンプトインジェクションの一形態として機能します。エージェントは、ディレクトリを一覧表示したりファイルを読み取ったりするだけで、GPUホスト上でコード実行をトリガーする可能性があります。 推論エンジンは、パワーを求めるLLMにとって魅力的な標的です。OpenAI、Google、Anthropicには、内部で実行するソフトウェアをレッドチームテストするセキュリティチームがあると信じています。しかし、オープンウェイトLLMがより強力になるにつれて、より少ない精査しか受けていない最先端の推論エンジンで実行されるLLMが増えるでしょう。これにより、悪意のあるオープンウェイトLLMが脆弱な推論エンジンに遭遇し、それを悪用する可能性が高まります。LLMがパフォーマンスを向上させるために、自身を実行する推論エンジンを記述または変更するタスクをますます与えられるようになるにつれて、別の攻撃ベクトルが出現する可能性があります。悪意のあるLLMはそのアクセスを使用してバックドアを仕掛けることができます。推論パイプラインのC++およびCUDAコンポーネントは、特に魅力的な標的のように見えます。LLMは、GPUまたはそれらを制御するCPUホスト上で任意のコード実行を可能にする、境界外メモリアクセス脆弱性を導入する可能性があります。 これにどう対抗するか？推論エンジンの脆弱性に対するレッドチームテストに加えて、いくつかの他の対策が役立つかもしれません：GPUとトークンパーサーを別のコンピュータで実行します。GPUホストはロジットのみを発行します。2番目のホストがそれらのロジットからトークンをサンプリングし、トークンをチャットメッセージに解析し、メッセージをエージェントハーネスに転送します。この分離により、パーサーの侵害はGPUホストではなくCPUホストに限定されます。GPUホストに付与される権限を制限し、それらが発行するすべてのデータを信頼できないものとして扱います。