The 2026 Salesforce Breach Wave: Is Your Org's Front Door Open?

On August 4, Brinks Home — a company whose entire business is keeping intruders out — confirmed that attackers had stolen roughly 4.9 million customer records from its Salesforce environment. The breach was detected on July 20, and it's only the latest entry in a list that has been growing all year. If your company runs Salesforce and has any kind of public-facing portal, community, or help center, this story is about you — even if you've never heard of the attackers involved. Here's what has actually been happening in 2026, why it's a configuration problem rather than a platform problem, and a practical checklist you can work through this week to make sure your org isn't next.

1. What's Actually Happening: The 2026 Breach Wave in Brief

The attacks trace back largely to one group, ShinyHunters, which spent 2026 systematically scanning the internet for misconfigured Salesforce Experience Cloud sites — the public communities, portals, and help centers thousands of companies run on top of their orgs. The year opened with Grubhub confirming a breach in January. By March, the group claimed to have compromised roughly 100 high-profile companies, with broader estimates putting the total between 300 and 400 organizations. The victims since then read like a cross-section of the economy: LexisNexis (3.9 million records), Canadian grocery giant Loblaw (a claimed 75 million records), Hallmark (7.9 million), home security provider ADT (over 10 million), and now Brinks Home.

The response from regulators was unusually fast. On March 7, Salesforce announced it was "tracking an increase in threat actor activity" targeting misconfigured public-facing sites, and FINRA issued a cybersecurity alert the same week urging member firms to review guest user permissions and treat any exposed data as compromised. Stolen data hasn't just been sold — it's being used to fuel targeted phishing, voice phishing (vishing), and extortion campaigns against the affected companies' employees and customers.

This follows the 2025 campaigns that hit Salesforce customers through social engineering and compromised third-party app integrations. The playbook keeps evolving, but the pattern is consistent: attackers aren't breaking into Salesforce. They're walking through doors that customers left open.

2. The Uncomfortable Truth: It's Not Salesforce, It's the Settings

Salesforce has been blunt about this: "this issue is not due to any vulnerability inherent to our platform." And the technical details back that up. The attackers used a modified version of an open-source scanning tool to probe publicly accessible Experience Cloud endpoints, looking for guest user profiles with overly generous permissions. Where they found one, they could query data through standard APIs — in some cases using a quirk of query sorting to page past the usual 2,000-record limit and extract entire databases.

Nothing in that chain is an exploit in the traditional sense. Every step uses functionality working exactly as designed. The vulnerability is the configuration: a guest user profile that can read Contact records it shouldn't, org-wide defaults left at Public Read Only for external users, API access enabled for anonymous visitors who never needed it.

This is the cloud's shared responsibility model in action. Salesforce secures the platform; you secure your configuration. It's the same reason a deadbolt manufacturer isn't liable when someone leaves the door unlocked. The good news buried in that uncomfortable truth: because the problem is configuration, the fix is also configuration. You don't need to buy anything. You need to audit.

3. Why Mid-Market Orgs Are Prime Targets

It's tempting to read the headlines — Loblaw, ADT, LexisNexis — and conclude this is an enterprise problem. The opposite is closer to the truth. These attacks are automated mass scans. The attackers aren't choosing targets by revenue; they're harvesting every misconfigured site their tools can find. A 200-person distributor's customer portal shows up in the same scan results as a Fortune 500's.

Mid-market orgs are often more exposed, for three familiar reasons. First, many portals were built years ago — by a consultant long gone or an admin two admins ago — and haven't had a security review since. Second, most mid-market teams run lean: one admin wearing five hats, with no dedicated security function watching sharing settings. Third, there's a widespread assumption that "Salesforce handles security," which is true for the infrastructure and false for your data model. If you launched an Experience Cloud site before guest user security tightening became a priority, and no one has revisited it, there's a real chance your guest profile can see more than you think.

