Salesforce's security team published an advisory this week describing an active campaign targeting misconfigured Salesforce Experience Cloud sites. Here's what's happening, why it matters, and where Obsidian's coverage maps to every step of the remediation.
What's Happening
A known threat actor group is mass-scanning public-facing Salesforce Experience Cloud sites using a modified version of the open-source tool Aura Inspector. The original tool can only identify vulnerable API endpoints. The attacker's custom variant goes further: it can extract data at scale through Salesforce's GraphQL interface, bypassing the ~2,000-record limit of older techniques.
The target: overly permissive guest user configurations.
In Experience Cloud, anonymous visitors share a "guest user profile." When that profile is misconfigured to allow access to objects and fields never intended to be public, attackers can query Salesforce CRM data directly — no login required.
This is not a new vulnerability in the Salesforce product. It's a tenant configuration problem that security teams have flagged for years. What's new is the attacker tooling, which makes exploitation faster, higher-volume, and more automated than ever before.
Why It Matters: The SaaS Kill Chain
The data harvested in these scans — names, phone numbers, contact records — is not an end goal in itself. It's fuel for vishing (voice phishing) campaigns: attackers call targets, impersonate IT staff or company leadership, and use the harvested details to sound credible while extracting login credentials, MFA codes, or approvals for rogue SaaS-connected apps.
A guest user misconfiguration exposing a contact list can be the first link in a chain that ends in a full SaaS data breach.
What To Do: Obsidian’s Recommended Priority Order
1. Audit What Guest Users Can Actually Access 🔴 Highest Impact
There are two distinct rules in Obsidian that work together here, and it's important to understand what each one tells you.
Obsidian rule: Sharing Rules for Guest Users
This rule shows you the scope of data explicitly visible to all unauthenticated visitors right now — what objects have active sharing rules pointing to the guest user profile, under what criteria, and how many records are in scope. This is your blast radius: the data an attacker can reach today.
For each finding you can see:
- Which account is affected
- Which object was shared
- Level of access (read, read/write)
- Whether all records are in scope or only a filtered subset
- Record count — the actual volume of exposed data
Obsidian rule: Objects Accessible to Guests
This rule shows you the potential surface area — the set of objects that are permitted to be shared via a guest sharing rule at all. Think of it as the universe of objects that could be exposed, regardless of whether a sharing rule exists today. Use it to identify objects that should never be shareable with guests and tighten those permissions at the object level before a sharing rule is ever created.
Together, these two rules give you the full picture: what is exposed now, and what could be exposed through a future misconfiguration.
2. Disable API Access for Guest Users 🔴 Highest Impact
Obsidian rule: High Risk Permissions for Guest Users
This is the single most impactful change you can make. The API Enabled permission on a guest user profile is what allows attackers to programmatically query your Salesforce data through the Aura and GraphQL endpoints — the exact vector used in this campaign.
Obsidian's High Risk Permissions for Guest Users rule flags this directly. Use it to identify any guest profile where API Enabled — or other high-risk permissions such as View All Users, Run Flows, and Access Activities — remains enabled. Strip anything that doesn't have a specific, documented business need.
Important caveat: Some Experience Cloud sites may depend on guest API access to function. Test any change in a sandbox first. If API access cannot be fully disabled, treat all other controls on this list as non-negotiable.
3. Clean Up Legacy Guest Access Paths 🟠 Medium Impact
Obsidian rule: Guest User Legacy Group Members
Older Salesforce configurations may include Public Groups that still contain guest users — a broad and often forgotten access path. Obsidian's Guest User Legacy Group Members rule surfaces any remaining legacy group memberships so you can replace them with explicit, minimal guest sharing rules that align to Salesforce's current least-privilege guidance.
4. Lock Down External Org-Wide Defaults 🟠 Medium Impact
Obsidian rule: Objects with Public Default External Access
This control is not directly about guest users, but it matters significantly if an attacker successfully self-registers an external portal account — escalating from unauthenticated guest access into an authenticated session with broader permissions.
Salesforce recommends setting the Default External Access for all objects to Private in Sharing Settings. Obsidian's Objects with Public Default External Access rule flags any object where the external org-wide default is more permissive than Private. Work through these findings to ensure that even a compromised external account can't reach data it shouldn't.
5. Restrict User Visibility 🟠 Medium Impact
Obsidian settings: Portal User Visibility · Site User Visibility
Without these locked down, guest users can enumerate your internal org members — handing attackers a ready-made list of targets for follow-on social engineering. Obsidian surfaces both Portal User Visibility and Site User Visibility directly, so you can audit and track their state without leaving the platform.
Both should be false. Any environment where either setting is enabled should be treated as a gap to close.
6. Review Public File and Link Exposure 🟡 Low Impact
Obsidian rule: Files with Publicly Accessible Sharing Links
Object and field permissions often get all the attention, but files are a frequently overlooked exposure path. Obsidian's Files with Publicly Accessible Sharing Links rule flags any files accessible without authentication — no password, no login. Review these findings and restrict or remove public links wherever they aren't intentional.
Obsidian configuration mapping: Allow Site Guest Users to Upload Files
Also check whether your Experience Cloud sites permit guest users to upload files. For most sites, this should be disabled. An "enabled" finding here means an unauthenticated visitor can write content into your organization and treat any exception as something that requires explicit justification.
7. Disable Self-Registration if Not Required 🟡 Low Impact
Monitoring in progress in Obsidian
If your site doesn't require unauthenticated visitors to create accounts, disable self-registration. Data accessible through guest user misconfigurations can be used to self-register portal accounts, escalating a passive guest-tier exposure into an authenticated session with significantly broader data access.
Obsidian monitors the "Allow using standard external profiles for self-registration, user creation, and login" setting — a dedicated setting.
Action: Setup > All Sites > [Your Site] > Workspaces > Administration > Login & Registration. Remove the self-registration page assignment if it isn't required.
The Bottom Line
The Salesforce GraphQL guest user campaign is a wake-up call, not a novel zero-day. The underlying exposure has existed for years. What's changed is the attacker's ability to weaponize it at scale through automated tooling.
The single most impactful thing any Salesforce Experience Cloud customer can do today is check whether API Enabled is set on any guest user profile and turn it off. Obsidian already flags this. If you have an open finding on the High Risk Permissions for Guest Users rule — treat it as critical and remediate immediately.
For the controls we don't yet surface directly, the manual steps in Salesforce are straightforward. We're actively expanding coverage for Portal/Site User Visibility and self-registration monitoring.
Questions? Reach out to your customer success team or check these rules directly on the platform.
