The Salesforce Experience Cloud Attack: A Wake-Up Call for Misconfigurations Management

The latest Salesforce Experience Cloud story is worth the attention it’s getting, but maybe not for the reason people first assume.

Salesforce says the activity it has been tracking is not a platform flaw. It is a threat campaign targeting customer-side misconfigurations in public-facing Experience Cloud environments. That distinction matters.

When attackers can reach business data not through a novel exploit chain, but through overly broad permissions on a SaaS surface that was meant to be public, the lesson is much bigger than Salesforce itself: in modern SaaS environments, security failures often start with governance gaps, not code defects.

What happened in the attack?

According to Salesforce, malicious actors used a modified version of AuraInspector. An open-source tool originally developed to help identify misconfigurations, attackers used it to mass-scan public Experience Cloud sites, probe the /s/sfsites/aura endpoint, and identify environments where guest user profiles had access to objects or fields that should not have been exposed.

In those cases, the actor’s custom tooling could move from discovery to extraction, directly querying Salesforce CRM objects without authentication.

Salesforce’s position on this? The platform itself remains secure; the risk emerges when guest user settings are more permissive than intended.

Independent reporting adds two important nuances. First, ShinyHunters has publicly claimed responsibility and alleged access to hundreds of sites and roughly 100 high-profile companies, but those figures are still attacker claims rather than fully verified victim counts.

Second, Mandiant has cautioned that seeing AuraInspector-style scanning in logs does not, by itself, prove compromise. It does, however, mean organizations should investigate quickly, because scanning is often the first step in operationalizing a much broader campaign.

The implications for SaaS environments everywhere

What makes this attack so significant for SaaS environments is the way modern cloud applications blur the line between a “public experience” and a “system of record.”

Experience Cloud is designed to expose carefully selected CRM data and workflows to customers, partners, or anonymous visitors. Salesforce describes access control in this model as layered across object access, record access, field-level security, and field value masking.

If any one of those layers is configured too broadly, sensitive data can become reachable through perfectly legitimate SaaS interfaces. That is exactly why misconfiguration risk is so persistent: the product is behaving as designed, but the design has been overexposed.

There is also a second-order risk here that security leaders should not underestimate. Salesforce explicitly says the data harvested in these scans can include details such as names and phone numbers, which can then be used to fuel targeted social engineering and vishing campaigns.

In other words, the initial exposure is not just a data governance issue. It can become the reconnaissance layer for identity compromise, fraud, downstream supplier targeting, and broader SaaS intrusion paths. This is one reason the company described the campaign as part of a broader trend in identity-based targeting.

That is why the right response is not a one-time emergency audit followed by a sigh of relief. It is continuous misconfiguration management.

Continuous misconfiguration management as the next step

In Salesforce’s own guidance, the immediate priorities are straightforward: audit guest user configurations, enforce least privilege, set external access to private, disable guest access to public APIs and unnecessary API permissions, restrict visibility settings, disable self-registration where it is not needed, and review Aura/Event Monitoring logs for anomalous access patterns.

The common theme is simple: define exactly what public access must be, and then continuously prove that it has not drifted beyond that boundary.

This is also why the story matters far beyond Salesforce. Security teams are now managing dozens or hundreds of business-critical SaaS applications, each with its own sharing model, admin surface, third-party integrations, and permission sprawl. Point-in-time reviews break down in that world.

What truly works is a posture management approach that establishes a secure baseline, detects configuration drift early, prioritizes exposure by business impact, and drives remediation before an attacker turns a gap into an incident.

DoControl publicly describes this category as the continuous identification of security drifts and compliance gaps across hundreds of SaaS security controls, paired with remediation capabilities rather than passive reporting alone.

This is where I believe DoControl adds real value. Our view has long been that SaaS security is not just about seeing risk; it is about operationalizing control across data, identities, permissions, and connected apps.

Public information about DoControl’s platform reflects that approach: a unified inventory of SaaS assets, users, and third-party apps; continuous posture management for insecure configurations; DLP and behavioral analytics for sensitive data and abnormal activity; and automated remediation workflows that reduce the lag between detection and response.

In a campaign like this one, that operating model matters, because attackers are exploiting the gap between a risky configuration being introduced and someone noticing it.

For Salesforce specifically, DoControl can build inventory across Salesforce assets and users, monitor live activity through Salesforce Shield event monitoring, classify risk using context from IdP, HRIS, and EDR systems, scan for sensitive data types such as PII, PHI, PCI, secrets, and credentials, and trigger automated remediation workflows.

That matters because incidents like this rarely stay confined to a single setting. Once a public-facing configuration is too open, the next questions are always the same: what data is exposed, who can reach it, what users or third parties interact with it, what activity looks abnormal, and how quickly can we contain it?

More broadly, DoControl has expanded its posture layer to include the top industry misconfiguration apps and controls, and added configuration drift capabilities designed to surface data exposure, compliance gaps, and configuration changes across the SaaS stack.

Security teams need THIS kind of operating posture: not just another dashboard that tells you something went wrong after the fact, but the ability to continuously govern what changed, why it matters, and what to do next.

The takeaway from the Salesforce Experience Cloud campaign is actually extremely straightforward. The next wave of SaaS incidents will not always announce itself as a flashy zero-day. Sometimes it will be a public endpoint, an anonymous profile, an overly permissive object setting, or a forgotten sharing rule that sits quietly until an attacker industrializes discovery.

The organizations that stay out of the headlines will be the ones that treat misconfiguration management as a core security discipline, not a quarterly hygiene exercise. And that is exactly why this story matters so much beyond Salesforce.