I’ll write from the story briefs: SalesBleed is the unused angle, Roundcube is the supporting pattern, and Cloudflare plus MacSync stay off the page because you already covered them. TITLE: Three Agentforce Bugs Enabled Zero-Click CRM Exfiltration

Three flaws in Salesforce Agentforce, published as SalesBleed, let an attacker hijack a trusted agent, pull tenant records, and queue phishing from inside the CRM. No user click. No implant on the laptop. The agent already held object permissions your sales org granted it, which is why this is a cybersecurity incident at the application layer before it is a malware event.

Researchers showed a blunt pattern. Agentforce treats some incoming content as instructions. Feed it the right prompt through a channel the agent is allowed to read, and it executes under its own identity. Zero-click here means the victim never opens a lure. Data leaves because the assistant was built to be helpful, and helpfulness is a privilege.

That is a bad look for anyone selling autonomous helpers on production CRM. It is a worse look for teams who still draw the trust boundary at the firewall and label the rest “business software.”

SalesBleed Hijacked Agents That Already Held Tenant Tokens

SalesBleed is three bugs, not a single remote-code trophy. Together they let an attacker take over the agent’s decision path, query Salesforce objects the agent could already see, and then use that same trusted channel to send phishing that looks like it came from your org. The phishing is the second punch. The first loss is every record the agent was allowed to read.

Salesforce logo on a corporate backdrop used in coverage of the Agentforce SalesBleed flaws
Salesforce Agentforce agents run inside the tenant with connected-app privileges. SalesBleed abused that trust path.

Treat these agents as service principals with a chatty parser. They live in the tenant. They hold OAuth-backed access. They ingest unstructured text from emails, cases, web forms, and other objects your process already dumps into Salesforce. If your data classification calls “the Salesforce agent” an internal helper, you have handed a privileged interpreter to whatever text lands in its context window.

Threat detection that only watches workstation processes will miss this. The traffic is HTTPS to a vendor you pay. The identity is a legitimate connected app. Your SIEM may log it as Agentforce doing its job. That log line is the incident, if you bother to read it as one.

Classic brute-force against the login page never enters this kill chain. The agent session is already valid. Credential stuffing dashboards stay green while records walk out through an assistant your sales ops team enabled last quarter because a vendor demo said it would close tickets faster.

Agent Traffic Passed Cybersecurity Controls as Trusted Business Logic

Most cyber security programs still sort risk into inbound scanning, lockouts, and endpoint threat-protection. Agentforce did not need those controls to fail. The request is authenticated. The destination is allowlisted. Defense in depth that stops at the network edge treats the CRM as a safe zone, then acts surprised when a helper with query rights becomes the exfil tool.

You already know this failure mode from other SaaS APIs. A compromised OAuth app dumps objects. A forgotten connected app survives offboarding. SalesBleed just removes the need for a stolen human session. The agent is the session. Prompt injection against a tool-using assistant is privilege abuse with extra steps, and those steps happen on Salesforce’s side of the TLS connection.

The real problem here is inventory. Few teams can list every Agentforce skill, every connected app, every object the agent can SOQL, and every outbound action it may take. If you cannot name those four things for a tenant, you cannot scope an incident response when Noma-style research turns into a live campaign. You will get a vendor advisory, a Slack thread, and a guess.

Patching the three SalesBleed issues is necessary and insufficient. The class remains: any agent that reads untrusted text and holds production data rights is an interpreter sitting on your crown jewels. Salesforce is the example in this week’s writeups. Your next ticket will name a different copilot on a different SaaS pile with the same permission shape.

Immediate Containment for Agent-Connected Salesforce Tenants

Do the boring work in the tenant you actually run, not in a slide about AI governance. Security hardening for agent platforms is identity work plus content-trust work. Skip the philosophy seminar until the connected apps are inventoried.

  • Inventory every Agentforce agent, skill, connected app, and named credential. Disable anything without a named owner and a written data scope.
  • Cut object and field permissions to the minimum the workflow needs. If the agent can see Cases, Accounts, and Files, assume an injected prompt can too.
  • Block agents from acting on untrusted inbound channels (web-to-case, public email-to-case, guest forms) until those channels are isolated from tool-calling agents.
  • Turn on verbose connected-app and Event Monitoring logs for agent actions, SOQL-equivalent queries, and outbound send. Alert on spikes, new objects, and mail/API bursts outside business hours.
  • Rotate OAuth secrets and session tokens for agent identities after you apply the vendor fix, then hunt 30 days of prior agent activity for odd object reads.

Immediate actions are freeze, shrink, and review. Freeze nonessential agents. Shrink remaining agents off broad “View All” and “Modify All” styles of access. Review outbound email, Slack, and HTTP callouts the agent can fire; those are your exfil and phishing rails.

Ongoing work belongs on a calendar, not a wiki page nobody opens. Re-approve agent scopes quarterly the same way you re-approve OAuth apps. Add agent identities to your joiner-mover-leaver process so a departed admin cannot leave a helper running with their old permission set. Put prompt-injection test cases into change control: untrusted text in a case comment should never cause a query of unrelated objects or a send to an external address.

When you do land in IR, run it like a compromised service account. Revoke the agent’s tokens. Preserve Event Monitoring and setup audit trail. Enumerate objects touched. Notify legal if customer PII sat in those objects. The laptop of the sales rep is a sideshow unless you have evidence the same actor also phished endpoints. Start from the tenant. Expand only with logs.

Unauthenticated Roundcube SQLi Shows the Same App-Plane Failure

While Salesforce teams were digesting SalesBleed, SecurityWeek reported CVE-2026-48842 in Roundcube Webmail: SQL injection with no authentication, already in attackers’ crosshairs. Different stack. Same operational insult. The host your users treat as “just email” is a database with a web skin, and an unauthenticated query is a full read of the mailbox store if you left that box on the internet with a stale build.

Email security conceptual image tied to exploited Roundcube webmail SQL injection
CVE-2026-48842 is unauthenticated SQL injection in Roundcube. Internet-facing webmail is a data store, not a convenience portal.

You do not need a novel framework to connect these. Agentforce is a privileged parser in a SaaS tenant. Roundcube is a privileged parser in a mail database. One needed crafted content the agent would obey. The other needed a crafted request the login page never saw. Both sit inside the story your network diagrams call “internal apps,” which is why they age out of patch SLAs until a reporter uses the word exploited.

If Roundcube is still in your estate, patch now, confirm the version on every vhost, and dump web logs for unauthenticated POST patterns hitting the vulnerable parameter space. Assume mailbox contents and session tables were readable until you prove otherwise. Then decide whether you still want a self-hosted webmail surface on the public internet at all. Many teams keep it for habit. Habit is not a control.

SalesBleed will get a vendor patch and a blog cycle. CVE-2026-48842 will get a scramble on the mail servers you forgot were still routing exec inboxes. Your job is to treat tool-using agents and internet-facing collaboration apps as production identities with data rights, then budget incident response drills that start in the tenant or the mail DB rather than in the EDR console. The next advisory will change the product name. The permission shape will not.

Sources

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.

Stay up to date with the latest news, releases and more.

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.