Original OrbTrail analysis expanded with complementary research, practical context and verified references.
Zenity Labs disclosed three flaws under the SalesBleed name on September 24, 2026. Two chains began with a public Web-to-Lead form and ended in zero-click CRM data exfiltration through either an image rendered in the conversation or Slack's automatic URL unfurling. The third used the Reply to a Slack Thread action to publish messages under the agent's identity without prior confirmation and without visibly attributing the person who triggered the action. The research was reported to Salesforce on June 1; Zenity says the URL bypass was validated as fixed on August 19 and all remediations were tested by September 21. The described chains therefore should not be presented as exploitable by default today.
The central question is what an organization must prove after the patch: how can externally supplied content remain data, rather than gain authority to direct an agent that can also read sensitive records or write into a trusted channel? In the experiment, the attacker did not authenticate or escalate privileges. Hidden instructions were stored in a Lead; later, a legitimate employee request caused the agent to read that record. The same subagent held a Query Records tool that could reach both Leads and Accounts, and the response found an automatic route to a researcher-controlled domain.
OrbTrail's analysis is that the incident cannot be contained by one control. The URL redactor fix closes the known bypass; permissions limit which records a tool can reach; prompt-injection detection attempts to recognize hostile instructions; confirmation and attribution constrain write actions; and the channel decides whether a URL is rendered or unfurled automatically. A security program has to test these boundaries together. If every team validates only its component, the handoff between public input, reasoning, tool and interface can remain ownerless.
The public lead accepts untrusted content
Web-to-Lead is public by design. The record must remain data even when its text resembles an instruction to the model.
A legitimate question reads the poisoned record
The employee opens no link or attachment; execution begins while asking for help with recent leads.
The tool defines the exposed data
In the test, Query Records reached Leads and Accounts in one subagent. Existing permission set the radius without escalation.
Rendering and unfurling turn text into traffic
An HTML image or URL preview caused a DNS lookup. Data left in name resolution before a useful HTTP response was needed.
The patch must survive the entire journey
Verify redaction in every channel, minimal tool scope, active detection, write confirmation and invoker attribution.
The lead did not break into the org—it crossed the boundary as a valid record
The first complementary point is why the attack was zero-click without confusing it with anonymous database access. Web-to-Lead accepts external submissions precisely to create Lead records. The malicious payload was stored in a field and remained dormant. When an employee asked Agentforce to review the newest lead, the model received the record text alongside the legitimate task and interpreted part of that content as instructions. This is indirect injection: the command does not come from the authenticated user but from data that entered through another surface.
According to Zenity, those instructions directed Query Records to retrieve Account fields and place their values in a subdomain. The URL redactor and the component rendering the response disagreed about what counted as a valid URL when a hostname used an unrecognized top-level domain and particular terminating characters. The redactor allowed the string through while the browser still tried to load it as an image source. Slack's automatic URL expansion served a similar role. Because the values were embedded in the queried hostname, the researcher's authoritative DNS server could receive them even when the later HTTP request failed.
A useful retest should neither copy sensitive data nor turn the proof of concept into an exploit recipe. In a sandbox, create synthetic external records with harmless markers, run the same journeys sellers use and observe four outcomes: external text does not change the agent's objective; a query does not cross into objects or fields outside the use case; every unapproved destination is redacted consistently in web and Slack; and no marker appears in DNS or an external request. Repeat this for each enabled channel, because the bypass relied on different components interpreting the same output differently.
The exposure radius is the tool set, not the intent written in a topic
The second point asks why a request about Leads could reach Accounts. Current Salesforce documentation says agents respect licenses, permissions, field-level security and sharing, while custom actions inherit the context configured in their Flow, Apex or prompt template. That keeps an agent within its runtime identity. SalesBleed exposed a different dimension: within that identity, a broad tool can reach more information than the immediate task requires. The injection granted no new privilege; it reused the privilege already available to the General CRM subagent.
Post-patch review should begin with an effective-capability matrix. For every subagent, list its tools, objects, fields, read or write operations, runtime identity and the channels where output appears. Then tie every capability to a justified task. If lead review requires only qualification fields, the negative case should request Account, Contact and commercial values and confirm denial. When one agent genuinely needs broad contexts, separate subagents and actions so that reading public input does not automatically share the same surface with sensitive data or outbound messaging.
Prompt-injection detection adds a signal, not certainty. Salesforce documents that the feature, still in beta, recognizes direct and indirect attempts, records scores in the audit trail and stores those signals in Data 360; it also explicitly states that no model can guarantee 100% accuracy. The feature is enabled at org level and depends on documented editions and add-ons. Turn it on when eligible, monitor its reports and test both false negatives and false positives, while keeping least privilege and controlled outputs as deterministic limits for cases the classifier misses.
In Slack, confirmation and authorship are part of authorization
The third point concerns operational effect. Zenity compared Slack write actions and found different protections: Send a Slack Direct Message requested confirmation and showed who invoked it, while Reply to a Slack Thread required neither. That allowed an internal user to publish phishing behind the agent's appearance and, when combined with a poisoned lead, allowed external input to trigger a message after an employee processed the record. The thread's context and the familiar agent identity made the message more plausible without requiring compromise of a recipient account.
Salesforce changed the reported default: attribution was confirmed on August 20 and required confirmation on September 21. Zenity notes that an administrator can still disable confirmation through configuration. Acceptance therefore cannot end at 'patch applied.' For every action that sends a message or email, changes a record or starts an integration, execute a test task and capture whether approval paused execution, which details were shown before approval, how the invoker appeared to recipients and which event remained available for audit. A vague confirmation after content has already been sent does not perform the control's function.
The immediate plan is concrete: confirm current settings for write actions; review agents that combine external data, query tools and communications channels; search records created through public forms during the relevant window according to the organization's incident process; and add regression tests spanning web and Slack. The consulted sources do not support a claim that every org was compromised, nor that the known fix eliminates every future indirect injection. OrbTrail's conclusion is narrower and actionable: SalesBleed is fixed, but the durable control is proving that untrusted data never gains, by itself, the combined power to instruct, query and publish.
