SalesBleed：1件の公開リード、Agentforceの3つの欠陥、クリック数ゼロ

2026年9月24日、Zenity Labsは、SalesBleedと名付けた研究を公開した：Salesforce Agentforce——CRMベンダーがAIエージェントを構築・展開するためのプラットフォーム——における3件の脆弱性で、第三者が企業のSalesforce orgから顧客レコードを引き出し、さらにその企業自身のエージェントを使って従業員をフィッシングできる。3件のうち2件は、企業内部の誰からのクリックも必要としない。この露出は、Web-to-Lead送信を受け付けるAgentforceテナント、およびテナントがSlackに公開したあらゆるエージェントに該当する。Dark Readingは、CVE識別子は割り当てられなかったと報じ、Salesforceは同メディアに対し、どの顧客に対しても悪用された証拠はないと述べた。アーカイブ自体の信頼度グレードと被害状況を含む完全な記録はOrca AI Incident Archiveにあり、同アーカイブは文書化された各エージェントインシデントを引用元とともに記録している。

公開リードフォームがデータチャネルになる仕組み

Web-to-LeadはSalesforceの公式のリード収集メカニズムであり、設計上、認証を必要としません。インターネット上の誰もがフォームを送信し、その内容が顧客のCRMに届くようにするために存在しています。Zenityの最初の投稿は、Alex Apostolov氏と同僚によるものとされ、冒頭でこれを唯一の侵入条件として掲げています。停止すべきアカウントも、失効させるべきセッションも、検知すべきログインイベントもありません。攻撃者がテナントに触れることは一切ありません。

研究者たちが説明する連鎖は、5つの段階で進む。

• 攻撃者は、公開されている Web-to-Lead エンドポイントを通じて、いずれかのフィールドに隠しプロンプトインジェクションを仕込んだリードを送信します。一見すると通常の問い合わせに見えます。

• リードは、従業員が自分のエージェントにごく普通のことを尋ねるまで、そこに置かれたままになります — Zenityの例は「最新のリードを確認して、一番新しいものを手伝って」です。

• エージェントは汚染されたレコードを読み、その中の指示に従って、デフォルトのGeneral CRMサブエージェントがすでに持っているQuery Recordsツールを使い、Accountsテーブルを照会します。Zenityは、特権昇格は不要だったと明言しています。同じサブエージェントはLeadsとAccountsの両方への読み取りアクセスを備えて出荷されており、これらは設定ミスではなくデフォルトです。

• 取得した値（研究者らの例では企業名と取引規模）を、攻撃者が管理するホスト名のサブドメインに書き込み、その結果を HTML の画像タグとしてユーザーに出力します。

• チャット画面は外部の画像ソースをサニタイズや確認ステップなしでレンダリングするため、クライアントがホスト名を解決します。データは DNS クエリに含まれて外部に送信されます。

その最後のステップこそ、少し立ち止まって検討する価値がある部分です。ペイロードは DNS ルックアップ内を伝わるため、その後に続く HTTP リクエストは無関係です。失敗しても、タイムアウトしても、完全にブロックされても、データはすでに送信されています。Zenity は、これが HTTP のエグレス制御をすり抜けると指摘しています。単一の DNS ラベルは 63 文字、完全な名前は 253 文字に制限されているため、1 回の送信で漏えいするのはほんの一部です。研究者らは、繰り返しリクエストを行うことで Accounts テーブル全体を 1 アカウントずつ吸い出せると説明しており、名称にある「bleed」はここに由来します。

さらに少ない要件で済む第二の流出経路があります。Slack に公開されたエージェントでは、画像タグは不要です。Slack は生の URL をプレビューに変換し、プレビューを作成するためにリンクをクロールするため、URL を出力するだけで同じ DNS ルックアップを引き起こすのに十分です。SecurityWeek は、結果として生じる動作についての Zenity の要約を引用しています。リンクが表示されるとすぐに、Slack は CRM データを運ぶリクエストを攻撃者が制御するインフラストラクチャに送信します。

Zenityはここで「ゼロクリック」が何を意味するかに慎重であり、その区別は重要だ。従業員が行うのはただ一つ、自分のリードについて自分のエージェントに普通の質問をするだけである。添付ファイルを開いたり、リンクをたどったり、攻撃者が送った何かに接触したりはしない。その質問の後はすべて自動だ。悪意あるリードも他の記録と同様にLeadsテーブルに残るため、従業員がそれを確認するたびに再び発火し得る——そして、より広い経路を望む攻撃者は、より多くのリードを送信するだけでよい。SecurityWeekは、この失敗をさらに際立たせる詳細を記録している。Agentforceは、そのコンテンツが組織のセキュリティポリシーによってブロックされたと報告したにもかかわらず、CRMデータはすでに攻撃者のサーバーに到達していたのだ。

Trusted URLsフィルターが保持されなかった理由

Trusted URLs は、まさにこの問題を阻止するための Salesforce のコントロールです。Agentforce が到達できる外部の宛先を制限し、誰も承認していないドメインを指すリンクや画像を削除します。Zenity は、組み合わせることでこれをそのまますり抜けてしまう 2 つのエッジケースを発見しました。

