SalesBleed: A Web Form Lead Could Steer Salesforce Agentforce Into Leaking CRM Data

A stranger who submits a Web-to-Lead form containing hidden instructions could get a Salesforce Agentforce agent to read the Accounts table and send company names and deal sizes to a server the attacker controls, with no click from any employee. Zenity Labs published the three flaws, which it calls SalesBleed, on Sept. 24. No CVE identifier has been assigned in the write-up.

The attack needs four things, per Zenity's post: a public, unauthenticated Web-to-Lead endpoint, an agent with read access to both the Leads and Accounts tables (the default General CRM configuration), an employee who asks the agent a routine question about leads, and an agent able to render external URLs or images.

How the exfiltration chain works

The entry point is prompt injection through the lead itself. Instructions placed in a lead field sit dormant until an employee asks the agent about that lead, at which point the agent treats them as commands and queries the Accounts table.

The next link is a bypass of Trusted URLs, the mechanism meant to stop Agentforce showing links and images from untrusted sources. Zenity found two edge cases: an unrecognised top-level domain (.fun) and disagreement between the redactor and the browser about where a URL ends when it contains curly braces or square brackets. A malformed URL carrying the stolen data therefore survived redaction.

The last link is the channel out. An HTML image tag or Slack URL unfurl triggers a DNS lookup on its own, and data placed in the subdomain reaches the attacker's nameserver. The same lookup trick appears in our report on an OpenAI agent that sent questions to an outside chatbot through DNS.

The third reported flaw is different in kind. The Register says Agentforce's "Reply to a Slack Thread" action required no user confirmation and carried no attribution to whoever invoked it, so an insider or outsider could phish staff under the agent's trusted identity and stay anonymous.

What data was exposed

Zenity lists account names, deal sizes, contact information and other CRM records reachable through the agent's Query Records tool. Neither source gives a count of organisations running the vulnerable configuration.

Where the two accounts differ

Both accounts agree on the start of the timeline. They differ on the end.

Date	Event	Source
June 1	Zenity reports to Salesforce	Both
June 2	Salesforce confirms it is investigating	Both
June 16	Technical call with Salesforce security	Zenity
Aug. 18	Salesforce confirms fixes complete	Zenity
Aug. 19	Zenity verifies the Trusted URLs fix	Both
Sept. 21	All three flaws confirmed fixed	The Register
Sept. 24	Public disclosure	Both

Zenity says all identified vulnerabilities were remediated by Aug. 18. The Register reports the URL redaction bypass was fixed Aug. 19 and all three flaws by Sept. 21, and says it found no separate remediation detail for the Slack action. Reading both, the Trusted URLs fixes were in place a month before disclosure, while the date for the Slack fix is not settled.

What Zenity says it means

Michael Bargury, Zenity Labs co-founder and CTO, is quoted by The Register: "The bigger lesson here is about what it takes to keep AI agents contained." He added that secure-by-design "remains essential but for agents it may no longer be enough."

The Register's article carries no quote from Salesforce, and Zenity's post says Salesforce "hardened the Trusted URLs mechanism to prevent similar attacks." The preconditions Zenity lists point to what an administrator can review: whether a Web-to-Lead form is public, and whether an agent needs read access to both Leads and Accounts. Agent tooling outside Salesforce is collecting disclosures too, as in the Paperclip advisory count.

The date of the Slack fix is the open item. The Register found no separate remediation detail for it, and Zenity's post does not give one.