Security researchers have disclosed a series of vulnerabilities in Salesforce Agentforce that could have allowed attackers to exfiltrate sensitive customer relationship management (CRM) data without logging into a victim’s Salesforce environment or requiring them to click anything.
The attack chain, dubbed “SalesBleed” by researchers at Zenity Labs, used hidden prompt injection instructions planted inside Salesforce Web-to-Lead forms to manipulate AI agents when they later processed the submitted records.
Zenity disclosed the findings on 24 September after reporting the vulnerabilities to Salesforce in June. Salesforce subsequently remediated the issues, with the security firm confirming the fix for the reported Trusted URLs bypass on 19 August.
Web-to-Lead is designed to allow external users to submit information that is then added directly to an organisation’s CRM. According to Zenity, an attacker could place a concealed malicious prompt inside one of these submissions without needing a Salesforce account or any access to the target organisation.
The payload could then remain dormant until an employee carried out an ordinary task using Agentforce, such as asking an agent to review the organisation’s latest leads.
When the agent read the malicious record, it could interpret the embedded content as instructions and use its existing access to Salesforce data and tools to retrieve information beyond the lead itself.
In Zenity’s proof of concept, the researchers instructed the agent to query account information including company names and deal sizes before placing the data inside a URL controlled by the attacker. An HTML image tag could then cause the interface to attempt to retrieve that external resource automatically.
Because the sensitive information was contained within the hostname, the resulting DNS request was enough to transmit the data to infrastructure controlled by the attacker. No link needed to be opened and the subsequent HTTP request did not need to complete successfully.
The technique also bypassed Salesforce’s Trusted URLs mechanism, which is designed to prevent agents from returning unapproved external URLs.
Zenity found discrepancies between the way the redaction mechanism identified URLs and the way they were subsequently interpreted by a browser. Among the weaknesses identified were differences in the handling of certain top-level domains and characters placed at the end of URLs, allowing specially constructed addresses to escape redaction while still being processed by the browser.
Importantly, the attack did not depend on an attacker escalating the agent’s privileges. Zenity said the General CRM subagent it tested already held read access to both Leads and Accounts as part of its default configuration.
This meant the malicious prompt could instruct the same agent that had legitimately been asked to inspect a lead to query other CRM records accessible through its existing permissions.
The malicious entry could also remain inside the Leads table and potentially be triggered again whenever an employee processed it, giving an attacker a persistent route into the agent’s workflow without maintaining a login or active session.
Zenity said the attack demonstrated how the combination of externally supplied data, sensitive internal permissions and an automated route for rendering external content can turn an indirect prompt injection into a data-exfiltration path.
“Our payload asked for company names and deal sizes, but the injection could have asked for anything the subagent’s Query Records tool can reach (which can include sensitive data). In a typical General CRM deployment, that includes accounts, contacts, and more,” the Zenity report noted.
The researchers reported the issues to Salesforce on 1 June, with Salesforce confirming the reports the following day. The companies discussed the vulnerabilities and potential mitigations later that month, before Salesforce confirmed fixes on 18 August. Zenity confirmed the specific Trusted URLs bypass had been addressed on 19 August.
Zenity said the complete data-exfiltration attack chain described in its research no longer works following the fixes.
SalesBleed research also uncovered a separate route through Agentforce’s integration with Slack, where a compromised agent could be abused to send phishing messages using the agent’s own identity.
Recommended reading
- ‘Reasoning’ AI Emits Up to 50x More Carbon Than Simpler Models
- Is ChatGPT Making You Dumb? Possibly, MIT Says
- New Apple Paper Pours Cold Water on AI Reasoning
- Is AI Making Us Dumber? Workers Think So.
According to Zenity, the default Slack Knowledge subagent included a Reply to a Slack Thread action which could previously send messages without user confirmation and without making clear to recipients which user had initiated them.
Combined with the URL-redaction bypass, this could have allowed an attacker to plant instructions through Web-to-Lead and subsequently cause Agentforce to distribute phishing links into an organisation’s Slack environment.
Salesforce added attribution identifying the invoking user and changed the default behaviour to require user confirmation before the Slack reply action could execute. Zenity said all fixes relating to that attack path had been confirmed and tested by 21 September.
The vulnerabilities have since been fixed, but Zenity argued that the broader security issue extends beyond Salesforce.
An AI agent that can process information supplied by untrusted external sources, access sensitive internal systems and cause links or other external resources to be rendered has the same basic combination of capabilities that enabled SalesBleed.
The findings highlight a wider challenge as organisations give AI agents greater access to enterprise applications and permission to take actions on behalf of users. In these environments, malicious instructions do not necessarily need to be sent directly to the AI system by an attacker. They can instead be placed inside the emails, records, documents and other data that an agent is subsequently asked to process.





