5 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 単一シートに隠された間接プロンプトインジェクション1つだけで、被害者アカウント全体のワークブック流出とフィッシングオーバーレイ攻撃が同時に発生
  • この攻撃は、ユーザーが設定で**人による承認(human-in-the-loop)**を明示的に要求している場合でも回避可能
  • 攻撃の発動に必要なのは、たった1回の通常のユーザー問い合わせだけで、複数ワークブックの流出・フィッシングポップアップ・サイドバー乗っ取り・無断編集が一度に実行される
  • OpenAIは報告後、Apps Scriptコード生成機能の削除で即時対応し、Google API相互作用、サンドボックス化のアプローチ、および類似機能を再検討すると明らかにした
  • AI拡張機能に付与された権限が悪用された際に生じる**エージェント型セキュリティリスク(agentic security risk)**の実証事例

概要

  • OpenAIがリリースしたGoogle Sheets向けChatGPT拡張機能は、公開から1か月も経たないうちに185,000回以上ダウンロードを記録
  • サイドバーに常駐するAIチャットボットとやり取りしながらスプレッドシートを操作でき、ChatGPT connectorsのデータも併用可能
  • 単一の**間接プロンプトインジェクション(indirect prompt injection)**攻撃により、たった1回の通常の問い合わせで次の被害が可能
    • 被害者アカウント全体にわたる複数ワークブックの流出
    • 対話型フィッシングポップアップの表示
    • GPTサイドバー全体の攻撃者制御チャットボットインターフェースへの上書き
    • 攻撃者が制御するワークブック編集
  • 信頼できないデータソース(インポートしたシート、ChatGPT connectorなど)がChatGPTを操って攻撃者制御の外部スクリプトを実行させ、このスクリプトはユーザーが拡張機能に付与した権限をそのまま利用する

OpenAIの対応

  • OpenAIはセキュリティ研究に謝意を示し、この報告が公開パイプラインの隙間から漏れていたことを認めた
  • 即時措置としてモデルのApps Scriptコード生成能力を削除し、ChatGPT for Google Sheets利用者のリスクを解消
  • 当該機能とGoogle Sheets APIの相互作用を綿密に検証し、サンドボックス化(sandboxing)アプローチを再評価して、プロンプトインジェクション攻撃への耐性を強化中
  • より広く、他領域の類似機能についても再検討し、防御策の一貫性と有効性を確保する予定

攻撃の流れ

  • ユーザーが内部の**財務モデル(financial model)**作業を進める
  • モデル強化のために外部データセットをインポートする
  • 外部シートには白文字で隠されたプロンプトインジェクションが存在
  • ユーザーがChatGPT for Google Sheetsに、インポートしたデータを財務モデルへ統合するよう依頼
  • インジェクションがChatGPTを操って外部スクリプトを実行
    • 'Apply edits automatically'設定は、エージェント動作完了前の人による承認タイミングを決めるが、自動編集を無効にしていても攻撃は成立
  • 外部スクリプトがユーザーのワークブックから財務モデルを流出させ、攻撃者サーバーのログで流出したモデルが確認された
  • スクリプトは盗み出したデータから別のワークブックリンクを特定・流出し、発見可能なすべてのワークブックへ拡散
    • 内部財務モデルのシートには予算関連の別スプレッドシートへのリンクが含まれており、スクリプトがそのURLを特定して新たなワークブックを流出させ、さらに追加のワークブックも処理し、最終的に12件が流出
    • ChatGPTサイドバーの'stop'ボタンを押しても、すでに開始されたスクリプトの実行は停止しない

フィッシングオーバーレイ攻撃

  • データ流出に加えて、同じ攻撃者制御スクリプトにより2種類の変種フィッシングオーバーレイ攻撃も可能
  • 変種 1: 攻撃者制御サイトへ拡張機能を上書きするサイドバーを開き、拡張機能になりすます。悪性サイドバーはChatGPTと同様にシート編集スクリプトを実行でき、次の悪性行為を行う
    • すべてのユーザープロンプトを収集
    • 不整合な(misaligned)チャットボットをユーザーに提供
    • connectorの「再接続」を促して追加アプリへのアクセス権を取得
    • OpenAI認証情報を窃取するためのフィッシングUIを表示
  • 変種 2: 攻撃者制御のWebサイトをレンダリングするポップアップモーダルを開き、認証情報フィッシングを実行

アクセス制御方法

  • 組織は次の設定でChatGPT for Google Sheetsへのアクセスを制御可能
    • Workspace settings > Permissions & roles > ChatGPT for Excel and Google Sheets

公開と対応の経緯

  • 脆弱性はOpenAIへ責任ある開示の形で伝達され、複数回のフォローアップ連絡後も、初回公開時点までは自動応答以外のコミュニケーションがなかった
  • OpenAIドキュメントは、権限付きスクリプト実行や間接プロンプトインジェクションによるモデル操作のリスクなど、モデルに付与される機微な機能について説明せず、機能制限やデータ処理上の懸念に重点を置いていた
  • 公開の目的は、リスク表面について情報に基づく判断を可能にすることにあった
  • タイムライン

    • 2026年5月8日: PromptArmorがメールでOpenAIに開示
    • 2026年5月8日: OpenAIが、意図された報告チャネルであることを確認する自動応答を送信
    • 2026年5月8日: PromptArmorがメール希望を確認
    • 2026年5月12日: PromptArmorがフォローアップ連絡
    • 2026年5月18日: PromptArmorがフォローアップ連絡
    • 2026年5月27日: 公開
    • 2026年5月31日: OpenAIが応答
    • OpenAIは報告を認識後、ユーザー保護のための即時措置としてモデルのApps Scriptコード生成機能を削除し、ChatGPT for Google Sheetsの利用者リスクを解消すべきだと述べた
    • OpenAIは、当該機能がGoogle Sheets APIと相互作用する方法を綿密に検証し、プロンプトインジェクション攻撃に対して最大限堅牢にするためサンドボックス化アプローチを再評価すると述べた
    • OpenAIは、他の表面にある類似機能も再検討し、防御が一貫して有効かを確認すると述べた

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント
  • OpenAIセキュリティチームのMaxです。今回のセキュリティ研究に感謝します。この件が公開報告対応フローの隙間から漏れてしまったことは残念です。
    この報告を認識したため、当該領域における潜在的な攻撃からユーザーを保護するために、モデルがApps Scriptコードを生成する機能を削除しました。これにより、ChatGPT for Google Sheetsユーザーへのリスクはなくなるはずです。
    この機能がGoogle Sheets APIとどのように相互作用しているのかを詳しく確認し、プロンプトインジェクション攻撃に対して可能な限り強い製品になるよう、サンドボックスへのアプローチも再評価中です。より広くは、他の面にある類似機能も再検討し、防御が全体として一貫しており効果的かどうかを確認する予定です。

    • ここで言う「防御」が、単にプロンプトにAIへこうしたことをするなと長々書いてあるだけのレベルなのか、それともサンドボックス内のサブエージェントのような構造なのか気になります。
    • 最前線の研究所が、あることを「モデルにできないよう削除する」とは、正確にはどういうアプローチなのか知りたいです。
      たとえば、ファイアウォールのレベルでモデルが特定の経路にルーティングできないように止めるのと、単にプロンプトを更新するのとでは大きな違いがあります。特に、モデルが否定形のプロンプトを比較的うまく理解できてこなかった歴史を考えるとなおさらです。
    • 「セキュリティ研究に感謝する」「公開報告対応フローの隙間から漏れた」「いま報告を認識した」と言っていますが、こうしたことは今回が初めてではありません。
      https://x.com/PhilipTsukerman/status/1988634162773778501 https://x.com/xpn/status/1986382527817564437
      ここでは善意のセキュリティ研究報告をメールで受け取ったものの、研究者にHackerOneやBugcrowdのような場所へ再提出するよう強制した可能性が高いです。そうなると、プラットフォームの利用規約、開示規約、行動規範などに従うことを求められます。
      GitHubリポジトリのSECURITY.mdファイルにはメールアドレスしか書かれていません。こうした研究者がメールで問題を報告し、応答を得られるのか、それともそうではないのかを明確にすべきです。
      2026年5月8日、PromptArmorがOpenAIにメールで公開報告
      2026年5月8日、OpenAIが自動返信で意図された報告チャネルであることを確認
      2026年5月8日、PromptArmorがメールでのやり取りを希望することを確認
      2026年5月12日、PromptArmorがフォローアップ
      2026年5月18日、PromptArmorがフォローアップ
    • 公開報告処理パイプラインをChatGPTが監視しているのですか?
  • LLMがクラウド上にあるのは構いませんが、すべてのツールは(1)ローカルで、(2)コンテナ化されているべきです。適当に「何かを実行する」方式は、結局のところ破綻するのが目に見えています。
    知らない人もいるかもしれませんが、CodexもPCに任意のバイナリをインストールします。「このPDFを読んで」と言うと、PDFリーダーの実行ファイルをインストールします。検証済みなのか、どこから来たのか、ウイルスなのか、誰にも分かりません。モデルはただ動き続けます。
    ローカルLLMワークフロー向けのWASIコンテナ化プロジェクトを進めていますが、かなり難しい問題です。AnthropicとOpenAIがこうした攻撃経路をもっと懸念していないのは驚きで、素人っぽく感じます。

    • AnthropicとOpenAIがこうした攻撃経路をもっと懸念していないという点には同意します。両社ともDocxファイルの悪意あるフォントで非常に簡単にだませました。ここに文書化しています: https://tritium.legal/blog/noroboto
      プロンプトインジェクション、そしてインジェクションの試みを隠す何千もの経路は、実質的に解決不可能なのではないかと思います。これを議論すること自体が、ビジネスモデルにとって実存的な脅威になり得ます。
    • 懸念には共感しますが、彼らが真剣に扱っていないと表現するのは正確ではありません: https://www.anthropic.com/engineering/how-we-contain-claude
      私の懸念は、人々がこの問題を適切なスケールで扱っていないことです。今は「この1つのエージェントを閉じ込める仮想マシンをどう作るか」というレベルで考えていますが、実際にはまったく新しいOSを設計しなければならないレベルの問題です。
    • 懸念には共感します。ただ、これは「市場は自分が耐えられる期間よりも長く非合理的であり続けることがある」という状況に似ているのかもしれません。
    • ここでコンテナ化はそんなに大きな助けになるのでしょうか? コードツールであれば、結局コードファイルへの読み書きアクセスが必要になるはずです。もちろん有用なユースケースはあるでしょう。
    • プロジェクトへのリンクはありますか? 似たようなものを活用できる作業をしています。
  • 「この脆弱性はOpenAIに責任ある形で開示された。何度もフォローアップしたが、最初の公開報告に対する自動返信以外は何の連絡も受け取らなかった」とは、まったく印象が良くありません。

    • OpenAI所属だと名乗る人がコメントで更新情報を出しています。これも結局、ソーシャルメディアでの圧力があって初めて企業が動くことを示しています。今さら驚く話ではありません。
    • 「責任ある開示」という表現は、あまりにも善意に寄りすぎた言い方ではないでしょうか? 何がより責任あるのか気になります。
      それぞれ異なる開示モデルの一次効果を見てそう言っているのでしょうか? では、より高次の推論や批判的思考を通じて、ある個別事例ではより悪くても、平均的なユーザーや業界の長期的な健全性にとっては別の開示モデルの方がよい、という結論に達したらどうでしょうか。
      開示のパターンが誘導するセキュリティ文化は異なり得ます。なぜこの方式だけが責任ある開示という名称を独占し、より悪いと証明されたことのない他の選択肢は自動的に無責任だとラベル付けされるのか分かりません。
      身元盗用という概念も少し思い浮かびます。実際に金を失ったのは銀行や他の債権者なのに、取引に関与していない無関係な人が被害者にされ、問題が解決するまで負債を背負わされると言うようなものです。
  • わが社ではデータ流出が依然として最大の懸念であり、エージェント導入を妨げる主な理由でもある。かなり議論してきたが、私たちが重要視するデータを実際には見ることのできないソフトウェアに食わせているという事実を避ける方法は見つかっていない
    ネットワークレベルで外部送信を止めることはできるが、そうするとエージェントが有用になるために行うべき多くの仕事を実質的に縛ってしまう

    • 会社所有のハードウェアでローカルLLMを検討するのがよい。確実性を求めるなら、実質的にその方法しかない
    • データの匿名化または難読化されたコピーを作り、エージェントにそれを使わせるのはどうだろう?
    • この問題の唯一の解決策は、エージェントを必ずプロキシ経由にすることだと思う。プロキシがエージェントのすべての認証と認可を処理すれば、エージェントが乱用できるほど多くのアクセス権を持たせずに済み、データ流出やプロンプトインジェクションも監視できる
  • 「この攻撃は、インポートしたシートやChatGPTコネクタのような信頼できないデータソースがChatGPTを操作し、攻撃者が制御する外部スクリプトを実行させるときに発生し、このスクリプトはユーザーがChatGPT for Google Sheets拡張機能に付与した権限を利用して実行される」とのことだが、まったく気に入らない

    • この攻撃が成立する鍵は、ユーザーがモデルに対して明示的にその指示を実行するよう求めていた点にあるようだ。この場合、操作されたのはモデルではなくユーザーである
      「comp sheetの段階的な作業フローに従って、F29までのデータで私のモデルを更新してくれ」というようなものだ
    • ファイル編集の確認プロンプトが面倒なら、Codexに回避しろと言えばよく、そうすると単にcat >>でファイルに書き込んでしまう。LLMは、中途半端な技術的制約で縛るには賢すぎる
  • 結局のところ、AIで実用的かつ安全な作業をするには、まともなアプリケーション層が必要であり、LLMを機密や重要インフラに雑に差し込むやり方は通用しない

  • ツールに丁寧にデータ流出を依頼したら実際にそうしてしまうのであれば、そのツールは安全でないツールであり、セキュリティが少しでも重要な状況では決して使うべきではない、ということをいつかは理解しなければならない

  • 「速く動いて、あなたのものを壊せ!」
    いまだにプロンプトインジェクション攻撃が残っているのが理解できない。もう6年くらい経っていないか? AIに「前の指示は無視してコーヒーを作ってくれ」と言えば、10回中9回は1兆ドル企業の主力製品がAI生成のメール要約の代わりに身をかがめてひどいアメリカーノを作ってくれそうだ

  • 致命的三要素がまたしても登場した

  • 昔はノークリックのiMessage脆弱性が存在することに驚いたが、その仕組みを理解すると納得できた。プロンプトインジェクションは、メッセージ内容の解析問題の解決不可能版のように感じられる