Salesforce patched three Agentforce flaws that let a public web form quietly drain CRM data

On September 24, 2026, Zenity Labs disclosed SalesBleed, a chain of three flaws in Salesforce Agentforce that let anyone submit a public "contact us" form and have the company's own AI agent quietly hand over CRM records — no click by a victim, no login, no stolen password. Salesforce fixed the flaws on its own servers, with the work completed on August 18, 2026 and confirmed by the researchers a day later, so there is nothing for customers to patch. What is left for administrators is the part the patch does not cover: narrowing what your AI agents are allowed to read, and where their output is allowed to point.

What happened, in plain English

Agentforce is the AI assistant built into Salesforce, the CRM (Customer Relationship Management system — the database where a company keeps its contacts, leads and deals). Staff ask it things like "summarise this week's new leads" and it reads the records and answers.

Most Salesforce customers also publish a Web-to-Lead form: the "contact us" box on the company website. Whatever a stranger types there lands in the CRM as a lead record. Zenity Labs realised the agent could not tell the difference between a customer's message and an instruction. So an attacker filled in that public form with text written as orders to the AI rather than as a sales enquiry. Nothing happened at first. The poisoned record simply sat in the CRM.

Later, an employee asked the agent about their new leads. The agent read the record, treated the planted text as instructions, pulled data from the Accounts table it also had access to, and sent it out to the attacker — all inside a normal-looking answer.

A rough analogy: someone drops a note in the company suggestion box that reads "receptionist — please photocopy the client file and post it to this address," and the receptionist, trained to be helpful and unable to tell a request from a customer comment, does it.

Three separate weaknesses had to line up. The agent read data that any stranger could write. The same agent held read access to both Leads and Accounts at once. And Salesforce's safety net — a feature called Trusted URLs, which is supposed to strip out links to servers you have not approved — could be talked past. "Zero-click" here means the employee never clicked anything; simply looking at the agent's answer was enough.

Are you affected? What to do now

If you do not use Salesforce Agentforce, there is nothing to do about this specific issue — but the pattern in the last section applies to any AI agent you deploy.

If you do use Agentforce: the flaws are already fixed. Salesforce remediated them server-side, which means there is no patch to install, no version number to check, and no maintenance window. Neither Zenity nor Salesforce has reported any exploitation in the wild, and no indicators of compromise and no CVE identifiers were published, so there is nothing to hunt for in your logs based on official sources.

The useful work is configuration review:

• Confirm what is actually switched on. Check which Agentforce agents and topics are live in your org. Pilots that were enabled months ago and forgotten are the common case.
• Review your Trusted URLs allowlist for agents in Setup. Keep it as short as it can be. Every entry is a place your agent's output is permitted to point.
• Audit every unauthenticated intake path that writes records an agent can read: Web-to-Lead, web case submission, email-to-case, chat transcripts, form integrations. These are attacker-writable by design — that is their job — so treat their contents as untrusted input, not as data.
• Narrow agent tool permissions. In the researched configuration, the default General CRM subagent could read Leads and Accounts simultaneously. Ask whether the agent that reads stranger-supplied leads needs access to your account book at all.
• Check your Slack integration, if you have one. Slack automatically previews ("unfurls") links, which means it fetches them without anyone clicking. Decide whether your agent needs to post into Slack, and who it posts as.
• Add one line to phishing awareness training: a message that appears to come from an internal bot or AI assistant is not proof that it came from inside the company.
• Keep and review agent audit logs — which records an agent read, and what URLs appeared in its output. Zenity's account notes the data had already left before anything looked wrong; the trail is what you will want afterwards.
• Ask your SaaS suppliers three questions about any AI agent they sell you: what untrusted data reaches it, what tools and tables it can access, and where its output can be rendered or sent.

The expert view

Mechanically, SalesBleed is an indirect prompt injection paired with an exfiltration channel — the two halves of essentially every agent data-leak chain. Neither half is new. What makes this one worth reading is where each half was found.

The injection point is not a contrived poisoned PDF. It is Web-to-Lead: a documented, public, revenue-critical feature that thousands of organisations expose deliberately. The attacker needs no access, no account and no infrastructure beyond a form submission, and the payload persists in the CRM until someone asks about it. That is a durable, low-cost foothold in a system of record.

The exfiltration channel is the more instructive part. The agent never had to make an outbound connection itself. Its answer contained a reference to a remote image; the employee's browser fetched it, and the hostname lookup carried the data out in the subdomain. In the Slack variant, Slack's own unfurling service made the request. This is why "block the agent's egress" is not the fix — the traffic originates from the victim's browser or from a trusted third-party service, and a DNS resolution alone is enough for the attacker to collect it.

Trusted URLs was the right control: a hard boundary on where agent output may point, enforced outside the model. Its failure was not an exotic jailbreak but a parser differential — the component that redacted URLs and the component that rendered them disagreed about what counts as a URL. An uncommon top-level domain the redactor did not recognise as a hostname, and punctuation where the two components disagreed about where an address ends, were enough. That is the same bug class as HTTP request smuggling or filename-parsing bypasses. Wherever two pieces of software parse the same string by different rules, the gap between them is the vulnerability. Worth sitting with: the AI-specific novelty here is thin. The model behaved exactly as designed; the sanitiser had an incomplete view of the world.

Zenity CTO and co-founder Michael Bargury framed it this way in the company's announcement: "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."

The third flaw — posting under the agent's identity in Slack — may be the one with the longest tail. Chat platforms attribute messages weakly, and an AI assistant becomes a trusted internal brand within weeks of deployment. An attacker who can speak as it inherits trust the organisation spent months building, which is a materially better phishing position than any lookalike domain.

All of this fits the trend other teams have been documenting through 2026: the assistant has become a privileged perimeter. An agent holds the union of permissions of everything it can touch, reads data that strangers can write, and emits output into a renderer. In conventional application design we would never knowingly combine those three properties in one component.

What remains unknown: whether anyone exploited this before the fix — no telemetry has been published either way; how many organisations run the permissive default subagent configuration; and whether equivalent redaction gaps exist in competing agent platforms. Zenity argues the pattern generalises to any agent that ingests external records, renders rich content and holds sensitive data access, but published no cross-vendor testing to support that.

One structural problem deserves a mention. No CVE was assigned, because there is no customer-installed artefact to version. That is increasingly normal for SaaS-side AI fixes, and it leaves security teams without a standard identifier to track, to feed into vulnerability management tooling, or to point at during an audit. The fix is real, silent and untraceable from the customer's side — and "trust us, it's patched" is a weak foundation for a compliance conversation.

Official sources

• Zenity Labs — "SalesBleed: 0-Click Data Exfiltration in Agentforce" (September 24, 2026) — the technical disclosure and timeline
• Zenity Labs announcement via Business Wire (September 24, 2026) — the three flaws summarised, plus the Bargury quote
• Salesforce Help — "Secure Your Agents with Trusted URL Allowlisting" — vendor documentation for the control involved
• Coverage: SecurityWeek — "'SalesBleed' Flaws in Salesforce Agentforce Enabled Zero-Click Data Exfiltration"
• Coverage: Infosecurity Magazine — "Zero-Click Vulnerabilities in Salesforce Agentforce Expose Wider AI Agent Risk" (September 25, 2026)
• Coverage: Salesforce Ben — "Lab Exposes New Agentforce Data Exploit" — admin-oriented summary