This isn’t a rumor or a theoretical “posture issue.” Salesforce Experience Cloud is in the middle of an active data-theft campaign targeting a very specific failure mode: guest access that can reach more data than the organization intended.
You’ll also see the ShinyHunters name attached to this activity in reporting and online claims. ShinyHunters has a long track record of branding data-theft activity and then using stolen information for extortion and follow-on pressure, so it’s not surprising the name is showing up here. Still, attribution isn’t the part defenders should get stuck on. What matters operationally is repeatable and simple:
Attackers are scanning public-facing Experience Cloud sites at scale. Where they find overly permissive guest-user access, they can query data through the Experience Cloud Aura endpoint (/s/sfsites/aura) without logging in.
That turns what many teams may casually call a “misconfiguration” into an active breach path.
And it’s a textbook example of the shared responsibility model in SaaS. Salesforce runs the platform. Customers control the Experience Cloud configuration, guest-user permissions, and what data is reachable from public-facing experiences. This campaign is exploiting the gap between “what the business meant to publish” and “what the guest user can actually access.”
If enterprises are asking whether this is real, it is.
And if anyone is downplaying it as “just a misconfiguration,” they’re missing the point. Misconfiguration is the cause. Unauthorized access and data theft are the outcome.
The exposure pattern in one screen
Here’s the clean way to think about this, without getting lost in labels.
Public Experience Cloud site
- Guest user with broad permissions
- Queryable CRM objects
= Unauthenticated data access
This isn’t about stolen employee credentials, and it’s not dependent on ransomware or malware. It’s an internet-facing surface that can be tested and abused programmatically.
Why this campaign scales
This campaign doesn’t require one unlucky user with a bad setting. It scales for two reasons.
1) It’s easy to automate
Attackers aren’t manually browsing portals and guessing. They can programmatically discover Experience Cloud surfaces and test what an unauthenticated guest can reach. That means they can find weak configurations quickly and repeat the process across many organizations.
2) It relies on normal platform behavior
This campaign isn’t exploiting “weird” behavior. It’s taking advantage of normal application pathways that are available to a guest profile when permissions allow it.
That’s why it spreads quickly and why it’s showing up in conversations. It hits a nerve: public business functionality, tied to real data, exposed more broadly than intended.
Why AuraInspector keeps coming up
AuraInspector is an open-source tool originally published for defenders to test Salesforce Experience Cloud sites from the outside in. Think of it as a way to answer one blunt question: If I’m not logged in, what can the guest user actually see and query?
It does that by interacting with the same Aura endpoints Experience Cloud relies on and surfacing which objects and methods appear reachable given the site’s guest-user configuration. Some analysis also notes that certain retrieval approaches can make bulk extraction more efficient, but the controlling factor is still the same: if the guest user can reach the data, attackers will find a way to pull it at scale.
Salesforce has warned that threat actors are using modified tooling to operationalize the same outside-in testing for malicious purposes. The practical point is simple: once exposure can be tested repeatably, it’ll be tested aggressively, and at internet scale.
What’s actually at risk
It’s easy to underestimate what an “external portal” might expose.
But even when the data looks basic, it can be high value because it carries business context. Depending on what the guest profile can access, exposed data can include things like:
- Customer and executive contact information including names, phone numbers, and email addresses
- Case metadata and workflow context
- Internal identifiers that help attackers map targets and relationships
This matters for two reasons.
First, the exposure itself is harmful.
Second, harvested context is fuel for follow-on attacks. It improves phishing and vishing success rates, supports impersonation and fraud, and helps attackers target the right people with the right story.
That’s why this isn’t “just a Salesforce admin issue.” It’s a SaaS security issue with real downstream risk.
10-minute verification checklist
This is the fastest way to get signal without turning this into a multi-week project.
- List your public Experience Cloud sites
- Confirm what’s internet-facing today (not what was intended six months ago)
- Identify the guest user profile used by each site
- Document it, don’t assume it
- Review guest access at three layers
- Object permissions
- Record visibility
- Field-level access
- Spot-check the obvious high-risk objects
- Start with Contacts, Cases, Users, Accounts, and any custom objects tied to customer workflows
- Confirm what’s reachable as an unauthenticated user
- Use a clean browser session (signed out) and validate what the guest experience can query or reveal
If any of this feels vague inside your organization, that’s the point. Most exposure doesn’t come from one “bad decision.” It comes from drift.
What to do now
This isn’t the moment for abstract guidance. The goal is to eliminate the exposure conditions attackers are actively exploiting.
Treat the guest user like an internet adversary
Because that’s what it is.
Audit guest permissions with the same seriousness you’d apply to any public-facing surface. If the guest user can query it, an attacker can too.
Reduce what can be queried from the public surface
If your portal doesn’t require broad query capability to function, remove it. The safest public surface is the one that simply can’t enumerate sensitive objects.
Assume drift is real
Most exposures don’t happen because someone intentionally made data public. They happen because things change.
- New portal feature
- New object added
- Temporary permission granted
- Default behavior inherited
Build guest access review into your operating rhythm, not just your incident response.
Why this matters in the agentic era
This campaign is a reminder that public SaaS exposure doesn’t sit off to the side of the modern environment. It sits in the middle of it.
As organizations adopt AI copilots, agents, and automation across SaaS, the value of business context increases, and the number of workflows that depend on delegated action keeps growing. That makes public exposure harder to contain and more valuable to attackers.
This is exactly where SaaS security programs either mature or get surprised:
Public surfaces, real business data, and permissions that drift faster than most teams review them.
Closing
This campaign exploits one core weakness: guest access that can reach more than it should.
If your organization runs Experience Cloud, treat this like something to verify immediately, not something to “circle back on.”
Because the fastest way to lose control of a SaaS environment is assuming public-facing surfaces are “mostly fine” until someone proves they aren’t.
Want a clearer view of public exposure, risky guest access, and non-human access across your SaaS and AI environment? Schedule a demo to see how Valence helps security teams secure SaaS and AI in the agentic era.
