Salesforce Agentforceの「SalesBleed」脆弱性-ゼロクリックでCRMデータ流出、Slack経由のフィッシングも可能に

セキュリティニュース

投稿日時: 更新日時:

Salesforce Agentforceの「SalesBleed」脆弱性-ゼロクリックでCRMデータ流出、Slack経由のフィッシングも可能に

セキュリティ企業Zenity Labsは2026年9月24日、SalesforceのAIエージェント基盤「Agentforce」で確認した一連の脆弱性を「SalesBleed」として公表しました。

研究では、外部公開されるWeb-to-Leadフォームから悪意ある指示を含むリード情報を登録し、その情報を社内ユーザーがAgentforceで処理した際、エージェントが間接的プロンプトインジェクションを受けることを確認しています。

さらに、Agentforceの「Trusted URLs」によるURL制御を回避することで、利用者がリンクをクリックしなくてもCRM内のデータを外部へ送信できる経路が成立しました。Slack連携では、エージェントの権限を利用して、社内Slackへフィッシングメッセージを投稿できる問題も確認されています。

Zenity Labsは6月1日にSalesforceへ報告し、Salesforceは修正を進めました。一次調査によると、Trusted URLsの回避は8月19日に修正確認、Slackで投稿者を識別する対策は8月20日、投稿前に利用者確認を必須とする対策を含む全修正は9月21日に確認されています。

今回の問題はSalesforceへの不正ログインや認証情報窃取を前提としない攻撃経路を含みます。外部から登録されたCRMデータをAIエージェントが「データ」ではなく「指示」として処理し、エージェント自身に付与された正規権限を使って情報へアクセスした点が特徴です。

SalesBleedのサマリー

  • Zenity Labsは2026年9月24日、Salesforce Agentforceの一連の脆弱性を「SalesBleed」として公表しました。
  • 攻撃の入口として、Salesforceの公式機能Web-to-Leadが利用できることを研究者が確認しました。
  • 外部から登録されたリード情報に悪意ある指示を含め、Agentforceが後からそのレコードを処理すると間接的プロンプトインジェクションが成立しました。
  • AgentforceのGeneral CRM subagentは、研究環境でLeadsだけでなくAccountsにもアクセスできる権限を持っていました。
  • Trusted URLsのURL制御を回避することで、CRMデータを外部へ送信できる経路が成立しました。
  • 研究者は、画像表示とSlackのリンクプレビューを利用する2種類のゼロクリックデータ送信を確認しています。
  • 利用者は悪意あるリンクをクリックする必要がありません。
  • Slack連携では、Agentforceを利用して社内チャンネルへフィッシングメッセージを投稿できる問題も確認されました。
  • 一部のSlack書き込みアクションで、利用者確認と実行者の表示が不足していました。
  • Zenity Labsは2026年6月1日にSalesforceへ報告しました。
  • Trusted URLs回避の修正は8月19日に確認されています。
  • Slackの実行者表示は8月20日、利用者確認を含む最終修正は9月21日に確認されています。
  • Zenity Labsは、公開した攻撃チェーンは現在成立しないとしています。
  • 公開資料では、実際の顧客環境で悪用されたとの記載は確認できません。
  • CVE番号は公表されていません。
項目 内容
名称 SalesBleed
対象 Salesforce Agentforce
公表日 2026年9月24日
発見者 Zenity Labs
主な入口 Web-to-Leadなど外部から登録されるCRMデータ
攻撃手法 間接的プロンプトインジェクション
主な影響 CRMデータの外部送信、Slackでのフィッシング
利用者のクリック データ送信では不要
認証 外部攻撃者がSalesforceへログインせずに起点を作れるケースを研究者が確認
CVE 公表なし
実悪用 公開資料では確認されず
Salesforceへの報告 2026年6月1日
Trusted URLs修正確認 8月19日
Slack実行者表示修正 8月20日
Slack確認動作を含む最終修正 9月21日

Web-to-Leadから間接的プロンプトインジェクション

SalesBleedの入口となったのは、SalesforceのWeb-to-Leadです。

Salesforceの公式資料によると、Web-to-Leadは企業のWebサイトから見込み客の情報を受け取り、自動的にSalesforceのLeadレコードを生成する機能です。

外部の顧客や見込み客から情報を受け付けることを目的とした仕組みであるため、登録されたデータがSalesforce内部へ保存されます。

Zenity Labsの研究では、攻撃者がWeb-to-Leadの入力項目へAI向けの悪意ある指示を埋め込みました。

この時点では攻撃者がSalesforce環境へログインする必要はありません。

その後、営業担当者などの正規ユーザーがAgentforceへ「新しいリードを確認して」といった通常の依頼をすると、エージェントが該当するLeadレコードを読み込みます。

Agentforceが外部から登録された文字列を単なる顧客データではなく、自分が実行すべき指示として解釈すると、間接的プロンプトインジェクションが成立します。

攻撃者がAIへ直接指示するのではなく、AIが後から読み込むデータへ命令を埋め込む点が、通常のプロンプトインジェクションとの違いです。

エージェントの正規権限でAccountsデータへアクセス

研究者が確認した環境では、AgentforceのGeneral CRM subagentがLeadsとAccountsの双方を参照できる状態でした。

そのため、悪意あるLeadレコードを読み込んだAgentforceは、攻撃者自身には権限のないAccountsデータを、エージェント自身の正規権限で取得できました。

Zenity Labsは、検証で会社名や案件規模などを対象にしました。

ここで問題になるのは、攻撃者がSalesforceのアクセス制御を直接突破したわけではないことです。

エージェントには業務上必要なデータ参照権限が正規に付与されており、その権限をプロンプトインジェクションによって意図しない目的に利用させています。

AIエージェントへ広い権限を与えた場合、プロンプトインジェクションが成立した際の影響範囲も、その権限範囲に応じて拡大します。

Trusted URLsの制御を回避しゼロクリックでデータ送信

SalesforceはAgentforceに「Trusted URLs」という制御を設けています。

Salesforceの公式ドキュメントでは、Agentforceが未承認の外部URLを応答へ含めようとした場合、URLをブロックまたはURL_Redactedへ置き換えることで、プロンプトインジェクション後の外部通信を制限すると説明しています。

Zenity Labsは、このURL判定処理と実際にURLを処理する側で解釈に差があるケースを発見しました。

その結果、Trusted URLsでは未承認URLとして認識されない一方、ブラウザなどでは外部URLとして処理される文字列を作れる状態でした。

研究者は、この差を利用してAgentforceが取得したCRMデータを外部への通信に含められることを確認しています。

本記事では、修正前の制御を回避する具体的な文字列やペイロードは掲載しません。

画像表示とSlackプレビューの2経路でゼロクリック送信

Zenity Labsは、データを外部へ送る方法として2つの経路を確認しました。

1つ目はAgentforceの応答内で外部画像を表示する処理です。

エージェントが生成した応答をクライアント側が表示する際、外部画像の取得に伴って通信が発生します。研究では、この通信へCRMデータを組み込み、攻撃者が管理するインフラ側で受信できることを確認しました。

2つ目はSlack連携です。

Slackには投稿されたURLの情報を自動取得し、リンクプレビューを生成する機能があります。AgentforceがSlackへ外部URLを出力すると、利用者がリンクをクリックしなくてもSlack側から通信が発生します。

Zenity Labsはこの処理を利用し、CRMデータを外部へ送信できることを確認しました。

どちらも、被害者が攻撃者のリンクをクリックする操作は不要です。

ただし、外部から登録された悪意あるLeadレコードを、社内ユーザーがAgentforceを使って処理することは攻撃チェーンの発火条件になります。

そのため「利用者が何もしていない状態で自動的にSalesforce全体からデータが流出する」という意味でのゼロクリックではありません。

SlackではAgentforceの名前でフィッシング投稿も可能だった

Zenity Labsは別のSalesBleed研究で、AgentforceとSlackの連携に関する問題も公表しています。

AgentforceにはSlackの情報を検索したり、メッセージを投稿したりするサブエージェントがあります。

研究者が確認した当時のReply to a Slack Threadアクションでは、

  • 実行前にユーザーへ確認を求めない
  • どのユーザーの操作が起点だったかを投稿先で表示しない

という2つの制御不足がありました。

この状態では、間接的プロンプトインジェクションを受けたAgentforceがSlackへメッセージを書き込んでも、利用者が投稿前に気付くための確認画面がありません。

さらに受信側からは、メッセージがAgentforce自身から投稿されたように見え、誰の操作が起点だったか分からない状態でした。

研究者は、外部から登録した悪意あるLeadを起点としてAgentforceを操作し、Slackの複数チャンネルへフィッシングメッセージを投稿できることを確認しています。

AIエージェントが「信頼された社内送信者」になる問題

通常のフィッシングでは、外部メールアドレス、不審なドメイン、未知の送信者などが利用者にとって判断材料になります。

SalesBleedのSlack攻撃では、メッセージを投稿する主体が企業内ですでに利用されているAgentforceです。

そのため、社員から見ると、

「外部の不審な人物から送られたリンク」

ではなく、

「普段業務で使っているAIエージェントから届いたメッセージ」

に見える可能性があります。

AIエージェントをSlack、Teams、メール、CRMなどへ接続する場合、エージェントが持つ「社内で信頼されている送信者」という立場そのものが攻撃に利用される可能性があります。

これは、従来のメールゲートウェイや送信ドメインだけを基準にしたフィッシング対策では判定しにくいケースです。

Salesforceは修正、最終対策は9月21日に確認

Zenity LabsはSalesBleedの問題を2026年6月1日にSalesforceへ報告しました。

一次調査に記載された修正時系列は次のとおりです。

日付 対応
6月1日 Zenity LabsがSalesforceへ報告
6月2日 Salesforceが報告を確認し修正作業を開始
6月16日 Zenity LabsとSalesforceが対策を協議
6月17日 Salesforceがエンジニアリングチームで修正中と回答
8月18日 SalesforceがTrusted URLs関連の修正完了をZenityへ通知
8月19日 Zenity LabsがTrusted URLs回避の修正を確認
8月20日 Slack投稿に実行者の帰属表示が追加されたことを確認
8月25日 Slack投稿前確認のデフォルト必須化は作業中とSalesforceが回答
9月10日 Salesforceが9月21日までの完了予定を通知
9月21日 Zenity Labsが全修正を確認

SecurityWeekは「8月19日までに3件すべてが修正された」と報じていますが、Zenity Labsの詳細なDisclosure Timelineでは、SlackのReply to a Slack Threadでユーザー確認をデフォルト必須とする修正は9月21日に最終確認されています。

本記事では一次調査の時系列を採用します。

Zenity Labsは、同社が公表した具体的なSalesBleed攻撃チェーンは修正後には成立しないとしています。

CVEはなく、実悪用も公開資料では確認されず

2026年9月28日時点で、SalesBleedとして公表された問題にCVE番号は確認できません。

Salesforceが管理するクラウドサービス側の問題であり、利用者が特定バージョンのパッチを適用する形式ではありません。

また、Zenity LabsやSalesforceの公開資料では、今回の攻撃手法が実際のSalesforce顧客を狙う攻撃で悪用されたとの記載は確認できません。

今回公表された内容は、セキュリティ研究者による検証結果です。

一方、Agentforceを利用している企業では、Salesforce側の修正だけでなく、自社エージェントに与えているデータアクセス権限やSlack書き込み権限を確認する必要があります。

Trusted URLsは多層防御であり、プロンプトインジェクション自体を防ぐ機能ではない

Salesforceは公式ドキュメントで、AgentforceにTrusted URLsの許可リストを適用すると説明しています。

この制御は、エージェントが未承認の外部URLを生成・利用し、外部へ情報を送信するリスクを抑えるためのものです。

しかし、Trusted URLsだけで間接的プロンプトインジェクションそのものを防止するわけではありません。

SalesBleedでは、

  1. 外部データからAgentforceへ悪意ある指示が入る
  2. エージェントが正規権限でCRMデータを取得する
  3. 外部送信を抑えるTrusted URLsを回避する

という複数段階の組み合わせによってデータ送信が成立しました。

この構造から、企業側では入力、権限、実行、出力の各段階を分けて制御する必要があります。

情報システム部門が確認したいポイント

Agentforceを利用している企業では、Salesforce側でSalesBleedの修正が完了していることを前提に、自社のエージェント構成を確認します。

特に確認したい項目は次のとおりです。

  • Agentforceがどのオブジェクトを読み取り・更新できるか
  • Leadsを処理するエージェントがAccounts、Contactsなど機密性の高いデータにもアクセスできないか
  • Web-to-Leadなど外部入力をAgentforceが自動的に読み込む業務フローがあるか
  • Trusted URLsに不要な外部ドメインや広すぎるワイルドカードを登録していないか
  • AgentforceからSlackへ投稿できるアクションを利用しているか
  • Slackへの書き込みアクションでユーザー確認が有効か
  • エージェントの操作を誰が起動したか監査ログで追跡できるか
  • AIが外部データを読み込んだ後のツール実行を監視できるか
  • CRMデータの大量参照や通常と異なるオブジェクト間アクセスを検知できるか
  • Agentforceが生成した外部URLや外部通信を監視できるか

SalesBleedでは、攻撃者自身にCRMデータへの権限がなくても、Agentforceが持つ正規の権限が利用されました。

AIエージェントのアクセス制御では「利用者本人が何を閲覧できるか」だけでなく、「その利用者の依頼を受けたエージェントがどこまで横断的に参照・操作できるか」も確認する必要があります。

間接的プロンプトインジェクションの仕組みと企業対策は、AIエージェントを狙う間接的プロンプトインジェクションで整理しています。

AIエージェントへ与える権限、ツール、監査などの設計は、AIエージェントのセキュリティとは-公的資料から見る6つのリスクと対策も参照できます。

出典

一次情報・公式資料: