Full Report
In Salesforce Agentforce, the recommended way to make an agent respond to events is a Flow: a record is created or a case is updated, and the Flow passes data into the agent's prompt. Separately, Email-to-Case and Web-to-Case turn inbound customer messages into case records; it is how airlines and hotels run support intake. Both are standard, documented, as-designed features. Chained together,
Analysis Summary
# Vulnerability: Prompt Injection Path from Email-to-Case/Web-to-Case into Salesforce Agentforce Agents
**Note:** The source article does not describe a single CVE-tracked software flaw. It describes a chain of standard, documented features that, combined, let an unauthenticated outsider reach an agent's prompt. The article states that "nothing was misconfigured." Fields without source data are marked accordingly.
## CVE Details
- CVE ID: Not assigned or not referenced in the article
- CVSS Score: Not provided
- CWE: Not provided. The closest conceptual match is untrusted input reaching an LLM prompt (prompt injection), but no CWE is cited.
## Affected Systems
- Products: Salesforce Agentforce, Salesforce Flow, Email-to-Case, Web-to-Case
- Versions: Not specified. The article does not name affected releases.
- Configurations (per the article's description):
- A Flow is triggered by record creation or case update and passes case data into an agent's prompt.
- Email-to-Case or Web-to-Case is enabled, so inbound messages from the public internet create case records.
- The agent can take actions and post case comments, and those comments can produce outbound replies to the customer.
- Guest or unauthenticated users can reach the relevant intake path and objects, as the article's "exposed to guest users" variable implies.
## Vulnerability Description
Inbound customer email or web form submissions create case records. A Flow fires on case creation or update and inserts the case content into the agent's prompt. Because the agent treats that content as instructions or context, an external sender can attempt to influence the agent's behavior. The agent can then act (for example, write a case comment), and that output is sent out through the outbound reply path.
The article's framing is that the risk lies in the application's configuration and automation (which intake features are on, which triggers fire, which data crosses into prompts) rather than in the underlying model. Prompt filters on agent inputs may not identify that content originated from an external stranger.
## Exploitation
- Status: No evidence of exploitation in the wild is reported in the article. No public PoC is referenced. The article says the finding was "documented by researchers in August 2026" but cites no advisory or report.
- Complexity: Low (analyst assessment). Sending an email or web form submission requires no credentials. Crafting content that the agent acts on is a separate question the article does not quantify.
- Attack Vector: Network (the entry point is public internet email or web intake)
## Impact
Impacts are inferred from the article's description, not from a formal assessment.
- Confidentiality: Potentially High. The article mentions "a route into an internal agent's instructions" and possible data exposure, depending on what the agent can read.
- Integrity: Potentially High. An attacker may influence agent actions and the content of outbound replies.
- Availability: Low to Moderate. The article describes a possible "support-queue nuisance" at minimum, such as case spam or noise.
## Remediation
### Patches
- None identified in the article. No vendor advisory or fixed version is cited. Check Salesforce release notes and Trust site guidance directly.
### Workarounds (analyst recommendations, not from the article)
- Inventory every Flow that fires on case creation or update and identify which fields feed agent prompts. Remove or sanitize inbound free-text fields (such as Description and Subject) before they reach a prompt.
- Restrict guest user access to case objects and fields the agent reads.
- Where possible, disable Email-to-Case or Web-to-Case for agent-handled queues, or route them to a queue without agent automation until reviewed.
- Limit the agent's action scope. Use least-privilege permissions for the agent's running user and avoid actions that reach sensitive data or send external messages without review.
- Require human approval before agent-generated comments or replies leave the org.
- Treat inbound case content as untrusted in prompt design, with explicit delimiters and instructions that the agent must not follow directives in customer text.
## Detection
- Case records created via Email-to-Case or Web-to-Case containing instruction-like language (for example, requests to ignore prior instructions, reveal configuration, or act on other records)
- Agent-generated case comments or outbound replies containing data the customer should not have, or content unrelated to the case
- Unexpected agent actions following inbound case creation, especially those touching other records
- Guest user activity against case or agent-related objects, reviewed through Salesforce event and field audit logs (where licensed)
- Flow run history showing automation triggered on Email-to-Case-created records
## References
- Source article: The Hacker News, "From Email-to-Case to the Boardroom: How Inherited Agents Break Governance Built for Software," Oct 19, 2026 (thehackernews[.]com/2026/10/from-email-to-case-to-boardroom-how.html)
- OWASP Agentic Skills Top 10 whitepaper, cited in the article (owasp[.]github[.]io, ast10-top10-whitepaper-2). Not verified here.
- Vendor sources: Salesforce Agentforce and Email-to-Case documentation. No specific advisory is cited in the article.
**Analyst caveat:** The article reads partly as vendor content promoting agent governance tooling and does not provide reproducible technical detail. Verify the attack chain against Salesforce documentation and a controlled test before acting on the impact assessment.