複数のチャットボットを手元で使えるようにするはずのAIツールが、場所さえ知っていれば誰でもアクセスできる状態で、数百万件のファイルを公開していました。
サイバーセキュリティ研究者のCybernewsによると、AIアグリゲーターの302.aiは、個人情報、AIとの会話、企業文書などを含む1760万件のファイル(計22.72テラバイト)を外部から閲覧できる状態にしていました。
Cybernewsの研究者は、一般公開状態のMicrosoft Azureストレージを2026年8月2日に発見しました。同社には8月11日に通知し、9月8日に公開アクセスが閉じられたことを確認しています。悪意ある攻撃者がデータにアクセスしたりダウンロードしたりした形跡は報告されていませんが、それ以前にアクセスされた可能性は否定できません。
302.aiは香港拠点のUniverads Technology Limitedが運営しており、ChatGPT、Claude、Grok、DeepSeek、Geminiなど複数のAIモデルを単一のプラットフォームから利用できるサービスです。
流出したアーカイブには、約9TBの画像、7.7TBの動画、5.6TBの音声が含まれていました。より深刻なのは、JSONファイルに保存された14万4000件超のチャットログです。会話内容と関連情報が記録されていました。
個人情報と企業の会話が流出
チャット記録には、ユーザーのプロンプト、AIの応答、選択したモデル、トークンコスト、タイムスタンプなどのメタデータが含まれていました。一部の会話には、ユーザーが入力した生年月日、性別、自宅住所、連絡先といった個人を特定できる情報も含まれていました。
企業ユーザーも影響を受けています。Cybernewsの研究者は、大手のセックスドール製造企業が運用する、法人向けカスタマーサポートチャットボットに関連する会話を確認しました。アーカイブには、AI研究に関する資料や、ユーザーが分析のために提出したファイルなど、業務文書も含まれていました。
Cybernewsが報告したところでは、流出したストレージバケットには、会話データ、モデルの出力、要約、アップロードされたファイルを収めた2万6000件超のZIPアーカイブも含まれていました。研究者によると、同社に連絡した後、データは一般公開されなくなりました。
流出がセキュリティリスクを生む理由
今回の件は、AIプラットフォームが個々のチャットメッセージにとどまらない機密情報の蓄積場所になり得ることを示しています。ユーザーは、顧客からの苦情、社内文書、個人情報、業務上の質問をAIサービスに送信しますが、それらの記録がプラットフォーム外からアクセスできる状態になるとは想定していないでしょう。
これは標的型攻撃の機会につながります。チャット履歴を入手した犯罪者は、実名、取引関係、プロジェクトの詳細、顧客の問題などを利用して、説得力のあるフィッシングメッセージを作成できます。流出した企業の会話は、攻撃者が従業員になりすましたり、 管理職をはじめとする経営幹部向けにメッセージを調整したりする際にも役立ちます。
リスクは主要なAIプロバイダーにとどまりません。302.aiのようなアグリゲーターは、プロンプト、アップロードされたファイル、会話履歴が保存される基盤をもう一層加えることになります。基盤となるモデルが実績ある企業のものであっても、仲介事業者のセキュリティは重要です。
AIユーザーへの影響
一般ユーザーにとって今回の件は、AIプラットフォームとの会話が当然に非公開とは限らないことを改めて示すものです。自宅住所、金融情報、私信など本人を特定できる情報を共有すると、サービス側が保存データを不適切に扱った場合に流出するおそれがあります。
企業にとっては、さらに大きな影響が及ぶ可能性があります。従業員が社内文書の分析、システムのトラブルシューティング、顧客対応にAIツールを使うことがあるためです。流出した会話から、一般には公開されていない情報が明らかになるおそれがあり、攻撃者になりすましやソーシャルエンジニアリングの材料を与えかねません。
組織は、従業員が利用できるAIアグリゲーター、アップロードを許可する情報、ベンダーがデータ保持とセキュリティに関する明確なポリシーを提示しているかを見直すべきです。可能な限り、適切なアクセス制御、暗号化、契約上の保護を備えた承認済みサービスを使う必要があります。
ユーザーも、利用するAIプロバイダーのプライバシー設定とデータ取り扱いポリシーを確認し、不必要な機密情報の入力を避け、承認されたAIツールに関する組織のルールに従ってください。
セキュリティチームが次に確認すべきこと
302.aiを利用した組織は、まず従業員が何を送信したのかを把握する必要があります。セキュリティチームは、サービスを利用している部門とアカウントを特定し、利用可能なアップロード履歴と会話履歴を調べて、顧客記録、機密文書、その他の機微な資料がないか確認してください。対応は、データセット全体の規模ではなく、流出した可能性のある情報の内容に応じて決めるべきです。
ベンダーには、影響を受けたアカウントとファイルを特定できるか、流出期間を確定できるか、アクセスログを提供できるかを問い合わせてください。公開アクセスを閉じたことで当面の流出は解消されましたが、自社のデータが含まれていたか、さらなる調査が必要かを判断するには、組織として十分な情報が必要です。
この確認で、送信された資料の中にパスワード、APIキー、その他の認証情報が見つかった場合は、ローテーションを実施し、関連アカウントに不審な動きがないか確認してください。これは自社の送信内容から見つかったものに基づく予防措置であり、今回の件で認証情報が流出したと確認されたわけではありません。顧客情報や機密性の高い業務記録は、組織のインシデント対応プロセスに沿ってエスカレーションすべきです。
今回の件は、今後のAIベンダー評価にも反映させる必要があります。アグリゲーターが顧客の情報をどう分離し、アップロードされたファイルへのアクセスをどう制限し、ストレージの権限をどう監視し、削除ポリシーをどう徹底しているかを確認してください。こうした保護が、目に見えるチャット画面だけでなく、会話アーカイブや生成されたメディアにも及んでいるかも確かめるべきです。
セキュリティ責任者にとっての実践的な教訓は、機密情報を扱う他のサービスと同じベンダーリスク管理プロセスに、AIの仲介事業者も含めることです。承認の可否は、提供するモデルの機能に加えて、プラットフォームが業務データをどう保護し、どう保持するかで判断すべきです。
関連記事:ストレージの流出はAIセキュリティリスクの一端にすぎません。 こちらのプロンプトインジェクションの実演は、攻撃者がチャットボットの応答を操作することもできると示しています。
翻訳元: https://www.esecurityplanet.com/threats/news-302-ai-data-leak-private-chats/