4. The Lockdown Checklist: 10 Steps to Close the Front Door

Here's the practical part. Most of these steps take minutes to check, and together they address the exact weaknesses being exploited right now. Work through them in order.

1. Inventory every public-facing site. In Setup, go to All Sites and list every Experience Cloud site, Salesforce Site, and portal — including ones marked inactive or built for long-dead projects. You can't secure what you don't know exists, and attackers' scanners don't care whether you remember the site.
2. Audit each guest user profile. For every site, open the guest user profile and review object and field permissions. The standard is minimum necessary: if the portal only needs to create Cases, the guest user shouldn't be able to read Contacts, Accounts, or custom objects holding customer data.
3. Set external org-wide defaults to Private. Sharing settings for external users should start from Private, with access granted back deliberately. Public Read Only defaults for external users are exactly what this campaign feeds on.
4. Review sharing rules that grant guest access. Guest user sharing rules are the only supported way to open records to unauthenticated visitors — so each one should be individually justified. Delete any rule nobody can explain.
5. Remove API access from guest users. Salesforce's own guidance during this campaign: disable public APIs in guest user permissions unless you have a specific, current business reason. Anonymous visitors rarely need programmatic access to anything.
6. Uncheck Portal User Visibility and Site User Visibility. These sharing settings quietly widen who external users can see. Salesforce specifically flagged both in its hardening recommendations this year.
7. Disable self-registration if you don't use it. Every self-registration page is an account-creation endpoint exposed to the internet. If it isn't serving a live business process, turn it off.
8. Run Security Health Check. The free tool in Setup scores your org against Salesforce's baseline and flags high-risk settings — session security, password policies, and more. It takes two minutes to run and gives you a prioritized punch list.
9. Audit connected apps and integration users. The 2025 wave of attacks came in through third-party integrations and stolen OAuth tokens. Review every connected app, remove ones no longer in use, scope integration user permissions tightly, and enforce MFA everywhere it isn't already on.
10. Brief your team on vishing. Stolen data is being used to make phone-based social engineering frighteningly convincing. Make sure anyone with admin access knows that "IT support" calling to install a connected app or reset credentials is the attack, not the fix.

What If You Find a Problem?

If your audit turns up a guest profile with broad read access on a public site, assume the worst until proven otherwise. Tighten the configuration immediately, then check guest user activity against your logs. If data was exposed, treat it as compromised — that means heightened monitoring for phishing and extortion attempts, and a conversation with counsel about disclosure obligations in your industry. FINRA's alert made exactly this point for financial firms, and the logic applies broadly.

5. Make It a Habit, Not a Fire Drill

The orgs that came through 2026 unscathed aren't the ones that never made a configuration mistake — they're the ones with a rhythm for catching mistakes early. The simplest version: put a recurring security review on the calendar tied to Salesforce's three release cycles per year. Each release changes defaults, adds enforcements, and occasionally resurfaces old settings. Reviewing guest access, sharing defaults, connected apps, and Health Check scores three times a year turns a potential headline into a 90-minute routine.

It's also worth asking a harder question: who owns Salesforce security at your company? If the honest answer is "nobody, specifically," that's the real finding of this year's breach wave — and it's fixable without hiring anyone.

Conclusion

The 2026 breach wave is a story about configuration debt, and mid-market companies carry more of it per admin than anyone. The attacks are automated, indiscriminate, and ongoing — but every door they walk through is one a customer can close, today, with settings they already own. Work the ten-step checklist above this week, put the review on a schedule, and you'll be better protected than most of the companies in the headlines were.

Not sure what your org would show if someone scanned it tomorrow? That's exactly what our free 2-minute org health check is for — and if you want certified eyes on the full picture, our fixed-fee 5-day org audit covers guest access, sharing, connected apps, and everything else in this article. Start at 360quantumsolutions.com. Your Salesforce should be your #1 sales tool — not your biggest exposure.