SalesBleed：一個公開潛在客戶，三個 Agentforce 缺陷，零次點擊

2026年9月24日，Zenity Labs發表了其稱為SalesBleed的研究，揭露三個存在於Salesforce Agentforce的漏洞；後者是這家 CRM 供應商建置與部署 AI 代理人的平台，漏洞可讓外人從公司的 Salesforce org 取出客戶紀錄，然後利用該公司自家的代理人對員工進行釣魚攻擊。這三個漏洞中有兩個不需要公司內部任何人點擊。此風險適用於接受Web-to-Lead提交內容的 Agentforce 租戶，以及租戶已發布到 Slack 的任何代理人。Dark Reading 報導指出，沒有指派 CVE 識別碼，而 Salesforce 向該媒體表示，沒有證據顯示任何客戶遭到利用。完整紀錄，連同該檔案庫自身的信心評級與危害狀態，收錄於Orca AI Incident Archive；該檔案庫會將每一起有紀錄的代理人事件對照其引用來源記錄下來。

公開潛在客戶表單如何成為資料通道

Web-to-Lead 是 Salesforce 官方的潛在客戶收集機制，而且依設計本質上就是未經驗證的——它的存在，是為了讓網際網路上的任何人都能提交表單，並讓表單內容進入客戶的 CRM。Zenity 的第一篇文章由 Alex Apostolov 與同事共同掛名，開篇即以此作為整個入侵前提：沒有帳號可停用、沒有工作階段可撤銷、沒有登入事件可偵測。攻擊者從頭到尾都不曾觸及租戶。

研究人員所描述的這條連鎖過程分五個步驟展開：

• 攻擊者透過公開的 Web-to-Lead 端點提交一筆潛在客戶，並在其中一個欄位中隱藏提示注入。它看起來像一則普通的詢問。

• 潛在客戶就擺在那裡，直到員工向自己的代理詢問一些再平常不過的事——Zenity 的例子是「查看我最新的潛在客戶，並幫我處理最新的一筆。」

• 代理程式會讀取遭毒化的記錄，並依循其中的指示，使用預設 General CRM 子代理程式原本就具備的 Query Records 工具來查詢 Accounts 資料表。Zenity 明確指出，過程中完全不需要提權：同一個子代理程式出廠時即具備 Leads 與 Accounts 的讀取權限，而這些都是預設設定，並非設定錯誤。

• 它會把所取得的數值——在研究人員的範例中是一個公司名稱與一筆交易金額——寫入攻擊者所掌控之主機名稱的子網域，並將結果以 HTML 圖片標籤的形式輸出回給使用者。

• 聊天介面會在不進行清理或確認步驟的情況下呈現外部圖片來源，因此用戶端會解析主機名稱。資料會隨 DNS 查詢外洩。

最後一步是值得放慢腳步仔細檢視的部分。因為載荷是透過 DNS 查詢傳送，後續的 HTTP 請求就無關緊要——它可以失敗、逾時或被直接封鎖，而資料早已送出去了。Zenity 指出，這種手法能挺過 HTTP 出口控制。單一 DNS 標籤上限為 63 個字元，完整名稱上限為 253 個字元，因此一次提交只會洩漏一小片；研究人員描述透過反覆請求，一次一個帳號地榨乾整張 Accounts 資料表，這正是名稱中「bleed」的由來。

還有第二個出口所需更少：對於發佈到 Slack 的代理程式，不需要影像標籤。Slack 會將原始 URL 轉成預覽，並爬取連結來建立預覽，因此只要印出 URL 就足以觸發相同的 DNS 查詢。SecurityWeek 引述 Zenity 對由此產生的行為的總結：只要連結一出現，Slack 就會向攻擊者控制的基礎設施發出承載 CRM 資料的請求。

Zenity 對這裡的「零點擊」定義相當謹慎，而這項區別至關重要。員工只做了一件事：向自己的代理提出一個關於自身潛在客戶的普通問題。他們沒有開啟附件、沒有點擊連結，也沒有與攻擊者所發送的的任何內容互動。那個問題之後的一切全自動進行。惡意潛在客戶資料也像其他紀錄一樣留在「潛在客戶」資料表中，因此每次員工檢視它時都可能再次觸發——而想開拓更寬廣通道的攻擊者，只要提交更多潛在客戶資料即可。SecurityWeek 記錄了一個讓這起失效更顯鮮明的細節：Agentforce 回報該內容已被組織的安全政策封鎖，儘管 CRM 資料早已送達攻擊者的伺服器。

