April 2026. McGraw Hill confirms the leak of 13.5 million records - names, emails, phones, physical addresses. Three days earlier, ShinyHunters announced the hacking of Amtrak – 2.1 million records with addresses and tickets. According to Have I Been Pwned, both incidents were recorded in the first decade of April. At the same time, Salesforce publishes an active campaign about an active campaign: attackers massively scan Experience Cloud and pull data through the Guest User - without a single login.
Contacts, addresses, support labels - a classic set of objects of any CRM. If your organization keeps this in Salesforce, the question is not, become Are you a goal, and that, find whether the misof configurations of Salesforce before attackers.
There's no zero-day. There is no complicated exploitation. Configuration errors have been in existence for years, and now they are operated on an industrial scale. Next is a specific attack chain, step-by-step audit instruction for your Salesforce-environment and a checklist of hardening-measures that close the main sections of the Salesforce data leakage.
All the salt in the shared responsibility model: Salesforce is responsible for the security of the platform, and for the configuration you yourself. And then there is a gap between the documentation and what is really happening in the production.
According to Obsidian Security, in 2026, a group of attackers launched a massive scanning of public Experience Cloud sites with a modified version of AuraInspector. The original tool (Google Mandiant) only finds vulnerable API-endopints. The casting version goes further - pulls the data through the GraphQL-interface Salesforce, bypassing the ~2000 entries limit characteristic of previous techniques.
The collected data - names, phones, emails, contact records - not an end in itself. According to Obsidian Security, they become fuel for vishing campaigns (voice phishing): attackers call victims, introduce themselves by the IT service or management and use the stolen parts for persuasiveness in the misleading of the MFA-codes.
One User Salesforce mixing, opening the contact list, can be the first link in the chain to a full-fledged hacking of the SaaS infrastructure.
The fence says “access is disabled”, and Guest User calmly pulls the API.
Setting up Salesforce security in the Future User part is to what objects and fields are available through the Sharen Rules. It is assumed that the administrator will open only public data - articles of the knowledge base, product catalog. In practice, in audits, I regularly see another:
According to Varonis, the attacker uses a sequence of descriptors for reconnaissance and extraction:
Separate headache - Apex-methods with directive without sharing. According to Reco.ai, they completely ignore Sharing Rules, allowing you to bypass access restrictions even with the correct configuration of the rules. Reco researchers found similar mys configurations in Fortune 500 companies.
GraphQL endpoint is available to Guest User as much as Aura, but allows you to retrieve data without a disability in 2000 records. GraphQL vector is used in the active campaign of 2026.
Personally, I look at it this way: AuraInspector is a symptom, not a disease. As Reco.ai emphasizes, the problem is that organizations have been exploiting irregular salesforce sites for years. The tool only makes detection and operation trivially simple.
For primary intelligence, Google dorks is enough. Experience Cloud sites have characteristic URL-patterns - /s/topic, /s/article, /s/contactsupport. Operator inurl: in conjunction with the name of the target organization often issues public Experience sites directly from the search results. There's no magic.
The reservation, and it is critical: Some Experience Cloud sites depend on guest API access for Lightning components. Test in sandbox. If API access cannot be disconnected completely, all other controls from this checklist become mandatory. No exceptions.
Similarly, we disable View All Users, Run Flows and Access Activities if there is no documented business reasoning for them.
Files with public links: Check the availability of files with sharing links available without authentication. Object permits focus on the main thing, and files are the often-forgotten data leak vector of Salesforce.
Self-registration: if the site does not require self-registration - disable. Path: Setup → All Sites → Select the site → Workspaces → Administration → Login & Registration - remove the purpose of the self-registration page. Data available through the User’s can be used to create portal accounts by escalating passive guest access in an authenticated session with broader rights. In fact, from “spying” we turn into “go, take what you want.”
Download User files - for most sites should be disabled. The included download means that an unauthenticated visitor can record arbitrary content in your organization.
The T1213.004 (Customer Relationship Management Software) technology is most specific to this vector - it describes data collection from CRM-systems.
To monitor adjust the alerta in Salesforce Event Monitoring on anomalous API-challenge maps from Guest User: mass queries to /s/sfsites/aura and GraphQL-endpoint, unusual volumes of unloading. Setup Audit Trail will fix the changes in the Sharing Rules and Profile Permissions - check it regularly for unauthorized modifications.
Disabling API Enabled can break the site if Lightning components use server calls for rendering. Always test in sandbox. If it is impossible to disable APIs - focus on the optimization of Object Permissions and Field-Level Security as compensating controls.
Salesforce access rights audits can be different depending on the version of API and edition (Enterprise, Unlimited). Requests to ObjectPermissions and PermissionSet available in API v49.0 and above.
The sret, cirrusgo and AuraInspector tools are designed to legitimately audit its own infrastructure. Their use against other people's copies without written permission is illegal. As part of red team or bug bootty, make sure the scope is clearly enabled the Salesforce.
Contacts, addresses, support labels - a classic set of objects of any CRM. If your organization keeps this in Salesforce, the question is not, become Are you a goal, and that, find whether the misof configurations of Salesforce before attackers.
There's no zero-day. There is no complicated exploitation. Configuration errors have been in existence for years, and now they are operated on an industrial scale. Next is a specific attack chain, step-by-step audit instruction for your Salesforce-environment and a checklist of hardening-measures that close the main sections of the Salesforce data leakage.
Why Salesforce Mysconfigration is a Critical Problem for CRM Protection in the Cloud
Salesforce is not just a CRM, but a platform on which companies build client portals, affiliate offices and knowledge bases through Experience Cloud. Each such site is a public entry point indexed by Google, through which external users interact with Salesforce-instanis data.All the salt in the shared responsibility model: Salesforce is responsible for the security of the platform, and for the configuration you yourself. And then there is a gap between the documentation and what is really happening in the production.
According to Obsidian Security, in 2026, a group of attackers launched a massive scanning of public Experience Cloud sites with a modified version of AuraInspector. The original tool (Google Mandiant) only finds vulnerable API-endopints. The casting version goes further - pulls the data through the GraphQL-interface Salesforce, bypassing the ~2000 entries limit characteristic of previous techniques.
The collected data - names, phones, emails, contact records - not an end in itself. According to Obsidian Security, they become fuel for vishing campaigns (voice phishing): attackers call victims, introduce themselves by the IT service or management and use the stolen parts for persuasiveness in the misleading of the MFA-codes.
One User Salesforce mixing, opening the contact list, can be the first link in the chain to a full-fledged hacking of the SaaS infrastructure.
How Attackers Operate Salesforce Experience Cloud
Guest User: Anonymous Access That Always Exists
Each Experience Cloud website has a Guest User - a special profile for unautrified visitors. The moment that administrators miss: according to the study of Reco.ai, Guest User exists even if the site settings are disabled the option “Gues Users can see interact with the site without logging in”. This user can still interact with the site through the Aura framework - JSON-protocol, which is the basis of Lightning components.The fence says “access is disabled”, and Guest User calmly pulls the API.
Setting up Salesforce security in the Future User part is to what objects and fields are available through the Sharen Rules. It is assumed that the administrator will open only public data - articles of the knowledge base, product catalog. In practice, in audits, I regularly see another:
- Sharing Rules without restrictions - give Guest User access to all object records, not specific
- No Field-Level Security - even with justified access to the object sensitive fields Phone, Email, Address remain open
- API Enabled on User Profile - this permission allows you to programmatically pull data through Aura and GraphQL
- Included Access Activities - Tasks and Events often contain internal notes. According to Reco.ai, this resolution was enabled by default until the researchers showed Salesforce the scale of the problem. Default has been changed, but on a bunch of old sites it is still active
Aura Endpoints and GraphQL: Salesforce Data Exposing
Fruit Frontend Experience Cloud uses HTTP enthusiasm /s/sfsites/aura for all interactions with the server. Each request is POST with a JSON structure describing the called method (descriptor) and parameters. Token with value undefined - Guest User, anonymous call.According to Varonis, the attacker uses a sequence of descriptors for reconnaissance and extraction:
- getConfigData- returns the domain of the organization, CSP-tuning and the list of available objects
- getObjectInfo- shows the fields of a particular object, their configuration and daughter bonds
- getItems- lists the object records (Account, Contact, Case)
- getRecord/ getRecordWithFields- pulls out specific records with extended fields and related objects
The advanced attacker will go further - will begin to look for custom and third-party components. According to Varonis, the definitions of available endpoints are loaded in JavaScript files from a URL of the look /l/{encoded_json}. Scanning them, the attacker learns about custom Apex methods and call methods.
Separate headache - Apex-methods with directive without sharing. According to Reco.ai, they completely ignore Sharing Rules, allowing you to bypass access restrictions even with the correct configuration of the rules. Reco researchers found similar mys configurations in Fortune 500 companies.
GraphQL endpoint is available to Guest User as much as Aura, but allows you to retrieve data without a disability in 2000 records. GraphQL vector is used in the active campaign of 2026.
Attackers: from sret to AuraInspector
Salesforce's myconfigurations have been in operation for years. Chronology of public instruments (according to Reco.ai):- 2021 - researcher Nitay Bachrach (now in Reco) publishes the first description of the technique of data extraction through GraphQL endpoint Salesforce
- 2022 - the appearance of sret and cirrusgo tools in the public domain, operating the same mechanisms through various API methods
- 2025–2026 – Google Mandiant’s team releases AuraInspector – the first public tool to use GraphQL to mass retrieve data from experienced Cloud sites
Personally, I look at it this way: AuraInspector is a symptom, not a disease. As Reco.ai emphasizes, the problem is that organizations have been exploiting irregular salesforce sites for years. The tool only makes detection and operation trivially simple.
For primary intelligence, Google dorks is enough. Experience Cloud sites have characteristic URL-patterns - /s/topic, /s/article, /s/contactsupport. Operator inurl: in conjunction with the name of the target organization often issues public Experience sites directly from the search results. There's no magic.
Salesforce hardring checklist: close the mys configurations
Disabling APIs and Critical Permissions Guest User
The most effective single action. The Enabled API on Guest Profile is something that turns a configuration error into an exploited attack vector. Way: Setup → Profiles → Guest Profile → System Permissions → Remove the flag API Enabled.The reservation, and it is critical: Some Experience Cloud sites depend on guest API access for Lightning components. Test in sandbox. If API access cannot be disconnected completely, all other controls from this checklist become mandatory. No exceptions.
Similarly, we disable View All Users, Run Flows and Access Activities if there is no documented business reasoning for them.
Setting up OWD and minimizing Sharing Rules
Sequence of actions to close Salesforce data exposure:- Install Default External Access = Private for all objects in Sharing Settings
- Revise each Sharing Rule for Guest User - delete the rules without a documented justification, replace "all records" with rules with specific criteria
- For each remaining rule, configure Field-Level Security - hide sensitive fields even with the necessary access to the object
- Enable Secure Guest Record Access in Sharing Settings – this limits Guest User’s access only to records explicitly shattered through Sharing Rules
- Install Default Owner for Guest User records - each entry must have the owner for the correct operation of the access rules
Control of user visibility, files and self-registration
Portal User Visibility and Site User Visibility - both settings should be false. According to Obsidian Security, with the values of Guest User included, it can list the internal users of the organization - a ready list of targets for social engineering.Files with public links: Check the availability of files with sharing links available without authentication. Object permits focus on the main thing, and files are the often-forgotten data leak vector of Salesforce.
Self-registration: if the site does not require self-registration - disable. Path: Setup → All Sites → Select the site → Workspaces → Administration → Login & Registration - remove the purpose of the self-registration page. Data available through the User’s can be used to create portal accounts by escalating passive guest access in an authenticated session with broader rights. In fact, from “spying” we turn into “go, take what you want.”
Download User files - for most sites should be disabled. The included download means that an unauthenticated visitor can record arbitrary content in your organization.
Mumping of Salesforce Mysconfigration on MITRE ATT&CK
The attack on the myconfindered Experience Cloud covers several tactics and techniques MITRE AT&CK. Mapping helps customize the detection and prioritize protective measures.The T1213.004 (Customer Relationship Management Software) technology is most specific to this vector - it describes data collection from CRM-systems.
To monitor adjust the alerta in Salesforce Event Monitoring on anomalous API-challenge maps from Guest User: mass queries to /s/sfsites/aura and GraphQL-endpoint, unusual volumes of unloading. Setup Audit Trail will fix the changes in the Sharing Rules and Profile Permissions - check it regularly for unauthorized modifications.
Restrictions of technology and the context of applicability
The described attack vectors and audit methods apply to Salesforce Experience Cloud (Lightning) with active Experience Sites. If the organization uses only the internal Salesforce without public portals - the vector through the Guest User is not applicable. But Salesforce OWD sharing settings and internal Sharing Rules remain relevant for protection against insiders and compromised accounting.Disabling API Enabled can break the site if Lightning components use server calls for rendering. Always test in sandbox. If it is impossible to disable APIs - focus on the optimization of Object Permissions and Field-Level Security as compensating controls.
Salesforce access rights audits can be different depending on the version of API and edition (Enterprise, Unlimited). Requests to ObjectPermissions and PermissionSet available in API v49.0 and above.
The sret, cirrusgo and AuraInspector tools are designed to legitimately audit its own infrastructure. Their use against other people's copies without written permission is illegal. As part of red team or bug bootty, make sure the scope is clearly enabled the Salesforce.
