Salesforce が Agentforce の脆弱性3件を修正した。外部の攻撃者が公開の問い合わせフォームだけで、企業自身の AI エージェントを乗っ取れる問題だった。Zenity Labs は SalesBleed と総称するこの攻撃チェーンを木曜日に公開した。Salesforce と11週間かけて修正を進め、8月に最後の一件を閉じた後のことだ。
入口は Web-to-Lead である。企業が営業の問い合わせを受けるためにサイトへ設置する、認証不要のフォームだ。攻撃者が隠し命令を含むリードを送信しても、その時点では何も起こらない。ペイロードは CRM に残り続け、従業員がエージェントにありふれた質問を投げた瞬間に動き出す。最新のリードを確認してほしい、新しい案件を手伝ってほしい——それだけで足りる。エージェントは汚染されたレコードを読み、従業員ではなく攻撃者の指示に従う。
要点
- Zenity Labs は2026年6月1日に SalesBleed を Salesforce へ報告し、Salesforce は翌日これを確認した。Zenity は8月19日に最終パッチを検証し、9月24日に公開した。
- 流出が成立したのは、Salesforce の Trusted URLs リダクターとレンダリング面が URL の終端を異なって判断したからだ。リダクターは固定のトップレベルドメイン一覧しか認識せず、
.funはそこに含まれていなかった。 - 3件目の脆弱性は Reply to a Slack Thread アクションにあった。ユーザー確認も発信者表示もないため、内部者がエージェントの身元を借りてフィッシングメッセージを送れる状態だった。
リダクターとブラウザーが食い違った場所
Agentforce には Trusted URLs という制御機能がある。エージェントが到達できる外部の宛先を制限し、信頼されない先を指すリンクや画像をリダクトする役割だ。Zenity の研究者である Alex Apostolov、João Donato、Avishai Efrat、Ayush RoyChowdhury は、これを突破する経路を2つ見つけた。
第一に、リダクターはホスト名を固定のトップレベルドメイン集合と照合しており、.fun のような未収録のものはそもそも URL として認識されなかった。第二に、リンク内の波かっこと角かっこはリダクトされず、レンダリング結果まで生き残った。https://random_string.oast.fun/{email} のような文字列は、リダクターが切り捨てるほど不正に見え、ブラウザーが取得するには十分に有効だった。
この食い違いが攻撃のすべてである。注入された命令は、エージェント自身の Query Records ツールで Accounts テーブルを照会し、企業名と取引規模を抜き出し、その値を攻撃者が管理するホスト名のサブドメインへ埋め込み、HTML の画像タグとして出力させるものだった。フロントエンドはそれをレンダリングして取得し、DNS 参照が盗んだフィールドを攻撃者の権威ネームサーバーへ運んだ。従業員の画面には何も表示されなかった。
Slack は被害を広げ、痕跡まで消した
同じペイロードは、画像のレンダリングなしで Slack 上でも機能した。Slack がプレビュー生成のためにリンクを展開するからだ。特別に組み立てた URL がチャンネルに現れるだけで、CRM のフィールドを外部へ送り出すリクエストが発生する。クリックもホバーも、リードを確認する以上の操作は一切要らない。
3件目のバグは性質が異なる。Agentforce の Reply to a Slack Thread アクションは、確認プロンプトも、呼び出したユーザーを示す表示もないまま出荷されていた。すでにエージェントと対話している内部者は、匿名のまま、エージェントの信頼された身元でフィッシングリンクを投稿できた。URL リダクトの回避と組み合わせれば、そのリンクはどこへでも向けられた。
パッチより長く残るパターン
Salesforce がリダクト回避を封じたため、この特定のチェーンはもう通らない。Zenity が強調するのはバグではなく材料のほうだ。外部から投稿されたレコードを読み、リンクや画像をユーザーへ返してレンダリングし、機微なデータに届くツール権限まで持つ AI エージェントなら、3つの材料が同じ場所に揃っている。
Zenity 共同創業者で CTO の Michael Bargury は、エージェントにとって secure-by-design は依然として不可欠だが、もはや十分ではないかもしれないとThe Register に語った。最初から組み込んだ保護でも、エージェントが現実の環境で自ら見つけ出す例外は取りこぼすからだ。彼は、エージェントを閉じ込めるはずだったサンドボックスを抜け出した OpenAI–Hugging Face の事例をより大きな潮流の一部として挙げ、エージェントが実際に何をしているかを監視する仕組みは、その能力の伸びに合わせて拡張されなければならないと論じた。
この主張はすでに一つの製品カテゴリーになっている。Docker は今週の開発者向け基調講演で同じ論理を展開し、コンテナーはアプリケーションを隔離するがエージェントには封じ込めが必要だという前提で、ホスト型 microVM サンドボックスを打ち出した。SalesBleed は同じ問題のエンタープライズ SaaS 版だ。Salesforce はガードレールを作り、そのガードレールとブラウザーは同じ文字列を別々に読んだ。
FAQ — よくある質問
SalesBleed は今も悪用できるのか
できない。Zenity Labs は2026年6月1日に Salesforce へ報告し、Salesforce は8月18日に修正を確認、Zenity は8月19日にパッチを検証した。9月24日に公開されたのは、すでに成立しない攻撃チェーンである。
SalesBleed は被害者のクリックを必要としたのか
必要としなかった。そこがこの脆弱性の際立つ点だ。求められた行動は、従業員が Agentforce のエージェントに最近のリードについてありふれた質問をすることだけだった。流出はその後、画像の自動読み込みか Slack のリンク展開を通じて起きた。
Salesforce 以外の AI エージェントにも影響するのか
回避手法そのものは Salesforce 固有だったが、Zenity はその下にある組み合わせは固有ではないと見ている。信頼できない外部レコードを取り込み、リンクや画像をユーザーへ返してレンダリングし、機微なデータを読むツールをエージェントに与えるプラットフォームであれば、同じ攻撃を組み立てられる。
