ForcedLeak and PipeLeak are two separate, publicly disclosed prompt-injection vulnerabilities in Salesforce Agentforce, found roughly seven months apart, that both used the same entry point: a public-facing lead form an anonymous visitor can fill in. Noma Labs disclosed ForcedLeak in September 2025; Capsule Security disclosed PipeLeak in April 2026. Salesforce responded to both, but the two disclosures ended up with different resolutions — an enforced platform-wide control for ForcedLeak, and a narrower, contested fix for PipeLeak — which is itself instructive about what "patched" means for an agent that reasons over untrusted input.

ForcedLeak: form field, expired domain, silent exfiltration

Noma Labs' research, published in September 2025, described ForcedLeak as a vulnerability chain rather than a single bug. Salesforce's Web-to-Lead feature accepts a "Description" field of up to 42,000 characters from anyone submitting a lead — a common integration for conferences, trade shows, and marketing campaigns. An attacker could encode a multi-step instruction payload inside that field, formatted to resemble ordinary business content.

When an internal employee later asked Agentforce to summarize or process that lead, the agent ingested the full description as part of its working context and executed the embedded instructions alongside the legitimate request, because the platform did not enforce a boundary between submitted form data and agent-directed instructions. The final step of the chain relied on a separate weakness: Salesforce's Content Security Policy allow-list included an expired domain. An attacker could register that domain and use it as a destination the agent's own policy already treated as trusted, so exfiltrated CRM data — customer emails, lead metadata — left through a channel that looked legitimate to the platform's own controls. Noma Labs rated the chain critical severity, citing a CVSS score of 9.4 for the combined vulnerability.

Salesforce's fix was architectural rather than a single patch to the form: the company enforced Trusted URLs across Agentforce and Einstein AI, so agent output can no longer be directed to domains outside an explicit, actively maintained allow-list. That closes the specific exfiltration channel ForcedLeak used, though it does not, by itself, stop an agent from reading and acting on injected instructions in the first place — it removes the destination the attacker needed, not the injection itself.

PipeLeak: the same door, a different resolution

Capsule Security's April 2026 disclosure, covered alongside a related Microsoft Copilot Studio finding called ShareLeak, used the same class of entry point — a public-facing Salesforce lead form — but a different downstream action. Researchers demonstrated that a hijacked Agentforce agent could be made to call its own GetLeadsInformation function and email the results externally, and that the technique was not limited to a single record: a crafted submission could turn into a bulk export of multiple lead records at once.

Salesforce's public response to PipeLeak, as reported by CSO Online on 15 April 2026, differed from its response to ForcedLeak. According to a Salesforce spokesperson quoted in that coverage, the company "remediated the specific scenario described" but characterized the exfiltration path as "configuration-specific," pointing to optional human-in-the-loop review as an available mitigation rather than treating it as a platform-wide default that needed to change. Capsule Security's researchers pushed back publicly on that framing, arguing that requiring manual approval for every agent action undermines the point of running an autonomous agent at all. As of that reporting, PipeLeak had not been assigned its own CVE identifier — teams tracking this incident should check Salesforce's current trust and security advisories directly rather than relying on a point-in-time summary, since disclosure status is exactly the kind of fact that moves.

The companion Microsoft-side finding, ShareLeak, affected Copilot Studio agents processing SharePoint form submissions in a structurally similar way — user input concatenated directly with system instructions, with no separation the model could rely on. Microsoft assigned CVE-2026-21520 to that issue — the National Vulnerability Database entry describes it as exposure of sensitive information to an unauthorized, unauthenticated network attacker in Copilot Studio, with a CVSS 3.1 base score of 7.5 — and patched it centrally so no customer-side action was required.

The shared root cause

Both Agentforce incidents, and the Copilot Studio one alongside them, trace to the same underlying failure: a system that concatenates untrusted external input with trusted system instructions, with nothing in between to tell the model which is which. The form field is not the vulnerability — it is simply the easiest place to plant the payload, because it is designed to accept free text from anyone. The vulnerability is that the agent's context has no structural boundary marking "data I should reason about" apart from "instructions I should follow." This is the general shape of indirect prompt injection, covered in more depth in threat model: indirect prompt injection and prompt injection threats and defenses.

