Salesbleed exposed a trust-boundary failure in Salesforce Agentforce that let poisoned Web-to-Lead records steer agents toward CRM data exfiltration and employee-facing Slack phishing. Zenity disclosed the weaknesses on September 24, 2026, after Salesforce completed fixes. Salesforce said on September 25, 2026, that it had found no evidence of customer exploitation.
What is Salesbleed?
Salesbleed is a set of Salesforce Agentforce weaknesses that allowed attacker-controlled instructions stored in public lead submissions to influence connected CRM and Slack actions. According to Zenity’s September 24, 2026 research, the demonstrated outcomes included zero-click data exfiltration through DNS requests and phishing messages delivered under an agent’s trusted Slack identity.
Indirect prompt injection is an attack technique that places malicious instructions inside data an AI agent later reads as ordinary content. Here, an attacker didn’t need a Salesforce login. Salesforce Web-to-Lead provided the unauthenticated entry point, and the poisoned text remained in the Leads table until routine work brought it before Agentforce.
The finding matters because the agent transformed untrusted website input into action inside authenticated business systems. The attacker’s text crossed from a public form into Salesforce records, reached tools with broader data access, and could emerge as an internal Slack message. That is trust laundering, not a conventional account takeover.
Salesforce told SecurityWeek on September 25, 2026, that it had no evidence the attack paths were exploited against customers. Dark Reading reported on the same date that no CVE identifiers, affected-customer totals, stolen-credential counts, or financial-loss figures had been published.
How did the Salesbleed attack chain work?
The Salesbleed chain began with an attacker submitting malicious instructions through Salesforce Web-to-Lead. During a later lead review, Agentforce interpreted the stored text and could invoke connected CRM or Slack capabilities. Zenity’s September 24, 2026 proof of concept required no employee click to initiate either demonstrated data-exfiltration path.
The sequence exposed four separate trust decisions. Each one looked reasonable in isolation, but their combination let external content influence authenticated actions:
- An attacker placed instructions in an unauthenticated Web-to-Lead submission.
- Salesforce stored the submission as an ordinary lead with no automatic expiration after one agent interaction.
- The default General CRM subagent read the lead and could query both Leads and Accounts through its Query Records tool.
- Agentforce generated an external image request or invoked a connected Slack action, producing an outbound request or employee-facing message.
No privilege escalation was needed in Zenity’s 2026 demonstration. The General CRM subagent already had the access required to move from attacker-supplied lead content to account information. That distinction should shape the response: patching a parser helps, but reducing an agent’s legitimate permissions limits what a future injection can reach.
The persistence is an easily missed risk. A malicious lead remained a normal CRM record and could influence later interactions repeatedly; it wasn’t consumed or invalidated after one review. Security teams already tracking enterprise risks from autonomous AI agents should therefore treat stored external records as durable attack inputs, not one-time prompts.
How could Salesbleed extract Salesforce CRM data?
Salesbleed could encode Salesforce company names and deal sizes into attacker-controlled DNS hostnames, according to Zenity’s September 24, 2026 proof of concept. Automatic rendering of an external HTML image and Slack’s automatic URL unfurling both generated DNS lookups, allowing information to leave the environment without an employee clicking the generated link.
Zenity reported in 2026 that Salesforce’s Trusted URLs control could be bypassed because the redactor and downstream renderer disagreed about top-level-domain recognition and URL termination. The proof of concept used a .fun domain that the redactor failed to recognize. Salesforce confirmed completion of fixes on August 18, 2026, and Zenity verified the Trusted URLs repair on August 19, 2026.
| Exit path | Automatic behavior | Employee click required | Observable result |
|---|---|---|---|
| External HTML image | Renderer fetched the generated image URL | No | DNS lookup to an attacker-controlled hostname |
| Slack URL unfurl | Slack processed the generated URL preview | No | DNS lookup to an attacker-controlled hostname |
| Slack thread reply | Agentforce posted through a connected action | No before remediation | Employee-facing message from the agent identity |
The bandwidth was small per request, but not trivial over time. Zenity noted in 2026 that a DNS label can hold up to 63 characters and a full domain name up to 253 characters. At a simplified 63-character payload per lookup, 100 successful lookups could carry 6,300 encoded characters before accounting for encoding overhead and domain components.
That calculation explains why low-bandwidth DNS leakage still deserves attention. Persistent poisoned records can generate repeated queries, while ordinary DNS logs may receive less scrutiny than API exports. Detection programs should connect agent prompts, tool calls, DNS activity, and record provenance rather than examining each stream alone.
How did Agentforce become a Slack phishing tool?
Salesbleed abused the standard Slack Knowledge subagent’s Reply to a Slack Thread action to turn injected instructions into internal messages. Before remediation in 2026, the action could send without user confirmation or visible attribution to the invoking user, making attacker-directed content appear to come from a trusted Agentforce identity inside Slack.
Zenity reported on September 24, 2026, that administrators could add the Slack Knowledge subagent and accompanying actions to an Agentforce agent in two clicks. The researchers also found that Markdown could hide a phishing destination behind benign-looking link text. An internal delivery channel gave the resulting lure credibility that an unsolicited external email wouldn’t have.
Salesforce’s July 3, 2026 support guidance says Agentforce Slack actions execute in the authenticated invoking user’s security context, with a separate per-user session for every invocation. Yet identity context alone didn’t solve the presentation problem: recipients needed to see who caused the agent to post and users needed a chance to approve outbound content.
Salesforce changed both points. Zenity verified on August 20, 2026, that thread replies attributed messages to the invoking user, and on September 21, 2026, confirmed default confirmation for Reply to a Slack Thread. Zenity said the confirmation setting could still be disabled with one configuration click after the fix, so administrators must check effective settings rather than assume safer defaults remain enabled.
Honestly, a write-capable workplace agent shouldn’t post security-sensitive content without approval merely because the feature permits it. The incident also illustrates why understanding how AI agents select and invoke tools matters beyond coding: tool choice becomes a security decision when the destination is a trusted communications channel.
Was Salesbleed fixed, and are customers still at risk?
Salesforce fixed the reported Salesbleed attack paths before Zenity’s public disclosure on September 24, 2026. Zenity confirmed all reported fixes by September 21, 2026, including the Trusted URLs repair, user attribution for Slack thread replies, and confirmation by default. Misconfiguration and future prompt-injection variants still require defensive controls.
The remediation timeline is unusually useful. Salesforce confirmed the data-exfiltration fixes were complete on August 18, 2026. Zenity verified the URL bypass fix on August 19 and message attribution on August 20; Salesforce said on August 25 that default confirmation work continued, before Zenity completed final testing on September 21.
By September 24, 2026, Zenity described the disclosed chains as closed by default. Salesforce then said on September 25 that it was contacting customers to review Agentforce configurations. No public evidence showed customer exploitation, but absence of reported exploitation doesn’t prove that historical logs contain no suspicious activity.
The strongest counterpoint is straightforward: these were repaired research findings, not a documented mass breach. Still, dismissing Salesbleed as a closed parser bug would miss the architectural lesson. Organizations using broad agent permissions, public data ingestion, and unapproved outbound actions can recreate the same class of failure through another model or integration.
How should administrators defend Agentforce workflows?
Administrators should mark externally sourced Salesforce records as untrusted, narrow every Agentforce subagent’s tool and data scope, retain approval for outbound messages, and log the complete trigger-to-action chain. Zenity’s 2026 recommendations specifically emphasized monitoring agent write actions and keeping confirmation requirements enabled rather than relying only on Salesforce’s remediated defaults.
Start with provenance. Web forms, imported spreadsheets, support tickets, emails, and partner feeds should carry machine-readable source labels that survive ingestion and retrieval. An agent shouldn’t treat text from a public form as an instruction merely because Salesforce stored it in a trusted table.
Next, separate reading from acting. A lead-triage agent usually needs selected lead fields; it may not need unrestricted account queries or permission to post into Slack. At my preferred baseline, any action that sends a message, modifies a record, or contacts an external host gets explicit approval and records the invoking user.
Audit trails must join the original record, retrieved text, model decision, tool arguments, network destination, approval event, and final action. Conventional SaaS logs often capture only fragments. Teams evaluating shadow AI discovery and monitoring platforms should test whether products preserve that causal chain rather than merely inventorying applications.
Retrospective review also has value. Search 2026 Agentforce logs for unusual external domains, image rendering from generated responses, Slack unfurl requests, repeated access to the same lead, and account queries that followed Web-to-Lead ingestion. The pitfall few check is recurrence: one poisoned record can remain dangerous after the first alert is closed.
Salesbleed FAQ
Did Salesbleed require stolen Salesforce credentials?
Salesbleed did not require stolen credentials in Zenity’s 2026 proof of concept. The attacker entered malicious instructions through the unauthenticated Salesforce Web-to-Lead feature, while later Agentforce actions ran through legitimate connected access.
Was Salesbleed assigned a CVE?
Salesbleed had no reported CVE identifier as of September 25, 2026, according to Dark Reading. Public reporting also provided no affected-customer count or financial-loss total.
Did Salesforce customers lose data?
Salesforce said on September 25, 2026, that it had no evidence Salesbleed was exploited against customers. Zenity demonstrated technically viable exfiltration in research, but a proof of concept is not evidence of a customer breach.
Can disabling Web-to-Lead prevent the attack?
Disabling Salesforce Web-to-Lead removes the entry point used in Zenity’s 2026 demonstration, but it doesn’t address the broader indirect prompt-injection problem. Other external records can carry hostile instructions unless Agentforce workflows enforce provenance, limited permissions, approvals, and end-to-end logging.