SalesBleed: One Public Lead, Three Agentforce Flaws, Zero Clicks

On 24 September 2026, Zenity Labs published research it calls SalesBleed: three vulnerabilities in Salesforce Agentforce, the CRM vendor's platform for building and deploying AI agents, that let a stranger pull customer records out of a company's Salesforce org and then use that company's own agent to phish its staff. Two of the three need no click from anyone inside the company. The exposure applies to Agentforce tenants that accept Web-to-Lead submissions, and to any agent a tenant has published into Slack. Dark Reading reports that no CVE identifiers were assigned, and Salesforce told the outlet it has no evidence of exploitation against any customer. The full record, with the archive's own confidence grade and harm status, sits in the Orca AI Incident Archive, which logs each documented agent incident against its cited sources.

How a public lead form becomes a data channel

Web-to-Lead is Salesforce's official mechanism for collecting leads, and it is unauthenticated by design — it exists so that anyone on the internet can submit a form and have the contents land in the customer's CRM. Zenity's first post, credited to Alex Apostolov and colleagues, opens with that as the entire entry condition: no account to suspend, no session to revoke, no login event to detect. The attacker never touches the tenant.

The chain the researchers describe runs in five moves:

• The attacker submits a lead through a public Web-to-Lead endpoint, with a hidden prompt injection in one of its fields. It looks like an ordinary enquiry.

• The lead sits there until an employee asks their agent something completely ordinary — Zenity's example is "check my latest leads and help me with the newest one."

• The agent reads the poisoned record and follows the instructions inside it, using the Query Records tool that the default General CRM subagent already holds to query the Accounts table. Zenity is explicit that no privilege escalation was needed: the same subagent ships with read access to both Leads and Accounts, and those are defaults rather than misconfigurations.

• It writes the values it retrieved — a company name and a deal size, in the researchers' example — into the subdomain of a hostname the attacker controls, and prints the result back to the user as an HTML image tag.

• The chat surface renders external image sources without sanitisation or a confirmation step, so the client resolves the hostname. The data leaves inside the DNS query.

That last step is the part worth slowing down on. Because the payload travels in the DNS lookup, the HTTP request that follows is irrelevant — it can fail, time out or be blocked outright, and the data has already gone. Zenity notes this survives HTTP egress controls. A single DNS label is capped at 63 characters and a full name at 253, so one submission leaks a slice; the researchers describe draining an entire Accounts table one account at a time through repeated requests, which is where the "bleed" in the name comes from.

There is a second exit that needs even less: for agents published into Slack, no image tag is required. Slack turns raw URLs into previews and crawls the link to build one, so printing the URL is enough to trigger the same DNS lookup. SecurityWeek quotes Zenity's summary of the resulting behaviour: Slack initiates requests carrying CRM data to attacker-controlled infrastructure as soon as the links appear.

Zenity is careful about what "zero-click" means here, and the distinction matters. The employee does exactly one thing: asks their own agent a normal question about their own leads. They do not open an attachment, follow a link, or interact with anything the attacker sent. Everything after that question is automatic. The malicious lead also stays in the Leads table like any other record, so it can fire again every time an employee reviews it — and an attacker who wants a wider channel can simply submit more leads. SecurityWeek records a detail that makes the failure sharper still: Agentforce reported that the content had been blocked by the organisation's security policies, even though the CRM data had already reached the attacker's server.

Why the Trusted URLs filter did not hold

Trusted URLs is the Salesforce control meant to stop exactly this — it restricts the external destinations Agentforce can reach and strips links and images pointing at domains nobody has approved. Zenity found two edge cases that, combined, walked straight through it.

The first was the top-level domain. The redactor recognised only a fixed list of TLDs, and .fun — the domain used by the app.interactsh.com out-of-band testing platform — was not on it. A hostname ending in an unrecognised TLD might not register as a hostname at all. The second was where a URL ends: the redactor and the surface rendering the answer disagreed about termination characters, and curly braces and square brackets sat in the gap. A string such as https://random_string.oast.fun/{email} is not a valid URI under RFC 3986, yet it still produces the DNS query the attack needs. The redactor saw a malformed non-URL and left it alone; the browser was willing to fetch it as an image source.

One structural detail made the bypass tunable. Redaction runs after the agent has generated its output, as a separate process the model knows nothing about. Zenity found the agent's raw output and the redacted version both present in the responses sent to the client, which let the researchers compare the two and strip whatever anomalies the filter was catching — square brackets in a subdomain, for instance — until the injection was stable end to end.

Dark Reading reports that Salesforce's URL redaction had until now relied on regular-expression matching to decide whether a string looked like a URL, which is what allowed domains to be hidden in unexpected formats. The company says it has replaced that with spec-conformant URL parsing, and has consolidated URL inspection so that all URL-related agent traffic now passes through a single gateway.

The third flaw: phishing under the agent's own name

The Slack finding, published the same day in a second post credited to João Donato and colleagues, is about identity rather than data. Agentforce agents can be published directly into Slack, and their capabilities arrive as subagents; Zenity notes that the Slack Knowledge template, including all its actions, can be added in two clicks.

Most Slack write actions the researchers examined carried two protections: a confirmation step before sending, and invoker attribution telling recipients which user's request caused the message. Send a Slack Direct Message did both. Reply to a Slack Thread did neither. Once Agentforce decided to invoke that action, the message went out unapproved and unattributed — it carried the agent's identity and nothing that pointed back to whoever asked for it.