It is worth being precise about what "patched" means in each case. Enforcing Trusted URLs, as Salesforce did for ForcedLeak, closes a specific exfiltration channel without changing whether the agent will execute injected instructions in the first place — it is a mitigation at the output boundary, not at the point where untrusted data enters the model's context. The distinction matters for anyone evaluating a vendor's disclosure: a patch that removes one attacker-controlled destination is not the same as a fix that prevents the agent from treating injected instructions as legitimate.

What this means if you run agents with public-facing input surfaces

Any AI agent that reads content submitted through a public form, an inbound email, an open ticket queue, or an unauthenticated API endpoint has the same structural exposure these two incidents demonstrate, regardless of vendor. The AI agent security guide covers this class of risk as part of a full program rather than a single control. A useful checklist for evaluating your own exposure:

  • Identify every input surface an agent reads that an anonymous or low-trust party can populate. Web-to-lead forms, support ticket bodies, and inbound email are the common ones; the specific product does not matter, the pattern does.
  • Check what the agent is authorized to do with that data, not just what it is designed to do. An agent that can query bulk records and send email is a wider blast radius than one that can only draft a summary a human reviews. Excessive agency (OWASP LLM06) and its controls covers how to scope this down.
  • Review your own outbound allow-lists for stale entries. ForcedLeak specifically exploited an expired domain still on a trust list — a lesson that trust lists need active maintenance, not one-time configuration, independent of any AI system.
  • Decide deliberately where human-in-the-loop review is mandatory rather than optional, particularly for any workflow that can move data outside your environment. See human-in-the-loop approvals for agents.
  • Log and monitor agent-initiated outbound actions — emails sent, records queried in bulk, external requests made — so an anomalous pattern is visible before it is reported by a researcher or a customer. How to detect prompt injection covers the detection side of this.

Why disclosed-and-patched is the healthy outcome

Both vulnerabilities followed the pattern security research is supposed to follow: independent researchers found the issue, disclosed it responsibly to the vendor, the vendor investigated and shipped a mitigation, and the details became public so the rest of the industry could learn from the specific mechanism — the same healthy disclosure pattern documented in the MCP STDIO RCE vulnerability wave. That is the system working as intended, not a sign that Salesforce or Microsoft was negligent — every agent platform that lets untrusted input reach a reasoning model over a broad enough surface area will surface findings like these, and the vendors with active bug-bounty and disclosure programs are the ones that get found and fixed first. The lesson for buyers is less about any specific vendor and more about the pattern: ask how a platform separates untrusted input from trusted instructions, and ask what "patched" means for each specific disclosure before assuming an incident like this cannot recur in a different form.

Common questions

Is Agentforce uniquely vulnerable to this kind of attack? No. ForcedLeak and PipeLeak are Agentforce-specific instances of a general pattern — indirect prompt injection through an input surface that accepts untrusted content — that has also been documented in Microsoft Copilot Studio (ShareLeak) and other agent platforms. Any system that lets an LLM-driven agent read attacker-controlled text as part of its working context is exposed to the same class of issue unless it has explicit controls in place.

Does enforcing Trusted URLs fully fix the underlying problem? It closes the specific exfiltration channel ForcedLeak used — the agent can no longer send output to an untrusted or expired domain — but it does not prevent the agent from ingesting and acting on injected instructions in the first place. A determined attacker who found a different, allow-listed exfiltration path (an internal email, a webhook already on the trust list) would not be stopped by this control alone.

Why did Salesforce treat PipeLeak differently from ForcedLeak? Based on Salesforce's public statement reported by CSO Online, the company characterized PipeLeak's exfiltration path as tied to a specific configuration rather than a default that needed a platform-wide change, and pointed to optional human-in-the-loop controls as an available mitigation. Capsule Security disputed that framing publicly. Readers should treat this as a live disagreement between researcher and vendor rather than a settled resolution, and check Salesforce's current advisories for the latest status.

What should a security team do right now if they use Agentforce with Web-to-Lead enabled? Confirm Trusted URLs enforcement is active, audit historical lead data for submissions containing unusual multi-step instructions or embedded links, and review whether your Agentforce configuration requires human review before an agent can send data externally or query records in bulk. Rotating any credentials the agent had access to is a reasonable precaution if you find evidence of exploitation.

How does this connect to the broader incident response process? Once you have evidence an agent executed injected instructions, the response follows the same phases as any breach: contain, scope the blast radius, find the root cause, and remediate. Incident response for AI agent breaches covers that process in detail, including why prompt injection specifically requires reviewing agent input and output content rather than just infrastructure logs.