Skip to content
HACKTECH
Data exposureReported Published 5 sources

Salesforce warns of mass scanning of Experience Cloud sites with open guest access

On 7 March 2026 Salesforce warned that a known threat actor group was using a modified version of Aura Inspector, an open-source tool originally developed by Mandiant, to mass-scan public-facing Experience Cloud sites and extract data where guest user profiles had been given access to objects and fields not intended to be public. Salesforce said the activity 'relates to a customer-configured guest user setting, not a platform security flaw.' ShinyHunters claimed responsibility and told The Register it had stolen data from almost 400 websites and about 100 high-profile companies; a Salesforce spokesperson declined to say how many customers were affected or whether ShinyHunters was behind the access.

  • Salesforce
  • Experience Cloud
  • guest user access
  • SaaS misconfiguration
  • Aura Inspector
  • ShinyHunters

What the sources report

  • Salesforce's advisory (published 7 March 2026, updated 11 March to cover additional configuration scenarios) says the original Aura Inspector is limited to identifying vulnerable objects by probing the /s/sfsites/aura endpoint, while the actor's custom version goes 'beyond identification to actually extract data.'
  • Salesforce says a misconfigured guest profile lets anonymous visitors 'directly query Salesforce CRM objects without logging in', and that harvested data such as names and phone numbers is often used for follow-on social engineering and vishing.
  • Salesforce calls disabling guest access to public APIs and unchecking API Enabled on the guest profile 'the highest-impact single change'; other steps include Private default external access for all objects, unchecking Portal and Site User Visibility, and disabling self-registration where it is not needed.
  • Mandiant Consulting CTO Charles Carmakal told The Register and BleepingComputer the actor was 'misusing the AuraInspector open-source tool to automate vulnerability scans across Salesforce environments' and that detecting scanning activity in logs 'does not indicate a compromise.'
  • ShinyHunters told BleepingComputer it began targeting insecure guest-user configurations in September 2025 and claimed a method to steal data from Aura instances even when properly configured; BleepingComputer said it could not independently confirm this, and Salesforce continued to state there is no vulnerability in its platform.
  • On 14 April 2026 McGraw-Hill, which ShinyHunters had named on its leak site, told BleepingComputer that attackers accessed 'a limited set of data from a webpage hosted by Salesforce on its platform' as part of 'a broader issue involving a misconfiguration within Salesforce's environment that has impacted multiple organizations'; the report does not say whether this was the Experience Cloud guest-access activity. Have I Been Pwned later indexed 13.5 million unique email addresses from more than 100 GB of published data.

What it means for your organisation

According to Salesforce, the campaign relied on permissions customers had granted to unauthenticated visitors rather than on a platform flaw, and a repurposed open-source audit tool found those permissions at scale. Because the vendor treats these settings as customer configuration, the customer's own security reviews need to cover them.

What we check

  • Enumerate Experience Cloud and other public portal sites and test, as an unauthenticated guest, which objects and fields the /s/sfsites/aura endpoint and public APIs return.
  • Review guest user profiles, org-wide defaults for external access, sharing rules and field-level security on Contact, Lead, Case and custom objects.
  • Confirm that guest access to public APIs, API Enabled on guest profiles, Portal and Site User Visibility, and self-registration are disabled unless there is a documented need.
  • Check that Aura event monitoring and log retention are in place so scanning and bulk record queries from unfamiliar IP addresses can be detected and investigated.

Sources

Services that cover these checks

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Database security audit

    A configuration and access review of your production databases: who can connect, from where and with which privileges, whether data is encrypted at rest and in transit, what is logged, and whether backups would survive the same attacker. We read each instance's live configuration.

    Duration: 3 to 7 working days

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works