1つ目はトップレベルドメインでした。リダクターは固定のTLDリストのみを認識しており、アウトオブバンドテストプラットフォーム app.interactsh.com で使用されるドメイン .fun はそのリストに含まれていませんでした。認識されないTLDで終わるホスト名は、ホスト名としてまったく認識されない可能性があります。2つ目はURLの終端位置でした。リダクターと回答をレンダリングするサーフェスとで終端文字の解釈が一致せず、中括弧と角括弧がその食い違いの間にありました。https://random_string.oast.fun/{email} のような文字列は RFC 3986 上は有効なURIではありませんが、それでも攻撃に必要なDNSクエリを発生させます。リダクターは不正な非URLとみなしてそのままにしましたが、ブラウザはそれを画像ソースとして取得しようとしました。

ある構造上の詳細によって、そのバイパスは調整可能になっていた。マスキングは、エージェントが出力を生成した後に、モデルが関与しない別プロセスとして実行される。Zenityは、クライアントに送られた応答の中に、エージェントの生の出力とマスキング済みの版の両方が存在することを発見した。これにより研究者は両者を比較し、フィルターが検出していた異常——たとえばサブドメイン内の角括弧——を、インジェクションがエンドツーエンドで安定するまで取り除くことができた。

Dark Readingは、SalesforceのURL秘匿化がこれまで、文字列がURLのように見えるかどうかを判断するために正規表現マッチングに依存しており、そのため予期しない形式でドメインを隠すことが可能だったと報じている。同社によると、それを仕様に準拠したURL解析に置き換え、URL関連のエージェント通信がすべて単一のゲートウェイを通過するようURL検査を一元化したという。

第3の欠陥：エージェント自身の名義によるフィッシング

同日に公開された、João Donato氏と同僚らによる2件目の投稿で報告されたSlackに関する発見は、データではなくアイデンティティに関するものです。AgentforceのエージェントはSlackに直接公開でき、その機能はサブエージェントとして提供されます。Zenityによると、Slack Knowledgeテンプレートは、そのすべてのアクションを含め、2回のクリックで追加できます。

研究者が調査したSlackの書き込みアクションのほとんどには、2つの保護措置がありました。送信前の確認ステップと、どのユーザーのリクエストがそのメッセージを引き起こしたかを受信者に示す呼び出し元の帰属情報です。 Slackダイレクトメッセージを送信 は両方を備えていました。 Slackスレッドに返信 はどちらも備えていませんでした。Agentforceがそのアクションを呼び出すと決めると、メッセージは承認も帰属情報もないまま送信されました。メッセージにはエージェントの身元だけが付き、それを要求した人物を指し示すものは何もありませんでした。

その結果、2つの攻撃経路が生まれた。すでにエージェントとチャットできる悪意のある内部関係者は、適切なスレッドにフィッシングを投稿し、自分にたどり着く手がかりを一切残さずに立ち去ることができる。受信者はそれをエージェントからのメッセージとして読むからだ。外部の攻撃者も、Web-to-Leadインジェクションを通じて同じ結果を得る。汚染されたリードがエージェントにSlackチャネルへ返信するよう指示し、エージェントはそれを引き起こした従業員に確認することなく実行する。最初の投稿で示されたURLリダクションのバイパスによって、フィッシングリンクはフィルタリングをすり抜けられる。後にZenityは、リンクを一見無害なマークダウンテキストの背後に隠すことも可能だと発見した。ZenityとSalesforceはどちらも、その帰結を同じ言葉で説明している。従業員は、不慣れな外部の送信者からではなく、すでに職場内で稼働している信頼されたシステムからメッセージを受け取るのであり、リンクをたどって認証情報を渡してしまう者は、メール、Slack、ソースコードリポジトリ、そしてそのIDが到達しうるあらゆるものをさらすことになる。

何が確立されており、何が確立されていないのか

4つの点が{{1}}ここで確認した情報源を通じて確定している{{/1}}。{{2}}Zenityは攻撃チェーンを実証し、概念実証（PoC）動画を公開した{{/2}}。{{3}}Salesforceはこの分析を認め、Dark ReadingとSecurityWeekへの声明の中で、実施した変更について説明している{{/3}}。{{4}}3つの脆弱性のいずれにもCVEは割り当てられておらず、Dark Readingはこれを、顧客が実行するソフトウェアではなく、ホスト型サービスのSalesforce側で修正が行われたためだとしている{{/4}}。そして{{5}}Salesforceは現時点で、そのいずれかが顧客に対して悪用された証拠はないと述べている{{/5}}。

確定していないのは、規模に関するあらゆることだ。本稿で確認したどの情報源も、影響を受けたデフォルト設定を使用していたAgentforceテナントがいくつあったのか、顧客データが実際に顧客環境の外へ出たのかどうか、またZenity LabsとSalesforce以外の誰かがそれを調査したのかどうかについて述べていない。独立系メディア——Dark Reading、SecurityWeek、Infosecurity Magazine、The Register——はいずれもこの調査結果を報じ、Salesforceの回答を掲載したが、それらの報道のいずれも、独自に攻撃を再現したことを報告しているわけではない。SalesBleedに関する第二の独立した技術調査は存在せず、本記事もそれが存在することを示唆していない。

