SalesBleed: a public web form hijacked the CRM agent

A stranger filled out a contact form. Nobody clicked anything. Account names and deal sizes left the building over DNS. That is the short version of SalesBleed, the Agentforce vulnerability chain Zenity Labs published this week. Salesforce has patched it. The architecture that made it work is still sitting in most agent deployments, including probably yours.

What actually happened

Three weaknesses chained into one attack:

• The entry point was Web-to-Lead — Salesforce's own public, unauthenticated lead-capture form. An attacker submitted a lead whose fields contained hidden instructions. Nothing fired yet. The payload sat in the CRM and waited.
• The trigger was an employee doing their job. Someone asked their Agentforce agent about recent leads. The agent read the poisoned record and followed the injected instructions: query the Accounts table, pull company names and deal sizes, stuff them into a URL.
• The exfiltration needed no click. The agent rendered that URL as an HTML image tag. The browser dutifully tried to load the image, which fired a DNS lookup to the attacker's nameserver with the stolen data sitting in the subdomain. Zenity's proof-of-concept used a host ending in .fun.
• The guardrail had gaps. Salesforce's Trusted URLs redaction was supposed to block exactly this. It missed uncommon TLDs, and it disagreed with the browser about where a URL ends when curly braces and square brackets are involved.
• A third flaw let an attacker borrow a trusted identity — an Agentforce-connected Slack agent, used to push phishing messages to employees from a source they had no reason to distrust.

Zenity reported it on June 1. Salesforce confirmed the next day, and the fixes were verified in mid-August. No CVEs were assigned. Per SecurityWeek, the whole chain is closed.

Why agent security matters for your business

Read the chain again and notice what is not in it. No stolen password. No malware. No insider. No access to your tenant. A public form and patience.

Every agent we build has the same shape: a model, a set of tools, and some text it did not write. That last part is the whole problem. Your agent cannot tell the difference between your instructions and a sentence a stranger typed into a form field, because to the model they are the same kind of thing — tokens in a context window. Salesforce shipped a filter to catch the bad ones. The filter had two parsing bugs. That is not a Salesforce failure so much as a preview of every filter anyone ships for this.

So stop treating output filtering as the control. Build the boundary at the tool layer instead. When we wire an agent to a CRM, the agent that reads untrusted records does not hold credentials that can query the whole Accounts object, and it does not get to render arbitrary markup. Separate the reader from the writer. Scope the token to the record, not the table. Allowlist egress hosts at the network, so a lookup to a .fun domain fails before DNS resolves it. And log every outbound request an agent causes, because SalesBleed was invisible in an audit log that only tracked user actions.

If you run an agent on any public intake — lead forms, support tickets, review replies, inbound email — assume the input is hostile and design like it.

Sources: Zenity Labs, SecurityWeek.