ShareLeak and PipeLeak: When a Form Field Becomes Your Agent's Root Prompt
Two recent disclosures show the same pattern in different enterprise platforms: a public form becomes upstream of a privileged agent. The agent cannot reliably separate instructions from data, so a single free text field turns into a control plane for tool use and data egress.
The pattern: “input” is now an instruction channel
We have spent years treating web forms as low risk:
- limited payload size
- validation
- spam filtering
- maybe some XSS prevention
Agentic systems change that. A form field is no longer only stored and displayed. It is ingested into a prompt, then used to produce actions.
Once you accept that, the rest becomes obvious: forms are now part of your agent’s prompt surface.
What the disclosures actually said
In April, Capsule Security published two related findings:
- ShareLeak in Microsoft Copilot Studio (patched, assigned CVE-2026-21520).
- PipeLeak in Salesforce Agentforce (reported as a critical prompt injection scenario).
In both, the attacker never needs to “hack” the platform. They just submit text to a form that the agent later processes.
Form field to SharePoint list exfiltration
A malicious payload is inserted into a SharePoint form field (for example, comments). When a Copilot Studio agent processes the submission, the injected content overrides intent and leads to exfiltration of list data to an external destination.
- CVE-2026-21520 assigned
- Microsoft patch deployed (per disclosure timeline)
- Key failure: instruction and data mixed in a single prompt stream
A “lead” becomes an extraction pipeline
A public facing lead form accepts free text. An internal user later asks the agent to review the lead. The agent executes attacker-controlled instructions and uses email tooling to send CRM data externally.
- Zero authentication for the attacker (public lead forms)
- Bulk access demonstrated beyond a single record
- Key failure: unsafe defaults for outbound communication tooling
This is not a SQL injection story. It is a control flow story. The attacker supplies natural language that the agent later treats as high priority instruction. Once the agent has read access to sensitive data and an egress tool, exfiltration becomes a normal looking workflow.
Why patching prompt injection does not close the incident class
In ShareLeak, the unusual part is not the injection itself. It is the existence of a CVE and a patch cycle for an agentic prompt surface.
That is progress, but it also risks a false sense of closure.
A patch can stop one concrete chain. It cannot remove the underlying condition:
- untrusted external input enters the agent context
- the agent has standing access to internal data
- the agent has a first class egress channel
That is the general incident class.
The security model you actually need: instruction isolation plus egress governance
If your goal is to deploy autonomous agents without turning your lead forms into an extraction API, you need controls that do not depend on the agent behaving.
The simplest useful model looks like this:
- Instruction isolation
- treat external content as inert data
- prevent role, system, and tool directives from being created via concatenation
- keep a strict boundary between prompt instructions and retrieved content
- Action level gates
- enforce least privilege for data reads
- enforce policy checks on tool calls
- require confirmation for cross boundary egress
- Egress policy
- an agent should not be able to email arbitrary recipients by default
- an agent should not be able to export records in bulk without explicit approval
| Control | What it prevents | Where it lives |
|---|---|---|
| Instruction isolation | Untrusted text becoming directives | Prompt assembly boundary |
| Tool allowlists | Abuse of high risk actions in low risk flows | Agent tool router |
| Record level scoping | Bulk extraction from a single trigger | Data connector policy |
| Outbound email policy | Exfiltration through “normal” comms | Egress enforcement |
| Behavioral monitoring | Silent drift and tool chaining anomalies | Runtime observability |
OWASP mapping: why this is not one risk
This pattern hits multiple categories in the OWASP Top 10 for Agentic Applications (2026):
- ASI01 (Agent Goal Hijack): external text changes agent intent.
- ASI02 (Tool Misuse): legitimate tools are used for illegitimate purpose.
- ASI07 (Data Exfiltration and Leakage): egress channels used as the leak path.
The important point is the chain. Teams often treat these as separate workstreams. Real incidents do not.
If your agent can read internal records and send outbound email, you are already running an exfiltration pipeline. The only question is who controls the prompt that drives it.
A practical checklist for this quarter
- Inventory every place untrusted text can enter an agent (forms, tickets, emails, chats, docs).
- Disable or restrict outbound tooling by default (email, export, share).
- Add record and field scoping, not just object level permission.
- Alert on bulk reads and novel recipients.
- Require explicit user confirmation when an agent action crosses from low trust input to high privilege tool.
References
- Capsule Security: ShareLeak (Copilot Studio), CVE-2026-21520
- Capsule Security: PipeLeak (Agentforce)
- CSO Online coverage of both disclosures