Nobody Hacked Salesforce. The Agent Just Followed Instructions.

Summary

SalesBleed is described as a set of three Salesforce Agentforce vulnerabilities discovered by Zenity Labs and disclosed in September 2026. The central demonstrated path combined indirect prompt injection through a public Web-to-Lead form with an outbound-link control bypass, allowing an agent's legitimate CRM access to be redirected toward data exfiltration. The supplied account concerns vulnerability research; it does not document an in-the-wild campaign or identify a malicious actor.^[0]

The attacker-controlled instruction entered Salesforce as ordinary lead data. When an employee later asked Agentforce to review recent leads, the agent retrieved the poisoned record and followed the embedded instruction. A malformed address bypassed the Trusted URLs control while remaining usable as an HTML image source. Rendering that image generated a request to an attacker-controlled hostname, with sensitive CRM fields—including company names and deal sizes—encoded into the requested subdomain. The article describes DNS lookup as the data-leakage channel.^[0]

The article reports that Salesforce fixed the specific Trusted URLs bypass and that Zenity verified the patch in August 2026. It provides no affected release range or separate remediation account for every vulnerability grouped under SalesBleed. All findings in this dossier rely on one secondary Bonfy article, which also promotes the publisher's governance products; the referenced primary research and vendor confirmation are not independently available in the supplied evidence.^[0]

Attack chain

1. 1. Poison public lead intake: An attacker submits a public Web-to-Lead form containing a hidden instruction in a text field. The submitted content becomes an ordinary-looking CRM lead record. The described entry path requires neither stolen credentials nor direct access to the Salesforce tenant.^[0]
2. 2. Trigger retrieval through a legitimate task: An employee later asks Agentforce to perform a routine activity, such as reviewing recent leads. Agentforce retrieves the poisoned record into its working context. Although no malicious-link click is required, the described sequence does include this normal employee request.^[0]
3. 3. Follow the embedded instruction: Agentforce acts on the instruction carried inside the retrieved lead rather than remaining confined to the employee's intended review task. Its existing access to CRM records supplies the data used in the subsequent exfiltration.^[0]
4. 4. Bypass the outbound-link control: The exploit uses a malformed address involving top-level-domain handling and specially crafted characters to evade Trusted URLs checks. The address still functions when placed in an HTML image source.^[0]
5. 5. Leak data during image rendering: When the client renders the image, it requests an attacker-controlled hostname whose subdomain contains encoded CRM fields. The article identifies the resulting DNS lookup, rather than email or a download link, as the exfiltration channel.^[0]

Disclosure timeline

How it works

The injection crossed a data-to-instruction trust boundary. A public intake form accepted attacker-controlled text, and Salesforce stored that text as a lead record. The content became operationally significant only when Agentforce retrieved it during a legitimate task and treated its embedded instruction as something to follow. The account therefore does not depend on compromising the employee's credentials or obtaining direct tenant access.^[0]

The agent already possessed access to lead records and the ability to produce rich content. The exploit redirected those legitimate capabilities into an unintended data flow. This distinguishes the demonstrated failure from a conventional authentication bypass: the attacker manipulated how authorized access was used rather than first acquiring the user's account.^[0]

The concrete control bypass involved Agentforce's Trusted URLs mechanism, which was intended to prevent generation of or visits to unapproved external links. The article says certain top-level domains and specially crafted characters escaped consistent detection. It does not provide the exact payload, affected parser behavior, or character sequence, so the available evidence supports the bypass mechanism but not a reproducible implementation.^[0]

The malformed address retained browser-relevant functionality inside an HTML image source. Rendering the image caused a request toward an attacker-controlled hostname, with company names and deal figures encoded in the subdomain. Because hostname resolution carried the sensitive values, the account identifies DNS lookup itself as the leakage path rather than requiring an email message or downloadable artifact.^[0]

Technical detail is uneven across the reported three-vulnerability set. The supplied article explains the prompt-injection and Trusted URLs chain and mentions a related Slack-agent identity issue, but it does not explain that identity issue's mechanics. The reported fix should therefore be understood specifically as remediation of the described Trusted URLs bypass, not evidence that every possible prompt-injection or agent-identity failure has been eliminated.^[0]

Affected versions and patch status

Key takeaways

• No stolen credential or malicious-link click was needed in the described demonstration, but a routine employee request still supplied the retrieval trigger. Those are different claims and should not be collapsed into an assertion that the chain required no user activity whatsoever.^[0]
• The important trust boundary was between externally supplied CRM content and instructions the agent would execute. Legitimate read access did not establish that the contents of a retrieved lead were authorized directions.^[0]
• The exfiltration mechanism joined an allowlist bypass to client-side image rendering and DNS resolution. Assessing only account permissions or conventional email and download channels would not address the specific path described.^[0]
• Evidence confidence is constrained by a single secondary account. No actionable attacker infrastructure, exact affected release range, or documented malicious deployment is supplied; the strongest supported conclusion is a reported researcher-demonstrated chain with a specifically reported bypass fix.^[0]

Defensive actions

• Inventory public intake paths that feed Agentforce or other enterprise agents, starting with Web-to-Lead forms and extending to support tickets and feedback fields where applicable.: The demonstrated entry point was unauthenticated form content later retrieved as trusted business context. The article explicitly recommends mapping these intake-to-agent paths rather than limiting review to authenticated agent interfaces.^[0]
• Pressure-test outbound allowlists and redaction controls against malformed addresses, encoding variants, and the rich-content rendering path used by the agent.: The reported bypass escaped Trusted URLs checks but remained functional in an HTML image source. Testing should address the actual rendering behavior described in the research, not merely whether an address appears acceptable to a static allowlist.^[0]
• Treat the reported Trusted URLs remediation as a fix for the identified bypass, not as closure of the wider prompt-injection risk.: The article reports a verified fix for that specific bypass while emphasizing that the broader mechanism—an agent acting on adversarial retrieved content using legitimate access—remains a separate governance concern.^[0]
• Review whether policy and audit coverage connect the employee's initiating task with the agent's subsequent data retrieval and transmission.: The chain began with an ordinary employee request and continued through agent access and client rendering. The article recommends reviewing disconnected human and agent governance models and evaluating actual data movement rather than relying solely on configured permissions.^[0]