What happened
Researchers at Zenity Labs found three vulnerabilities in Salesforce Agentforce that could have allowed attackers to hijack trusted agents to exfiltrate sensitive CRM data and to distribute phishing. The flaws were named SalesBleed.
The entry point was Web-to-Lead, Salesforce's official lead collection mechanism, which also provides a direct path into the CRM. Malicious instructions injected into a Web-to-Lead submission stayed dormant until an employee asked an Agentforce agent to interact with it, at which point the agent processed the poisoned lead and executed the hidden instructions.
Two of the flaws could be used in zero-click data exfiltration, and the third let attackers weaponise an agent to send phishing. The first two stemmed from weaknesses in Trusted URLs, the mechanism meant to stop Agentforce displaying URLs and images from untrusted sources. Zenity found that it did not recognise top level domains and that character sequences could tamper with URL parsing. A payload could reach leads and accounts table data and then use HTML image tags to send CRM data to an attacker server. Notably, Agentforce reported the content as blocked by organisational security policy even though the data had already been transmitted.
The third flaw affected the Agentforce integration with Slack. Specially constructed links could cause Slack to initiate requests carrying CRM data to attacker infrastructure as soon as the links appeared in a channel. Because the agent did not identify who was sending a message, an attacker could hijack it and post phishing into internal Slack channels using the agent's own identity. Employees would see a message from a trusted internal system rather than an unknown outside sender, and a compromised identity could open up email, code repositories and other connected systems. Zenity reported the issues on 1 June and Salesforce confirmed all three had been addressed by 19 August.
Why this is a GRC story
Agent identity needs the scrutiny of a privileged account. The agent could read CRM records and post internal messages under its own name. A non-human identity with that reach is an access control subject, and it needs an owner, a scope and a review cycle.
One control carried the whole weight. Trusted URLs was the boundary between a language model and the CRM, and it failed on basic URL parsing. When a single mechanism is the only thing in the way, its test coverage becomes a statement about risk appetite.
The policy fired after the data left. Blocking was reported once exfiltration had already happened. Controls that log after the fact satisfy an audit but not a risk appetite, and this failure is easy to miss because the control appears to be working.
Untrusted input with a known address. Web-to-Lead is an open form that anyone can write to. Anything that reads it ingests untrusted content by design, which makes prompt injection an input validation problem with a clearly mapped surface area. Third-party risk also carries dates here, and those belong in the register.
What to watch
Watch for a vendor advisory and for whether other agent integrations share the same Trusted URLs weakness. Watch whether agents gain controls that distinguish a human sender from another agent. And watch how buyers write assurance requirements for agentic features, because this class of failure will not appear in a standard vulnerability scan.
Attribution: Analysis based on SecurityWeek's reporting and Zenity Labs' technical write up of the SalesBleed flaws. This article is original commentary, not a repost of the source material.