この記録が依拠する資料自体も、ある細部で食い違っており、それをならすのではなく、はっきり指摘する価値がある。9月24日にBusiness Wire経由で配信されたZenityのプレスリリースは、SalesforceがZenityから報告された特定のTrusted URLsバイパスに「およそ2週間以内」に対処したと述べている。Zenityの技術投稿にある日単位のタイムラインは、報告が送られた6月1日から、修正が確認された8月18日と19日までで、11週間に近い。どちらの説明も同じ組織によるものだ。

Salesforceが何を、いつ変更したか

開示には時間がかかり、Zenity の説明によれば和やかに進んだ。調査結果は2026年6月1日にメールで Salesforce に送られ、Salesforce は翌日にそれを確認して修正に取り組んでいると述べた。両チームは6月16日に技術通話を行い、Salesforce はエンジニアリングがまだ作業中であると注記して6月17日に開示をクローズした。8月18日に Salesforce は修正を確認し、8月19日に Zenity は特に Trusted URLs のバイパスを検証した。Slack アクションにおける帰属表示は8月20日に修正済みであることが確認された。デフォルトで確認を必須にすることにはより時間がかかり、8月25日に Salesforce はまだ作業中と述べ、9月10日には9月21日を目標として示し、9月21日に Zenity が3件すべてをテストして確認した。

Salesforceが説明する変更は具体的だ。Slack上の特定のAgentforceアクションでは、デフォルト設定でメッセージを送信する前にユーザーの確認が必要になり、同社は顧客の設定を確認するため顧客に直接連絡していると述べている。Trusted URLsでは、正規表現マッチングが廃止され、仕様準拠の解析に置き換わった。また、URL検査はワークフロー内の複数箇所で処理されるのではなく、単一のゲートウェイに統合された。

Slackの修正に対するZenityの結びの注記は、問題が完全に解消したという宣言ではなく、注意喚起だ。確認を求める仕様は設定の一つであり、無効にするのはクリック1回で済む。一度無効にすれば、同じ攻撃経路が再び利用可能になる。エージェントを構築する組織に対する研究者の助言は、デフォルトの設定が維持されていると想定するのではなく、書き込みアクションがどのように設定されているかに目を配ることだ。

なぜ研究者たちはそれが一般化すると言うのか

細部はSalesforceに固有ではあるが、ZenityはSalesBleedをあるパターンの一例として位置づけている。Zenity自身の要約は、外部ソースから提出されたレコードを読み取り、ユーザーにリンクや画像をレンダリングして返し、さらに機密データへのツールアクセスも持つエージェントは、同じ3つの要素を同じ場所に持つというものだ。研究者たちはこの組み合わせを、リーサル・トリフェクタの一形態と呼んでいる。つまり、プライベートデータ、信頼できないコンテンツ、外向きチャネルが1つのアイデンティティで交わるものだ。

このパターンには前例がある。Dark Readingは、SalesBleedの1年前にNoma Securityの研究者が同じWeb-to-lead経路を使ってSalesforceのデータに到達し、Salesforceがそれに応じてURLルールを厳格化したと報じている。そのルールは正規表現ベースの秘匿化で、Zenityはその後これを回避した。Salesforceの広報担当者はDark Readingに対し、以前の対応は包括的なものではなく応急処置だったと認め、今回の対応はより堅牢なものにする意図だと述べた。

「私たちは、Agentforceが企業データを未承認の送信先へ送信するのを防ぐために設計されたセキュリティ境界を突破する複数の方法を発見しました」と、Zenityの共同創業者兼最高技術責任者であるMichael Bargury氏は発表資料の中で述べている。「強固な境界は、AIエージェントを封じ込めるために私たちが持つ最も強力な手段の一つであり続けていますが、それでもソフトウェアにすぎません。そうした制御が失敗すると、高い自律性を持ち、制約のない特権アクセスエージェントが残されることになります」。Zenityのセキュリティ研究ディレクターであるTamir Ishay Sharbat氏は、より広い論点をDark Readingに示した。エージェントに与えられる権限が大きいほど危険性も高まり、自ら複数のチャネルにメッセージを送信でき、同時に契約書、見込み客、買掛金を読み取れるエージェントは、悪用される組み合わせだという。Bargury氏は同媒体に2つ目の懸念を付け加えた。エージェントがブラックボックスとして構築され、ログの代わりに要約が提供されるため、エージェントが何をしたのか、なぜそうしたのかを把握するのが難しくなっているという。

この記録をデモンストレーションからインシデントへ移すのは、新しい手法ではなく、一本の証拠である。顧客による開示、CVE、あるいは攻撃チェーンが実際に使用されているのが確認されたというSalesforceまたはZenityからの声明だ。ここで確認した情報源には、そのいずれも存在しない。そのうち一つでも存在するまでは、SalesBleedはアーカイブが記録しているとおりのものとして残る — 高重大度の脆弱性であり、発見者らによって信頼度Aの基準で文書化され、ベンダーによって修正済みであることが確認されており、実世界での被害は記録されていない。