Salesforce recently issued a warning that attackers are targeting Experience Cloud (Aura) sites with overly permissive guest user settings. The company stressed that this is not a platform bug, but rather misconfigured guest access. Security researchers confirm that a modified AuraInspector audit tool is being used to scan public Aura API endpoints ( /s/sfsites/aura ) and siphon data from unsecured Salesforce sites.
In short, if a Salesforce portal’s Guest User profile has excess permissions, an unauthenticated attacker can directly query CRM objects. Salesforce has advised customers to enforce least-privilege settings for example, disabling guest API access and setting all objects to private by default. These steps should lock down any unwanted exposure.
How ShinyHunters Mass-Scans Aura Endpoints
The extortion group ShinyHunters claims responsibility for the attacks, stating they have been scanning for Aura endpoints since September 2025. They use automated searches for publicly exposed Experience Cloud websites by scanning the /s/sfsites/ path. They use paged data to get past the 2,000 records per query limit enforced by Salesforce. Once they find an incorrectly configured website, they use their own scripts, such as Anthropic/RapeForceV2 or browser-agent disguises, to quietly harvest data.
- They reused AuraInspector, which is open source and was initially created for Experience Cloud security audits. ShinyHunters’ tool not only detects misconfigurations but also retrieves data from Aura pages.
- After ShinyHunters released their tool, Salesforce fixed known bypasses in AuraInspector’s code. ShinyHunters then released methods to bypass those fixed bypasses, such as using GraphQL queries and a technique called boxcar bundling of actions, to continue data harvesting.
- In a nutshell, ShinyHunters’ tool can send a request to Salesforce that bundles dozens of backend data fetches, which is useful for exfiltrating a lot of data at a time, such as a whole table.
This is exactly what ShinyHunters is doing. They are using a tool to crawl all data from any portal that is left open. Salesforce states that a scan detected by a log is not a breach in and of itself.
Widespread Impact: High-Profile Targets
The ShinyHunters group stated that their campaign accessed “hundreds of websites,” which included data from almost 400 Aura-enabled websites and around 100 prominent companies, like Snowflake, LastPass, Okta, AMD, and Salesforce. The victims of this data breach are mostly tech and cybersecurity companies, which made it a highly publicized incident.
ShinyHunters scanned indiscriminately, which meant any misconfigured website made them a potential target. Experts are advising organizations to assume that their websites have been scanned by attackers. All it takes is a misconfigured website for attackers to gain access to data.
Salesforce’s Recommended Mitigations
Salesforce recommends taking immediate action with critical fixes:
- Restrict guest permissions: Narrow down the guest profile to the minimum.
- Disable guest API access: Uncheck ‘Allow guest users to access public APIs’ and uncheck ‘API Enabled’ on guest profile; close Aura endpoint to anonymous queries.
- Make org-wide defaults private: Set external user defaults to ‘Private’.
- Disable user visibility: Disable ‘Portal User Visibility’ and ‘Site User Visibility’ to stop guests from enumerating internal users.
- Disable any self-registration: If not needed, turn off open sign-ups to stop guest data from creating portal accounts.
- Monitor and respond: Check Aura Event Monitoring to identify suspicious activity and respond to it, set up a security contact to respond to any security incidents.
It reduces risk through customer-side configurations rather than code-level fixes. Locking down configurations may stop the attack. Attackers found that disabling public guest access is the surest way to stop it, even though it reduces site publicness.
Conclusion: When “Guest Access” Becomes Data Exfiltration
This campaign is not a Salesforce platform bug. It is a configuration failure with breach-level consequences. If an Experience Cloud (Aura) site grants excessive Guest User permissions, an unauthenticated attacker can query CRM objects directly through public Aura endpoints like /s/sfsites/aura and quietly siphon data.
Why This Threat Scales So Fast
ShinyHunters did not need zero-days. They used automation.
- Mass scanning of exposed Experience Cloud paths to find misconfigured portals
- Modified AuraInspector to both detect exposure and retrieve data
- High-volume extraction using techniques like boxcar bundling of actions, and continued harvesting via GraphQL approaches
This turns one misconfigured portal into a full table pull, at attacker speed.
Why Organizations Are Vulnerable
Any public-facing portal can inherit risk from one overly permissive setting.
Salesforce highlights least-privilege as the real fix, including disabling guest API access and setting objects to private by default.
Experts advise assuming your site has been scanned, because the campaign was indiscriminate and any misconfigured site becomes a target.
Where Xcitium Changes the Outcome
If you have Xcitium, this attack would NOT succeed.
With Xcitium Vulnerability Assessment, this exposure should have been visible before attackers found it. Misconfigurations that enable anonymous data queries can be identified, prioritized, and remediated, so guest access cannot be weaponized into data theft.
Close the Exposure, Then Monitor for Bulk Retrieval
Lock down Guest User permissions, disable guest API access, set external defaults to Private, disable user visibility and unnecessary self-registration, then monitor Aura event logs for high-frequency bulk retrieval patterns.
