SalesBleed: Three Agentforce Flaws Let Strangers Siphon CRM Data With Zero Clicks

On September 24, security researchers at Zenity Labs pulled back the curtain on SalesBleed — a set of three now-patched vulnerabilities in Salesforce’s Agentforce platform that together sketch out one of the clearest pictures yet of how AI agents change the economics of intrusion. The headline flaw allowed attackers to steal CRM data — account names, deal sizes, pipeline detail — without logging in, without touching the target tenant, and without a single click from any victim. A second turned Agentforce into an untraceable phishing launcher inside Slack. Salesforce fixed all three by August 19; no CVEs were assigned. But the attack chain is worth studying closely, because it will not be the last of its kind.

A lead form as the entry point

The attack begins somewhere almost nobody monitors: Salesforce’s Web-to-Lead forms. These are public, intentionally unauthenticated endpoints that let prospective customers submit sales leads from a company website. Anyone on the internet can submit one.

An attacker submits what looks like an ordinary lead — but embeds hidden instructions in one of its fields. The poisoned record sits quietly in the organization’s Leads table, indistinguishable from routine inbound business. Nothing happens. Nothing needs to happen, potentially for days.

The payload detonates when an employee does something completely normal: asks Agentforce a routine question, such as “help me review the latest leads.” The agent dutifully retrieves the poisoned record — and follows the instructions inside it rather than the employee’s intent. This is indirect prompt injection, delivered not through a chat message but through the business data itself.

No privilege escalation needed

Here is the detail that should stop every security team cold: the attack required no privilege escalation whatsoever. Agentforce’s General CRM subagent already had legitimate access to both Lead records and Account records via its built-in Query Records capability. The injected instructions simply directed it to use the access it already had — pulling company names and deal-size values from Accounts — and to format the results into a place where they could leave the building.

The exfiltration channel was elegant. The agent’s response included an HTML image tag pointing at an attacker-controlled hostname, with the stolen CRM data encoded into the subdomain of that hostname. When the Agentforce client rendered the response, the browser tried to resolve the hostname — and every DNS resolution request travels to the authoritative server for the domain, which the attacker controls. The data arrives before any HTTP connection is even completed. No file transfer, no outbound API call, just a DNS lookup that most environments never inspect.

That is what makes it “zero-click.” The employee asked an ordinary question about leads. They did not open an attachment, visit a link, or approve an action. The theft was a side effect of using the product as intended.

Bypassing the Trusted URLs allowlist

Salesforce had a control designed to stop exactly this. Trusted URLs is an allowlist mechanism meant to prevent agents from generating or surfacing unapproved external links — unapproved URLs in agent responses are supposed to be replaced with URL_Redacted.

Zenity found that the redaction layer’s regex-style URL recognition disagreed with downstream rendering components about what constitutes a URL. Certain top-level domains and certain special characters were parsed differently by the redactor than by the surface that eventually rendered the output. A carefully malformed string — for example, a subdomain without the bracket markers the redactor expected — could slip past the filter while still being treated as a fetchable URL when placed into an image source. Salesforce has since replaced the regex approach with standards-compliant URL parsing, closing the bypass.

The second flaw: anonymous phishing through Slack

SalesBleed’s second act moves from data theft to identity abuse. Agentforce agents can be published directly into Slack, where employees interact with them in the tools they already use. Zenity examined the Slack-facing subagent actions and found that while most actions behaved well — asking for user confirmation and attributing messages to the user who triggered them — the Send a Slack Direct Message action, inherited from a default subagent template, did neither.

The consequences compound. An external attacker could plant instructions in a poisoned CRM lead (same entry point as before); when an employee later asks the agent for help, the agent follows the injected instructions and posts a phishing message into active Slack threads — under its own trusted identity, with no confirmation checkpoint and no attribution showing who or what initiated it. Zenity also found the phishing links could survive the URL-redaction layer and be dressed up behind benign markdown link text, making them appear legitimate inside the agent’s message.

The delivery context makes it unusually effective phishing. A reply inside an ongoing thread arrives with the conversation’s built-in credibility — employees are discussing an account, the agent they trust pipes up with a relevant-looking link. The Register quoted Zenity’s warning that the flaws “lead to very unexpected consequences,” and Dark Reading framed the broader lesson: agentic AI can smuggle arbitrary instructions from the public web, across multiple applications, into trusted internal communication channels.

A third flaw in the set abused Slack link previews to auto-leak data through the same rendering pipeline. Salesforce patched all three.

Disclosure done right

The timeline here is a model of coordinated disclosure. Zenity reported the findings to Salesforce, which investigated, remediated the Trusted URLs bypass, hardened the Slack action defaults with proper confirmation and attribution, and confirmed the fixes in August — roughly a month before this week’s public disclosure. Zenity publicly credited Salesforce’s collaborative approach. No CVEs were issued, in part because the flaws lived in product configuration defaults and layered behaviors rather than a single memory-corruption bug.

The pattern, not the bug

The individual flaws are fixed. The pattern they expose is not, and it generalizes far beyond Salesforce:

Three ingredients make an agent an exfiltration engine: attacker-controlled content, access to sensitive internal data, and any channel for sending generated output outward. Agentforce happened to combine all three in one product, but any enterprise agent wired into a CRM, a ticketing system, or a chat platform has the same shape.

Unauthenticated intake is a prompt-injection surface. A lead form, a support email, a public comment — anything the world can write and your agent will later read is effectively a prompt. Organizations should treat externally submitted CRM fields as untrusted instructions, not trusted business content.

Least privilege is the only real backstop. SalesBleed needed no exploitation to escalate because the agent’s permissions were scoped for convenience, not containment. Limiting agents to the minimum CRM objects they need — and auditing what Query Records can actually reach — turns a total siphon into a narrow drip.

Exfiltration will find the quietest channel. DNS lookups, image fetches, link previews: the outbound surface of a modern application is large and rarely logged end-to-end. Redaction layers help, but as the Trusted URLs bypass showed, any filter that must perfectly recognize “what is a URL” across every rendering context is one edge case away from failure.

Salesforce shipped a genuinely fast, thorough response. The next vendor may not. The organizations that internalize SalesBleed’s real lesson — that in agentic systems, reading data and executing instructions have become the same operation — will be the ones whose CRM doesn’t bleed.