There's a lot of noise out there about Salesforce security this year. Headlines, breach disclosures, vague "third-party CRM" language. I've been tracking this closely and the picture is both alarming and clarifying.
Here's the actual breakdown.
Since early 2026, a coordinated data theft campaign has been targeting Salesforce customers at scale. The threat group ShinyHunters is heavily implicated and has claimed responsibility for dozens of high-profile breaches.
What's important to understand upfront: these aren't exploits of Salesforce itself. The platform isn't broken. What's broken is how people configure the platform and implement their Salesforce application.
The attacks leverage permission misconfigurations, social engineering, and third-party vulnerabilities — not inherent platform flaws.
The scale of this is hard to ignore once you notice the list of targets which include Grubhub, Odido, Axios, LexisNexis and Loblaw just to name a few.
That's not a rough patch. That's a sustained, multi-month offensive against Salesforce customers by finding vulnerabilities in their application.
The attackers aren't doing anything clever. They're doing what works.
This is the big one. Public-facing sites with overly permissive guest user profiles are the primary entry point. Salesforce's own warning pointed directly at this — guest users who can read far more than they should.
Targeting employee accounts to bypass security controls. A single compromised credential can undo months of security investment. The Infinite Campus breach came from a single employee's Salesforce account.
When guest user profiles have "API Enabled" checked, attackers can bulk-exfiltrate data at scale. This is the difference between seeing a few records and walking away with tens of millions.
The Odido breach didn't just come from Salesforce directly — it involved a BeyondTrust vulnerability in integrated software. Attackers increasingly pivot through connected vendors to reach the org.
Notice a pattern in the headlines? Victims often refer to Salesforce generically as a "third-party CRM" in breach disclosures. This downplays direct platform involvement and makes it harder to track the real scope of the problem.
These aren't theoretical recommendations. Each one closes an active attack vector being exploited right now.
Restrict guest user profiles to the absolute minimum objects and fields required. If a guest doesn't need access to it, they shouldn't see it. Period.
All objects should be set to Private for external users in Sharing Settings. This is your baseline. You can always open things up selectively — but starting wide is how you end up on a breach list.
Uncheck API Enabled in the guest user profile's System Permissions. If guests don't need programmatic access, don't give it to them. This alone stops bulk exfiltration.
Uncheck Portal User Visibility and Site User Visibility in Sharing Settings. Guest users shouldn't be able to enumerate other users in your org.
If unauthenticated visitors don't need to create accounts, turn self-registration off. Every new account is another surface to manage and potentially misconfigure.
The threat landscape is active and evolving. The good news is that these are all configuration problems, not Salesforce platform problems. That means you can fix them without waiting for a patch.
Misconfigurations are the attack surface. Proper guest user and admin hygiene stops most of what's being exploited right now.
Start with one public-facing site, audit its guest profile, and work outward. You'll likely find more than you expected.
Managing user access in Salesforce is a delicate dance. Profiles are the foundation, but Permission Sets are the future. Here's how to build a scalable security model.
Burning tokens isn't a productivity metric, it's a cost center. Here's how the frugal AI shift translates into concrete architecture decisions on Salesforce projects.
Hooks let you enforce behavior in Claude Code instead of hoping the model does the right thing. The mental model, three Salesforce-specific hooks, and why this matters more in Salesforce than in most stacks.