SalesBleed: A Public Lead Form Became a Zero-Click Wire Out of Salesforce

2026-09-25 Agent & Supply Chain Security by al-ice.ai Editorial

The most dangerous prompt injection is the one nobody is present for. Zenity Labs disclosed September 24, 2026 three vulnerabilities in Salesforce Agentforce, collectively dubbed SalesBleed, in which an attacker who never logs in, never touches the target tenant, and never interacts with a victim can still walk CRM records out the door. The entry point is the public Web-to-Lead form — a public endpoint designed to accept untrusted input from strangers. The exfiltration channel is the agent itself, doing exactly what it was built to do: read records, follow instructions found inside them, and render helpful output. All three chains are now patched, but the shape of the failure generalizes far beyond one vendor.

Zenity reported the findings to Salesforce on June 1; Salesforce confirmed it was working on fixes a day later. The Trusted URLs bypass fix was confirmed August 19, and Zenity finished testing the remaining fixes on September 21, ahead of disclosure with a video proof-of-concept. The timeline is worth noting for what it implies: the exposure window for customers ran the better part of a quarter, and nothing in the attack required anything the victim organization did wrong during it.

A poisoned lead waits for a routine question

The first two flaws convert lead intake into a data-exfiltration channel. The attacker submits a Web-to-Lead form carrying indirect prompt instructions, which sit dormant inside Salesforce until an employee asks an Agentforce agent an ordinary question — the researchers' example is check my latest leads and help me with the newest one. Processing the poisoned lead activates the hidden instructions: the agent queries the Accounts table through its Query Records subagent tool, takes a couple of fields such as company name and deal size, and pastes them into a subdomain string under an attacker-controlled hostname. It then prints that URL back to the user as an HTML image tag. The frontend fetches the image with no further sanitization and no user interaction — and the fetch, routed through the attacker's authoritative DNS and web infrastructure, carries the record data with it.

This is the classic three-ingredient agent compromise the researchers call out explicitly: attacker-controlled content, tool access to sensitive internal data, and a rendered output path that reaches the network. Any one ingredient is benign. Salesforce had all three in the same room, and the guardrail meant to separate them — Trusted URL controls that restrict and redact external destinations for Agentforce and Einstein agents — failed in two specific ways. Zenity found the redaction did not register hostnames ending in an unrecognized top-level domain, and that certain characters interfered with URL parsing, so exfiltration strings sailed through a control whose entire job was stopping them. URL allowlists that parse differently from the renderer are not a control; they are a second parser waiting to disagree with the first.

Slack unfurling: the same wire, zero clicks again

The second chain reuses the same planted injection but changes the output path to Slack's URL-unfurling mechanism. Slack automatically fetches linked URLs to generate previews, so when an employee interacts with the Salesforce agent over Slack and the agent surfaces a crafted link, Slack itself initiates the request carrying CRM data to attacker infrastructure — again with no click and no visible anomaly. The exfiltration primitive here belongs to the collaboration layer, not the agent, which is the uncomfortable part: the agent only had to emit a link, and a helpful feature in a different product did the rest. Defenders who scope prompt-injection review to the agent boundary will keep missing chains whose final hop lives in unfurlers, preview renderers, and notification pipelines.

The agent's identity became the phish

The third flaw, detailed in a separate Zenity writeup, targets trust rather than data. The Agentforce Reply to a Slack Thread action required no user confirmation before sending and carried no visible attribution to the invoking user. A malicious insider already chatting with the agent could therefore send phishing messages under the agent's trusted identity while staying anonymous — and an external attacker could reach the same outcome through the Web-to-Lead injection, having the agent post the phish once an employee processed the poisoned lead. Agent-impersonation phishing inherits every permission the organization granted the agent's voice: internal distribution, executive-adjacent credibility, and none of the friction that normally attaches to sending as someone else.

Zenity co-founder and CTO Michael Bargury framed the lesson as containment, not correctness: secure-by-design matters, but agents encounter edge cases in the real world that design-time review misses, and the OpenAI–Hugging Face sandbox escape is the same trend in a different costume. Monitoring what agents actually do in production is the backstop, because a single overlooked gap redefines the blast radius after deployment.

What defenders should do now

Confirm Salesforce's SalesBleed fixes are active on your tenant and review lead-triggered agent activity for June through September. Hunt for agent queries against Accounts or other sensitive objects that originated from lead-processing sessions, and for rendered output containing image tags or links to unfamiliar hosts.
Treat every unauthenticated intake surface as an instruction channel. Web-to-Lead, support portals, file uploads, and calendar invites are prompt-injection entry points wherever an agent later reads them. Inventory which agents read externally submitted records and what tools those agents hold.
Require confirmation and attribution on every agent action that speaks as you. Messaging, email, and ticket-update actions need explicit user approval plus visible invoking-user attribution — the exact two controls the Slack reply action lacked.
Test your URL redaction against the renderer, not the spec. Feed the agent exfiltration-shaped strings with unusual TLDs, parsing edge characters, and redirector chains, then observe what the frontend actually fetches. A redaction control that disagrees with the renderer is decorative.
Scope review to the full output path, including unfurlers and previews. Slack link previews, email clients, and notification renderers are exfiltration hops. Disable or constrain automatic fetching of agent-emitted links where the data classification demands it.
Apply the three-ingredient test to every agent workflow. Wherever external content, sensitive tool access, and network-reaching output meet, assume the combination is exploitable and either separate them or instrument the junction with runtime monitoring.

The pattern rhymes with this spring's ShareLeak and PipeLeak disclosures in Copilot Studio and Agentforce — same vendor, same flaw family, five months later and one privilege level more creative. It also belongs beside this week's AgentCore harness findings, where default configuration turned prompt injection into credential theft. The industry keeps relearning the same lesson per product: agents collapse the distance between reading untrusted data and acting on it, and every control that assumes those are separate operations needs re-examination.

Sources: