AI ショッピング・アシスタントの脆弱性：トラフィック傍受による RCE の恐れ

AI Shopping Assistant Vulnerabilities Enable Remote Code Execution on Retailer’s Servers

2026/08/31 gbhackers — 米国の大手小売企業 (社名非公開) の AI ショッピング・アシスタントの脆弱性を悪用することで、一般向けモバイル・アプリケーションを通じて、同社のバックエンド・インフラ上でリモート・コード実行 (RCE) が可能になることを、セキュリティ研究者が実証した。Rein Security の共同創業者兼 CTO である Netanel Rubin と研究者の Dan Avraham は、“Bye Bye AI” と題する研究成果を Black Hat の講演で発表しており、8月31日 (月) の正午 (米国東部時間) に開催される PWN コミュニティのライブ Ask Me Anything (AMA) セッションでは、この研究について議論される予定である。

AI ショッピング・アシスタントの脆弱性

今回の攻撃シナリオで明らかになったのは、モバイル・アプリケーションの制御／AI ガードレール／バックエンド・エージェントの機能に存在する脆弱性を組み合わせることで、重大な侵害に至る経路が形成される可能性がある点だ。

社名非公開の小売企業をシナリオの標的にする前に、Rubin と Avraham は Kroger／Instacart／Amazon Alexa／Walmart Sparky／Albertsons の 5 種類の AI 小売アシスタントを評価した。単純に見える質問を介してアシスタントの基盤としての検索エンジン／Retrieval-Augmented Generation (RAG) ／独立した意図分類レイヤーのいずれが使用されるのかが調査された。

たとえば、対象となる小売業がアボカドを販売しているかと尋ねると、ショッピング関連のクエリを使用してボットによる商品検索が動作する。その一方で、ショッピングとは無関係なスペイン語の挨拶 “Como estas?” を使用して、ショッピング以外のプロンプトに対する各アシスタントの処理方法もテストした。

その結果、各アシスタントのアーキテクチャには違いがあり、一部はキーワード検索インターフェイスのように動作していたが、それ以外では会話形式での応答／リクエストの拒否／基盤モデルへ到達する前のブロックなどの動作が確認された。なかでも、モデルへ到達する前にリクエストを拒否する動作はきわめて重要であり、対象となる小売企業のアシスタントでは、ショッピングと無関係なプロンプトを拒否するよう設計された、意図分類ゲートウェイが使用されていた。

この小売企業のアシスタントはモバイル・アプリケーションだけで利用可能であり、Google Vertex AI Search を使用していたことから、研究者はブラウザ・ベースのサービスではなく Android アプリケーションからのトラフィックを分析する必要があった。

研究者はアプリの通信を Burp Suite 経由にさせたが、暗号化されたモバイル・トラフィックの傍受を防止するセキュリティ対策である SSL 証明書ピンニングにより阻まれた。そのため研究チームは、Frida を使用して実行中のアプリケーションの証明書検証関数をインターセプトし、プロキシ証明書を受け入れるよう強制した。

これによりトラフィックを復号したところ、ユーザー向けチャット・インターフェイスには公開されない隠し入力フィールドが、アプリケーションのリクエストに含まれていることが明らかになったが、表示されているチャット・フィールドの入力は、ショッピングの意図を判定する分類器によりフィルタリングされていた。

その一方で、別の検索クエリ・フィールドはフィルタリングが大幅に少ない状態でバックエンドへ送信されており、チャット・インターフェイスで拒否されたプロンプトであっても、この検索フィールドを通じて見かけ上の商品検索として送信することが可能だった。研究者は、「一貫したフィルタリングが適用されていない入力が 1 つ存在するだけで、ゲートウェイ全体が突破される」と述べている。

Rubin と Avraham は、この脆弱な検索フィールドを悪用するプロンプト・インジェクションが、漏洩を防止するための制限を回避するとしている。ただし、システム・プロンプトを直接要求するのではなく、アクロスティック (折句) の生成やテキストの並べ替えといった、ショッピングをテーマとするリクエストを、彼らは行った。その結果、漏洩した指示から、AI アシスタントが Python コードを記述／実行できることが判明した。

この機能が単なる模倣ではなく、実際に動作していることを確認するため、研究者はゼロ除算例外を発生させるコードを与えた。それに対して、このアシスタントは Python の ZeroDivisionError を返し、実際に稼働しているインタープリターでコードが実行されたことが確認された。

さらに、時間遅延を使用してコード実行をテストしたところ、通常の応答には約 5.5 秒かかった一方で、10 秒／20 秒の遅延を要求するコマンドでは、それぞれ約 11.4 秒／26.8 秒を要し、これらの時間差からバックエンド・インフラ上で実際にコードが実行されたことが確認された。さらに研究者は、RCE の達成後にバックエンド・コンテナの環境変数へアクセスできたことも指摘している。

研究チームは、復号されたアプリケーション・リクエスト内から有効な Google Maps API キーを発見した。報告によると、これらのキーには許可されたアプリケーション／リファラー／送信元の場所に関する制限がないため、それを悪用する攻撃者が、小売企業に料金を発生させる恐れがある。

Rein Security は 2026年3月に、これらの調査結果を小売企業へ開示した。小売企業は RCE の動作を意図された機能として分類し、報告を情報提供として扱った。しかし、90 日間の開示期間を経て研究結果が公開された時点でも、これらの問題は未解決の状態だと小売企業は述べている。

Google Vertex AI Search を採用した大手小売企業の AI ショッピング・アシスタントアプリを対象としたセキュリティ解説です。アプリの通信暗号化を迂回してトラフィックを分析した結果、意図分類器によるチェックを免れる隠しフィールドが判明しました。この実装上の不備が悪用された場合、制御の回避／システムプロンプトの漏洩／バックエンド上での任意の Python コード実行 (RCE) ／環境変数や API キー等の重要情報奪取といった深刻な被害につながります。入力値に対する一貫した検証の徹底／不要な機能の無効化／強力な暗号化ピンニングの実装など、多層防御の再構築が求められます。