That produced two attack paths. A malicious insider who can already chat with the agent can post phishing into the right thread and walk away with nothing tracing it to them, because recipients read it as a message from the agent. An external attacker gets the same result through the Web-to-Lead injection: the poisoned lead tells the agent to reply into Slack channels, and it does so without asking the employee who triggered it. The URL-redaction bypass from the first post is what lets the phishing link survive filtering; Zenity later found that links could also be hidden behind benign-looking markdown text. Zenity and Salesforce both frame the consequence in the same terms: employees receive the message from a trusted system already operating inside their workplace rather than from an unfamiliar outside sender, and anyone who follows the link and hands over credentials exposes email, Slack, source code repositories and whatever else that identity can reach.

What is established, and what is not

Four things are settled across the sources reviewed here. Zenity demonstrated the attack chains and published video proof of concept. Salesforce acknowledges the analysis and describes the changes it made — in statements to Dark Reading and to SecurityWeek. No CVE was assigned to any of the three flaws, which Dark Reading attributes to the fixes being made on Salesforce's side of a hosted service rather than in software customers run. And Salesforce states that it has no evidence at this time that any of it was exploited against a customer.

What is not settled is anything about scale. No source reviewed here states how many Agentforce tenants ran the affected defaults, whether any customer data actually left a customer environment, or whether anyone outside Zenity Labs and Salesforce looked for it. The independent outlets — Dark Reading, SecurityWeek, Infosecurity Magazine and The Register — each reported the findings and carried Salesforce's response, but none of that coverage reports its own reproduction of the attack. There is no second independent technical investigation of SalesBleed, and this article does not imply one.

The record's own sources also disagree on one detail, in a way worth naming rather than smoothing over. Zenity's press release, distributed through Business Wire on 24 September, says Salesforce addressed the specific Trusted URLs bypasses reported by Zenity "within approximately two weeks." The day-by-day timeline in Zenity's technical post runs from 1 June, when the report was sent, to 18 and 19 August, when the fix was confirmed — closer to eleven weeks. Both accounts come from the same organisation.

What Salesforce changed, and when

The disclosure ran long and, by Zenity's account, cordially. The findings went to Salesforce by email on 1 June 2026; Salesforce confirmed them the next day and said it was working on fixes; the two teams held a technical call on 16 June; Salesforce closed the disclosures on 17 June noting that engineering was still working. On 18 August Salesforce confirmed the fixes, and on 19 August Zenity verified the Trusted URLs bypass specifically. Attribution on the Slack action was confirmed fixed on 20 August. Requiring confirmation by default took longer: on 25 August Salesforce said it was still working on it, on 10 September it gave 21 September as the target, and on 21 September Zenity tested and confirmed all three.

The changes Salesforce describes are specific. Default settings for certain Agentforce actions in Slack now require user confirmation before a message is sent, and the company says it is contacting customers directly to review their configurations. On Trusted URLs, the regex matching is gone in favour of spec-conformant parsing, and URL inspection has been consolidated into one gateway rather than being handled at several points in a workflow.

Zenity's closing note on the Slack fix is a caveat rather than an all-clear. The confirmation requirement is a setting, and it takes one click to turn off; once it is off, the same attack path is available again. The researchers' advice to organisations building agents is to watch how write actions are configured rather than to assume the default holds.

Why the researchers say it generalises

Salesforce-specific as the details are, Zenity frames SalesBleed as an instance of a pattern. Its own summary is that any agent which reads records submitted by external sources, renders links or images back to a user, and also holds tool access to sensitive data has the same three ingredients in the same place. The researchers call the combination a version of the lethal trifecta — private data, untrusted content and an outbound channel meeting in one identity.

The pattern has local history. Dark Reading reports that a year before SalesBleed, researchers at Noma Security used the same Web-to-lead route to reach Salesforce data, and that Salesforce responded by tightening its URL rules — the regex-based redaction that Zenity then walked around. A Salesforce spokesperson acknowledged to Dark Reading that the earlier response was a quick fix rather than a comprehensive one, and said this one is intended to be more robust.

"We found multiple ways to break through the security boundary designed to stop Agentforce from sending enterprise data to unapproved destinations," Michael Bargury, Zenity's co-founder and chief technology officer, says in the release. "Hard boundaries remain one of the strongest tools we have for containing AI agents, but they are still software. When those controls fail, we are left with a privileged access agent with high autonomy and no bounds." Tamir Ishay Sharbat, Zenity's director of security research, put the wider point to Dark Reading: the more power an agent is given, the more dangerous it is, and an agent that can message multiple channels by itself while also reading contracts, leads or accounts payable is a combination that will be abused. Bargury added a second concern to the same outlet — that agents are being built as black boxes, with summaries instead of logs, which makes it hard to tell what an agent did or why.

What would move this record from demonstration to incident is not a new technique but a piece of evidence: a customer disclosure, a CVE, or a statement from Salesforce or Zenity that the chains were seen in use. None of that exists in the sources reviewed here. Until one does, SalesBleed stands as what the archive records it as — a high-severity vulnerability, documented to a confidence-A standard by the people who found it and confirmed as fixed by the vendor, with no recorded real-world harm.