Recently, the Salesforce Security team has noticed a rise in activity from threat actors targeting misconfigured public websites. In particular, we’ve identified a campaign where attackers are taking advantage of overly permissive Experience Cloud guest user settings. When these settings are configured incorrectly, attackers may be able to access more information than organizations intended to make public.
Since our initial report, our investigation has uncovered additional configuration scenarios that could lead to unintended exposure of customer data. As a result, we’ve updated this guidance and included new recommended actions below.
It’s important to clarify that Salesforce itself remains secure. This situation is not caused by a vulnerability in the Salesforce platform. Our findings show that the issue arises from how certain guest user permissions are configured by customers, rather than from a flaw in the platform. We are sharing this information to help customers review their environments and take the necessary steps to strengthen their security.
About the Threat Actor Activity
Our Cyber Security Operations Center (CSOC) has been monitoring a campaign linked to a known threat actor group.
Evidence suggests that the attackers are using a modified version of an open-source tool called Aura Inspector, originally developed by Mandiant. They are using this tool to scan large numbers of publicly accessible Experience Cloud websites. The standard version of Aura Inspector can identify potentially vulnerable objects by probing API endpoints exposed by these sites, particularly the /s/sfsites/aura endpoint.
However, the threat actor appears to have built a customized version of the tool. Instead of just identifying vulnerabilities, this modified tool can also extract data when guest user permissions are overly broad.
On publicly accessible Salesforce Experience sites, anonymous visitors operate under a shared “guest user profile.” Normally, this profile allows unauthenticated visitors to view information that organizations intentionally make public. But if the guest profile has too many permissions, sensitive information that was never meant to be public could become accessible. In such cases, attackers may be able to directly query Salesforce CRM objects without needing to log in.
For an Experience Cloud customer to be vulnerable to this activity, two conditions generally need to exist:
- The site uses a guest user profile.
- The guest profile allows public access to objects or fields that should not be publicly available, which goes against Salesforce’s recommended configuration guidelines.
This activity also reflects a broader trend toward identity-based attacks. Information gathered from these scans—such as names or phone numbers—can later be used in targeted social engineering attacks, including voice phishing (vishing) campaigns.
Understanding Experience Cloud Data Access Controls
Salesforce Experience Cloud manages data access using a four-layer security model. Each layer is evaluated in sequence. If access is denied at any stage, the user cannot proceed further.
Layer 1 — Object Access
Defines which objects a user can view.
Layer 2 — Record Access
Controls which specific records within those objects are visible.
Layer 3 — Field-Level Security (FLS)
Limits access to certain fields within those records.
Layer 4 — Field Value Masking
Masks sensitive field values even if the user can view the record.
A user’s ability to view a field depends on permissions across all these layers. If any layer is configured too broadly, it may unintentionally expose data. The recommendations below are designed to help close those gaps.
Recommended Immediate Actions for Customers
Security is a shared responsibility and works best when multiple layers of protection are in place. While Salesforce continues to improve anomaly detection and introduce new safeguards, customers should also take proactive steps to secure their environments. A good starting point is reviewing guest user permissions and applying the principle of least privilege, ensuring users only have the access they truly need.
Recommended actions include:
Audit Guest User Configurations
Review the guest user profile and limit access to only the objects and fields required for the site to function. Start with no access and grant permissions only as needed for verified functionality.
Set Organization-Wide Defaults to Private
In Sharing Settings, make sure that Default External Access for all objects is set to Private. Also confirm that Secure Guest User Record Access is enabled so guest users can only access records through explicit sharing rules.
Disable Public API Access
Turn off the option that allows guest users to access public APIs, and remove API access from the guest user profile’s system permissions. This change blocks the Aura endpoint from unauthenticated API queries, which is the primary technique used in this campaign.
Restrict User Visibility
Disable “Portal User Visibility” and “Site User Visibility” in Sharing Settings to prevent guest users from listing or discovering internal users within your organization.
Disable Self-Registration if It’s Not Needed
If your site does not require visitors to create accounts, disable self-registration. Data exposed through guest user misconfigurations could otherwise be used to create portal accounts and gain broader authenticated access.
Review Enhanced Personal Information Masking (EPIM)
If the setting “Let guest users see other members of this site” is enabled, certain User object fields may become visible. Since these fields cannot be restricted using Field-Level Security, Enhanced Personal Information Masking should be used to protect sensitive details such as Last Login Date or Last Password Change.
Organizations that were active before Spring ’22 should also verify that fields like Latitude, Longitude, Address details, and Mobile Phone are included in the EPIM protection set.
Enable Profile Filtering
Without profile filtering enabled, guest users may be able to see profiles within the organization, including internal ones. Enabling profile filtering ensures users can only see their own profile unless they have administrative permissions.
Enable Nicknames Instead of Real Names
By default, real names are visible to other site members. Enabling “Show Nicknames” hides users’ real first and last names and improves privacy. Additional protection can be enabled by hiding these fields from the SOAP API for site users.
Review Field-Level Security for Other Objects
EPIM protects only the User object. For other objects such as Contact, Lead, Case, or custom objects, Field-Level Security should be carefully reviewed. Remove access to any fields that guest users do not absolutely need—especially sensitive fields like email addresses, phone numbers, addresses, case descriptions, or custom data fields.
Ongoing Monitoring and Investigation
Customers should continue monitoring their environments for suspicious activity.
Review Event Monitoring Logs
Examine Aura Event Monitoring logs for unusual patterns such as high query volumes, access attempts to objects that shouldn’t be public, requests from unfamiliar IP addresses, or activity outside normal business hours.
If you believe your environment may have been affected, contact Salesforce Support and complete the guest user permission audit described above.
Add a Security Contact
Ensure your Salesforce organization has a designated Security Contact. This allows Salesforce to quickly reach the right person if suspicious activity is detected.
