SalesBleed made Agentforce leak CRM Account data over DNS from a public lead form

Salesforce puts the subagent's output through a redactor before it renders. The subagent produced an image URL, and the redactor and the browser's URL parser read that same string differently ^[7]. The redactor passed it. The browser resolved it, and the fetch went to a domain the attacker controlled ^[8].

DNS is the channel because it is the one almost nobody blocks. The stolen Account values ride inside the hostname of that image URL, so resolving the hostname hands the labels to the attacker's DNS server as an ordinary query ^[8]. There is no HTTP response to inspect. Zenity's detection advice is to watch for long DNS labels aimed at unfamiliar TLDs such as .fun, next to external image URLs ^[12].

Two separate boundaries are in play. The sensitive read happens inside Salesforce, in the subagent; the exfiltration happens outside it, in the DNS resolver of the browser or a connected service ^[9]. A control that limits one leaves the other open ^[11].

The injection lives in a Web-to-Lead form, which Salesforce accepts from anyone with no authentication ^[4]. The payload then waits as lead text until an internal user runs a routine inquiry, at which point the subagent treats the lead's contents as instructions and reads Account values ^[5]. Because the planted lead persists, one submission can be triggered again by every later query that reads it ^[10].

Zenity ran this as a proof-of-concept, reported no exploitation in the wild, and says Salesforce has patched it ^[3]. The patch closes this instance. The same shape recurs on any platform where an agent reads attacker-controllable input ^[4], holds read scope wider than any single request needs ^[6], and emits URLs that get fetched ^[8]. The concrete fixes Zenity lists are to stop treating external inputs as instructions, cut the subagent's object and field permissions, block automatic rich-text fetches, and restrict DNS and HTTP egress to approved domains ^[11].