為什麼 Trusted URLs 篩選器未生效

受信任的 URL是 Salesforce 的一項控制機制，正是為了阻止這種情況而設——它會限制 Agentforce 能觸及的外部目的地，並移除指向未經核准網域的連結與圖片。Zenity 發現了兩個邊緣案例，兩者結合起來便能直接繞過這道防線。

第一個是頂級網域。遮蔽器只認得一份固定的 TLD 清單，而 .fun——app.interactsh.com 帶外測試平台所使用的網域——並不在清單上。以未識別 TLD 結尾的主機名稱，甚至可能完全不會被辨識為主機名稱。第二個是 URL 結束的位置：遮蔽器和呈現答案的介面對於終止字元看法不一致，而大括號與方括號就落在這個落差裡。像 https://random_string.oast.fun/{email} 這樣的字串，依 RFC 3986 並不是有效的 URI，卻仍會產生攻擊所需的 DNS 查詢。遮蔽器看到的是格式錯誤的非 URL，於是原封不動放過它；瀏覽器卻願意把它當作圖片來源來抓取。

一個結構性細節讓這項繞過變得可調校。內容遮蔽是在代理產生輸出之後才執行，而且是模型完全不知情的獨立程序。Zenity 發現，傳送給用戶端的回應中同時存在代理的原始輸出與遮蔽後的版本，這讓研究人員得以比對兩者，並剔除篩選器所攔截到的任何異常——例如子網域中的方括號——直到注入在端到端流程中穩定為止。

Dark Reading 報導指出，Salesforce 的 URL 遮蔽功能迄今一直仰賴正規表達式比對來判斷某個字串看起來是否像 URL，而這正是網域得以用出乎意料的格式隱藏起來的原因。該公司表示，已改以符合規格的 URL 解析取代原有做法，並整合 URL 檢查機制，讓所有與 URL 相關的代理流量如今都經過單一閘道。

第三個缺陷：以代理自身名義進行的網路釣魚

這項 Slack 發現於同日發布在第二篇文章中，作者署名為 João Donato 及其同事，內容涉及身分而非資料。Agentforce 代理可直接發布到 Slack，其能力會以子代理形式呈現；Zenity 指出，Slack Knowledge 範本（包含其所有動作）只需點擊兩下即可新增。

研究人員所檢視的大多數 Slack 寫入動作都具備兩項保護措施：傳送前的確認步驟，以及叫用者歸因，讓收件者知道是哪位使用者的請求導致該訊息。 傳送 Slack 私訊兩者皆具備。 回覆 Slack 討論串兩者皆無。一旦 Agentforce 決定叫用該動作，訊息便會在未經核准且未標示來源的情況下送出——它只帶有代理程式的身分，完全沒有可回溯至提出要求者的資訊。

這產生了兩條攻擊路徑。已經能與代理交談的惡意內部人員，可以把網路釣魚訊息貼到正確的討論串中，然後全身而退，不會留下任何能追查到他們的線索，因為收件者會將其解讀為來自代理的訊息。外部攻擊者則可透過 Web-to-Lead 注入獲得相同結果：遭投毒的潛在客戶資料會指示代理回覆到 Slack 頻道，而代理會在未詢問觸發它的員工的情況下照做。第一篇文章提到的 URL 遮蔽繞過手法，正是讓釣魚連結得以通過篩選的原因；Zenity 後來發現，連結也可以藏在看似無害的 Markdown 文字背後。Zenity 和 Salesforce 都以相同措辭描述後果：員工是從一個已在其工作場所內運作的受信任系統收到訊息，而不是從不熟悉的外部寄件者收到；任何點擊連結並交出憑證的人，都會暴露電子郵件、Slack、原始碼儲存庫，以及該身分所能觸及的任何其他資源。

什麼是已經確立的，什麼不是

在此處檢視的各方來源中，有四件事已獲確認。Zenity 展示了這些攻擊鏈，並公布了影片概念驗證。Salesforce 承認這項分析，並在對 Dark Reading 與 SecurityWeek 的聲明中說明其所做的變更。這三個漏洞均未獲指派 CVE，Dark Reading 將此歸因於修補作業是在 Salesforce 這一方、也就是代管服務端進行，而非在客戶自行運行的軟體中。而 Salesforce 表示，目前沒有證據顯示其中任何一項曾遭利用來攻擊客戶。

