On March 7, 2026, Salesforce issued a security advisory warning customers about an active campaign targeting misconfigured Experience Cloud sites. The threat actor group ShinyHunters has since claimed responsibility, stating they have compromised data from 300 to 400 organizations by exploiting overly permissive guest user configurations. Despite sensationalized headlines, this is not a vulnerability in Salesforce’s platform. It is a configuration management failure, and it is entirely preventable.
“Salesforce remains secure, and this issue is not due to any vulnerability inherent to our platform.” – Salesforce Security Advisory, March 7, 2026
At Digital Mass, we have been identifying and remediating exactly these types of guest user misconfigurations for our clients for years. This advisory validates what our team has consistently emphasized: the power and flexibility of Salesforce’s permission model is only as secure as the configuration behind it.
What Happened
ShinyHunters, a well-known cybercrime group with a track record of targeting Salesforce customers, launched what they call the “Salesforce Aura Campaign” starting in September 2025. The attack chain is straightforward:
1. Discovery: The attackers scanned the public internet for the /s/sfsites/aura endpoint, which identifies active Salesforce Experience Cloud sites.
2. Reconnaissance: They used a modified version of AuraInspector, an open-source tool originally built by Mandiant to help admins find misconfigurations, and repurposed it for mass scanning.
3. Exploitation: Where guest user profiles had been configured with excessive object and field-level permissions, the attackers queried CRM data directly through the Aura API without ever needing to authenticate.
4. Exfiltration: Data was extracted via Salesforce’s GraphQL API, with the attackers finding workarounds to platform-imposed query limits.
The critical detail: no credentials were stolen. No authentication was bypassed. No zero-day was exploited. The guest user profile simply had more access than anyone intended to give it.
Why This Keeps Happening
This is not the first time guest user misconfigurations have made headlines, and it will not be the last. There is a fundamental tension in Experience Cloud deployments:
- Salesforce is powerful because you can customize everything, including permissions.
- Salesforce is risky because you can misconfigure everything, including permissions.
Guest user profiles exist for a legitimate reason. They allow unauthenticated visitors to view public pages, submit forms, and interact with portal content without logging in. The problem arises when these profiles are provisioned with broad object access, API-enabled permissions, or visibility into records far beyond what the site’s functionality requires. In our experience, this happens for a few common reasons:
- Speed over security during implementation. Permissions are opened to get features working quickly and never locked back down.
- Lack of ongoing security reviews. Guest user configurations are set once and rarely revisited, even as the org evolves and new objects are added.
- Underestimating the Aura API surface. Many admins do not realize that Aura endpoints expose queryable access to any object the guest user profile can see, not just what is rendered on the page.
- Misunderstanding of the sharing model defaults. If org-wide defaults are not set to Private for external users, guest profiles may inherit broader access than intended through sharing rules or public groups.
What You Should Do Right Now
If your organization operates any Salesforce Experience Cloud site with guest user access enabled, we recommend taking the following steps immediately:
Audit your guest user profile. Navigate to Setup > All Sites > [Your Site] > Builder > Settings > General > Guest User Profile. For each listed object permission, ask: Does an unauthenticated visitor actually need access to this? Remove anything that is not explicitly required for the site to function. We also recommend reviewing your external user profiles.
Enforce least-privilege defaults. Set org-wide sharing defaults to Private for all external users. Enable the “Secure guest user record access” setting. Guest users should not be able to access any record unless a sharing rule explicitly grants it.
Disable API access on guest profiles. Remove the “API Enabled” permission from guest user profiles. Unless your site explicitly requires unauthenticated API calls, this permission should not be active.
Disable self-registration unless required. Guest data can be used to create portal accounts, which may enable broader authenticated access.
Review your Aura Event Monitoring logs. Look for anomalous query patterns, especially queries targeting objects not intended to be public, unexpected volume spikes, or unfamiliar IP addresses hitting your /s/sfsites/aura endpoint.
Check your public groups. Be aware that public group membership, including the users within those groups, may be visible through the same Aura endpoints. This is a known limitation that cannot currently be restricted at the guest user level.
The Bigger Picture
Every major Salesforce-related “breach” over the past year has followed the same pattern: headlines suggest a platform failure, but the details reveal a self-inflicted configuration gap. Phishing, third-party integration abuse, and now guest user misconfigurations have all been framed as Salesforce security issues when, in reality, they are governance issues.
This pattern points to a growing need in the Salesforce ecosystem: organizations need to treat their Salesforce security posture with the same rigor they apply to their network infrastructure.
That means regular configuration audits, a documented security baseline, and a consulting partner who understands the platform’s permission model well enough to spot risks before threat actors do.
How Digital Mass Can Help
Our team has direct, hands-on experience remediating the exact class of vulnerability exploited in this campaign. We have performed guest user access audits, locked down Aura endpoint exposure, and hardened Experience Cloud configurations for clients across industries.
We offer:
- Experience Cloud Security Assessments – a targeted review of guest user and external user profiles, sharing settings, API exposure, and public group visibility across your Experience Cloud sites, or a broader evaluation of your org’s permission model, including profiles, permission sets, sharing rules, and field-level security.
- Ongoing Security Governance – partnering with your team to establish baseline security standards, implement change monitoring, and conduct periodic reviews so misconfigurations do not accumulate over time.
If you have questions about your Experience Cloud security posture or want to schedule an assessment, reach out.
