An LLM agent that pentests Salesforce Experience Cloud end-to-end

What is this?

On June 8, 2026, the security research team at Reco published a write-up describing an autonomous LLM agent that runs an end-to-end security assessment of Salesforce Experience Cloud sites. You give it a URL; it enumerates the attack surface, classifies what looks sensitive, fuzzes server-side methods, writes a working exploit, runs it, and then reviews its own findings for severity — with no human guidance after the target is set.

The technique against the platform is not new. Since September 2025, the threat group ShinyHunters has been mining the same surface — misconfigured Experience Cloud guest-user profiles — by repurposing AuraInspector, a command-line audit tool Mandiant released on January 12, 2026 to help defenders find access-control gaps. The campaign became public in early March 2026 and is credited with hitting 300–400 organizations. What the Reco demonstration adds is the step after reconnaissance: letting a model, not a human, drive the analysis and exploitation.

How it works

Experience Cloud exposes the Salesforce Aura framework to unauthenticated guests. Through it, an external visitor can enumerate Salesforce objects (database tables), Apex controller methods (server-side logic), public routes and files. The two weaknesses being exploited are old and ordinary: broken object- and record-level access control (Apex classes declared without sharing, overly permissive guest profiles, ContentDocument files set to AllUsers visibility) and SOQL injection from string-concatenated queries.

Reco’s agent is not a monolithic script but an agentic pipeline of skills, each handling one phase a human pentester would run:

Phase            What the agent does
---------------  ------------------------------------------------------
1. Recon         Enumerate objects, Apex methods, routes, files via Aura
2. Object review Rank tables by sensitivity (Contact, Lead > BlogPost)
3. Apex fuzzing  Infer valid inputs from signatures; probe for SOQL injection
4. Exploitation  Write a standalone PoC, run it, validate extracted data
5. Severity      Self-review findings as a skeptical reviewer would

The leverage is in phases 3–5. The model reasons about what a method named getContactInfo(email) expects, reuses records it already dumped to build valid inputs, and recognises an injection oracle from a behavioural change in the response. In one anonymised case it found a guest-accessible Apex method that returned a full contact record — name, phone, title, billing address — for any email address, then autonomously pivoted to LinkedIn to harvest employee names, guessed corporate email patterns (first.last@company.com), and validated them against the endpoint to compile a PII list. The exploit primitives themselves (boolean-blind SOQL extraction, character-by-character LIKE matching) are long-published and are not reproduced here.

Why it matters

The shift, as with LLM-driven post-exploitation, is one of cost, not capability. None of these flaws is novel; what was expensive was the human time to assess each portal, read every method signature, and craft a bespoke exploit. An agent collapses that cost to inference budget — so the long tail of “low-exploitability” misconfigurations that defenders deprioritised becomes economically worth attacking at scale. ShinyHunters already demonstrated the recon half against 300–400 organizations with a repurposed audit tool; bolting a model onto the exploitation half is the obvious next move.

The second property is thoroughness. The agent does not miss a single injectable parameter among dozens, or one confidential file buried among hundreds, because it inspects everything systematically. “Security through obscurity” — assuming an exposed method or file is safe because it is hard to find — no longer holds when the finder is tireless and cheap.

Defenses

1. Use bind variables in SOQL, never string concatenation. WHERE Id = :blogId instead of WHERE Id = '' + blogId + ''. A one-character fix closes the entire injection class; the Reco cases all traced back to dynamic queries built by concatenation.
2. Audit without sharing Apex classes. Developers reach for without sharing because “everything just works”; it bypasses record-level security. Default to with sharing and justify every exception, especially on any class reachable by guest users.
3. Lock down guest-user permissions. Treat the guest profile as fully hostile. Review object and field permissions, Apex method access, and remember that “guest users can’t see the site” controls page access, not record or file access.
4. Fix ContentDocument visibility. Set ContentDocumentLink.Visibility away from AllUsers and disable “let guest users view asset files” unless genuinely required. The agent reliably found the one confidential document among hundreds of benign ones.
5. Put Experience Cloud sites in scope. Many programs audit the main app but not the connected portal. Run Salesforce’s own Guest User Access Report and Mandiant’s AuraInspector against your own sites before an attacker’s agent does.
6. Assume probing is automated and exhaustive. Risk-acceptance decisions that rated a flaw “low exploitability” by hand are out of date; re-rate them against an adversary that tests everything.

Status

Item	Reference	Date	Notes
ShinyHunters Aura campaign public	Salesforce / Help Net Security	2026-03	Misconfigured guest profiles; scanning since Sept 2025
AuraInspector released	Mandiant	2026-01-12	Defensive audit tool, then repurposed by attackers
Reported scale	Salesforce Ben	2026-03	ShinyHunters claims 300–400 organizations
Autonomous exploitation agent	Reco	2026-06-08	End-to-end agentic pentest, responsibly disclosed findings

The flaws here are configuration and code, not a platform zero-day, and Reco’s findings were responsibly disclosed with organizations anonymised. The point is not a new vulnerability — it is that the economics of exploiting old ones just changed.