尚未有定論的是任何與規模有關的事。本文所檢視的來源，都沒有說明有多少 Agentforce 租用戶執行過受影響的預設設定、是否有任何客戶資料真的流出客戶環境，或者是否有 Zenity Labs 與 Salesforce 以外的任何人去查找過。獨立媒體——Dark Reading、SecurityWeek、Infosecurity Magazine 與 The Register——各自報導了這些發現，並刊載了 Salesforce 的回應，但這些報導中沒有一篇提及自身對該攻擊的複現。目前沒有針對 SalesBleed 的第二份獨立技術調查，本文亦不暗示存在這樣一份調查。

該紀錄本身的來源也在一處細節上彼此矛盾，而這個矛盾值得點明，而非粉飾帶過。Zenity 於 9 月 24 日透過 Business Wire 發布的新聞稿表示，Salesforce 在「約兩週內」處理了 Zenity 所通報的特定 Trusted URLs 繞過問題。Zenity 技術文章中逐日的時間軸，則從 6 月 1 日通報送出當天，一路延伸到 8 月 18 日與 19 日修復獲得確認之時——更接近十一週。這兩種說法都出自同一個組織。

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 測試並確認這三項皆已修正。

Salesforce 所描述的變更很具體。Slack 中某些 Agentforce 動作的預設設定，現在會在傳送訊息前要求使用者確認，而該公司表示正直接聯絡客戶以檢視其設定。在 Trusted URLs 方面，正則表達式比對已移除，改用符合規格的解析，且 URL 檢查已整合至單一閘道，而非在工作流程的多個環節中處理。

Zenity 對 Slack 修補方案的結語是一項但書，而非全面放行。確認要求是一項設定，只需點擊一次就能關閉；一旦關閉，同樣的攻擊路徑便會再次可行。研究人員給建置代理程式的組織的建議是，要留意寫入動作的設定方式，而不是假定預設設定會一直有效。

為什麼研究人員說它能泛化

儘管這些細節是 Salesforce 特有的，Zenity 仍將 SalesBleed 界定為某種模式的實例。其自身的總結是：任何會讀取外部來源所提交紀錄、將連結或圖片呈現回給使用者，並且同時具備對敏感資料之工具存取權的代理，都會在同一處具備同樣的三項要素。研究人員將這種組合稱為致命三要素（lethal trifecta）的一種版本——私有資料、不受信任的內容與對外通道在同一身分上交會。

這個模式有在地歷史。《Dark Reading》報導，在 SalesBleed 發生的一年之前，Noma Security 的研究人員曾利用同一條 Web-to-lead 路徑觸及 Salesforce 資料，而 Salesforce 的回應是收緊其 URL 規則——也就是 Zenity 後來繞過的那套以正規表示式為基礎的遮蔽機制。一名 Salesforce 發言人向《Dark Reading》坦承，先前的回應只是權宜之計，而非全面性的解決方案，並表示這次的措施旨在更為穩健。

Zenity 共同創辦人暨技術長 Michael Bargury 在新聞稿中表示：「我們發現有多種方法可以突破旨在阻止 Agentforce 將企業資料傳送到未經核准目的地的安全邊界。」「硬性邊界仍是我們控制 AI 代理最強大的工具之一，但它們終究是軟體。當這些控制失效時，我們面對的是一個擁有高度自主權、且毫無界線的特權存取代理。」Zenity 安全研究總監 Tamir Ishay Sharbat 向 Dark Reading 提出更廣泛的觀點：賦予代理的權力越大，它就越危險；一個能自行向多個通道發送訊息，同時又能讀取合約、潛在客戶或應付帳款的代理，這種組合必將遭到濫用。Bargury 向同一家媒體提出第二個擔憂——代理正被建構成黑箱，以摘要取代日誌，這使得人們難以判斷代理做了什麼或為什麼這麼做。

讓這筆紀錄從示範跨入事件領域的，不是新技術，而是一項證據：客戶披露、CVE，或 Salesforce 或 Zenity 的聲明，指出這些鏈條曾被目擊使用。在此處審閱過的來源中，這些都不存在。在出現之前，SalesBleed 就如檔案所記載的那樣：一個高嚴重性漏洞，由發現者以 confidence-A 標準記錄，並經廠商確認已修復，且沒有任何已記錄的現實世界危害。