A Security Tool Turned Against Its Users
In January 2026, Google-owned Mandiant released AuraInspector, an open-source tool designed to help Salesforce administrators audit their Experience Cloud configurations for security gaps. It was built with good intentions. Within weeks, the threat group ShinyHunters had modified it into a weapon.
By March 10, Salesforce was issuing urgent warnings to customers. ShinyHunters (also tracked as UNC6240 and Bling Libra) had used the modified tool to scan public-facing Experience Cloud portals at scale, quietly extracting data from organisations that had left their guest user permissions wide open. The group claims to have hit somewhere between 300 and 400 companies since September 2025, with around 100 described as "high-profile." On March 14, they began threatening to leak stolen data unless victims paid up.
Salesforce's official position? This wasn't a platform vulnerability. It was a customer configuration problem. And that distinction matters, because it means this was preventable.
Key Facts
- 300-400 companies compromised via misconfigured Salesforce Experience Cloud portals (ShinyHunters claim)
- Attack vector: modified AuraInspector tool scanning the /s/sfsites/aura API endpoint
- Root cause: excessive guest user permissions, not a Salesforce platform flaw
- Data stolen: names, phone numbers, contact records, and CRM data
- Industries targeted in follow-on attacks: financial services, manufacturing, legal, retail
- Lateral movement observed in under 60 seconds in some incidents
How the Attack Actually Works
Salesforce Experience Cloud lets organisations build public-facing portals. Customer support sites, partner hubs, community forums. These portals use "guest user" profiles to control what unauthenticated visitors can see and do. The problem is straightforward: too many organisations left these profiles configured with excessive permissions, often granting API access and read permissions on CRM objects that should never be public.
The original AuraInspector tool from Mandiant would scan these portals and flag which objects were exposed. Useful for defenders. ShinyHunters took it a step further. Their modified version didn't just identify the gaps. It extracted the data sitting behind them.
The attack requires two things to succeed. First, the target has to be running an Experience Cloud portal. Second, the guest user profile needs to have overly permissive settings. If both conditions are met, the attacker doesn't need credentials, doesn't need to phish anyone, and doesn't need to exploit a software bug. They just query the API endpoint and the data comes back.
That's what makes this so uncomfortable. There's no clever zero-day here. No sophisticated exploit chain. Just a misconfiguration sitting on the public internet, waiting to be found by whoever looks first.
Why This Keeps Happening
Salesforce isn't the first platform to have its customers burned by default or misconfigured settings on public-facing infrastructure. We've seen the same pattern with exposed S3 buckets, open Elasticsearch clusters, and misconfigured Azure Blob storage. The technology is different each time, but the underlying failure is always the same: organisations don't have visibility into what their internet-facing assets are actually exposing.
There's a gap between what security teams think their external attack surface looks like and what it actually looks like. SaaS platforms make this worse, not better. Every new portal, API endpoint, or integration creates another surface that needs monitoring. Configuration drift happens silently. A setting gets changed during a migration, a new portal goes live without a security review, a guest profile inherits permissions it shouldn't have. None of this generates an alert unless you're actively looking for it.
ShinyHunters didn't need advanced capabilities to pull this off. They needed a scanner and patience. That should worry anyone running internet-facing services, because if a threat group can find your misconfigurations at scale, so can every other attacker with a script.
What Happens After the Breach
The stolen data (names, phone numbers, contact records) might not sound catastrophic on its own. But ShinyHunters isn't just hoarding it. Palo Alto Networks Unit 42 reported on March 12 that the stolen contact data is feeding follow-on voice phishing campaigns targeting financial services, manufacturing, legal, and retail organisations. In one documented case from 2025, attackers achieved lateral movement within 60 seconds of initial access gained through social engineering.
This is how modern attack chains work. The initial breach isn't the end goal. It's the first step. Stolen CRM data gives attackers the context they need to craft convincing pretexts. They know who your customers are, who your contacts are, and what relationships exist. That makes subsequent phishing and vishing campaigns far more effective than generic spray-and-pray approaches. We've seen this pattern play out repeatedly in recent ransomware campaigns too, where initial access brokers sell stolen data to ransomware operators.
ShinyHunters has also set a deadline. Pay up by March 14, or the data gets leaked publicly. For the organisations involved, that clock is already ticking.
What You Should Do Right Now
If You Use Salesforce Experience Cloud
Salesforce has published specific guidance. The critical steps are:
- Set Default External Access to Private on all guest user profiles
- Disable guest user API access unless there's a documented, justified business need
- Review object-level permissions on guest profiles and remove read access to any CRM objects that shouldn't be publicly queryable
- Monitor access logs for unusual query patterns against the /s/sfsites/aura endpoint
- Audit every Experience Cloud portal for configuration drift since its initial deployment
Regardless of Your Tech Stack
This breach is a reminder that your external attack surface extends well beyond your own servers. Every SaaS portal, every public API, every customer-facing integration is a potential entry point if it's misconfigured. As we covered in our piece on the strategic benefits of automated vulnerability scanning, the organisations that avoid incidents like this are the ones that treat external attack surface monitoring as a continuous process, not a quarterly checkbox.
- Maintain an up-to-date inventory of every internet-facing asset, including SaaS portals and third-party integrations
- Run external vulnerability scans weekly at minimum. 75% of vulnerabilities are exploited within 19 days of disclosure. Pair this with DAST and SAST testing for coverage of your application code as well
- Review public-facing configurations after every deployment, migration, or platform update
- Treat configuration audits with the same urgency as patching. A misconfiguration is just as exploitable as an unpatched CVE
- Set up automated alerts for configuration changes on internet-facing services
How Luna Helps
Luna scans your internet-facing infrastructure continuously, covering websites, servers, APIs, and network services. It checks for open ports, known CVEs, SSL/TLS weaknesses, and misconfigurations that attackers exploit. With 11,000+ security templates and scheduled daily, weekly, or monthly scans, Luna gives your team visibility into your external attack surface before threat groups like ShinyHunters find the gaps first.
Findings are mapped to OWASP Top 10, Cyber Essentials, and other compliance frameworks, with Slack and email alerts so your team can respond in hours rather than weeks. Because the lesson from this Salesforce breach is simple: if you're not scanning your own external surface, someone else will.
Frequently Asked Questions
How do I secure Salesforce Experience Cloud guest user access?
Start with Salesforce's own guidance. Their secure guest user sharing documentation walks through the core settings. The short version: set Default External Access to Private, disable guest API access, and strip object-level permissions down to the bare minimum your portal actually needs. Salesforce also publishes best practices for configuring guest user profiles that cover common mistakes. Review these against every portal you run, not just the ones you think are exposed.
How did ShinyHunters breach Salesforce Experience Cloud?
They modified Mandiant's open-source AuraInspector tool to mass-scan public-facing Experience Cloud portals via the /s/sfsites/aura API endpoint. Where guest user profiles had excessive permissions, the tool extracted CRM data without needing any credentials. This was a customer misconfiguration issue, not a Salesforce platform vulnerability. Salesforce confirmed this in their March 2026 security advisory.
How many companies were affected?
ShinyHunters claims between 300 and 400 companies since September 2025, with around 100 described as high-profile. Industries targeted in follow-on attacks include financial services, manufacturing, legal, and retail. The exact number is difficult to verify independently since many affected organisations have not disclosed the breach publicly.
The Bigger Picture
ShinyHunters didn't break into Salesforce. They walked through doors that hundreds of organisations left open. The group took a legitimate security tool, made a few modifications, and turned it into a mass-scanning operation that compromised data from hundreds of companies in a matter of weeks.
Salesforce is right that this isn't a platform vulnerability. But that's cold comfort for the organisations whose customer data is now in the hands of an extortion group. The responsibility for securing configurations falls on the teams running those portals. And the only way to know whether your configurations are actually secure is to test them. Regularly, automatically, and from the outside in.
If there's one takeaway from this incident, it's this: your external attack surface is bigger than you think, it changes faster than you expect, and the window between a misconfiguration going live and an attacker finding it is shrinking every month. Continuous monitoring isn't optional anymore. It's the baseline.