Salesforce Guest User Enumeration: How Attackers Pull 45M Records ShinyHunters-Style

# Salesforce guest user enumeration: how attackers pull 45M records ShinyHunters-style

McGraw-Hill's April 2026 breach exposed 45 million Salesforce records. ShinyHunters claimed responsibility and the technical mechanism is now widely discussed in threat-intelligence channels: Salesforce Experience Cloud guest-user access misconfiguration. Same pattern that hit AT&T, Ticketmaster, Santander, and multiple F500 companies across 2023-2025. Same pattern that will continue to work in 2026 because the default Salesforce configuration makes it easy to misconfigure and hard to detect until the data is already out the door.

This post walks through the technical anatomy of the attack, what it costs an attacker in time (surprisingly low), what the defender signals look like (uncomfortably subtle), and the audit approach we use when a client asks us to verify their Salesforce org is not already leaking.

#The guest user attack pattern

Salesforce Experience Cloud (formerly Community Cloud) lets you publish a branded customer portal that external users can access. A portal can be fully public (no login) or require authentication. When a portal is public, requests hit Salesforce as an unauthenticated "Guest User." Salesforce exposes an internal, automatically-created guest user identity per Experience Cloud site with its own profile, permission set, and sharing rules.

The attack pattern exploits misconfigurations in what that guest user can see:

1. Attacker identifies a target's Experience Cloud site. Usually a customer portal, community forum, or public-facing knowledge base. These are easy to enumerate: Salesforce hosts them at *.force.com or a custom domain like community.company.com.

1. Attacker triggers an unauthenticated REST API call against the site. Experience Cloud sites expose a JSON API at /services/data/vXX.X/. The guest user's credentials are implicit in the session cookie.

1. Attacker enumerates objects the guest user can read. Most orgs only audit the obvious objects (Contact, Account, Case). They forget to review custom objects, especially ones named CustomerProfile__c, OrderHistory__c, MembershipDetail__c. These commonly hold PII.

1. Attacker pulls data via REST pagination. No rate limiting on the read API for guest users in default configurations. Millions of records are a few thousand paginated requests away.

The entire chain can run from a single laptop over residential internet in under 48 hours for a target the size of McGraw-Hill.

#The specific misconfigurations that enable it

Every confirmed ShinyHunters Salesforce incident we've studied matches at least one of these five misconfigurations:

#1. Public objects on the guest user profile

Guest user profile has "Read" permission on an object whose records contain PII. The misconfiguration isn't that the object is shared publicly — it's that the org never did a "does this object belong on the guest profile at all" review.

How to find it: Setup → Profiles → Guest Profile for [Site Name] → Object Settings → scroll every object flagged "Visible." Anything that is not explicitly part of the public-facing experience is a finding.

#2. "Grant Access Using Hierarchies" left on for sensitive sharing rules

When a public sharing rule is defined ("give Guest Users read access to Knowledge Articles where Category = Public"), Salesforce by default also grants the access to records rolled up via the role hierarchy. This is an opt-out control in the UI. Most admins miss it.

#3. API access enabled on guest profile

Salesforce Summer '21 release tried to tighten this by requiring admins to explicitly enable API access for guest users. Problem: the "Enable API Access" setting defaults ON for any guest profile created before the release, and many orgs inherited that setting when they migrated to the "Secure Guest User" framework.

How to find it: Setup → Profiles → Guest Profile → Administrative Permissions → look for "API Enabled."

#4. Custom Aura components leaking data via Lightning endpoints

Experience Cloud pages that use custom Aura components expose Lightning component methods at /aura?.... If any of those methods call out to Apex with no permission check, and Apex runs in "without sharing" mode, the guest user just called a method that bypasses CRUD and sharing enforcement entirely.

How to find it: All Apex that can be invoked from an Experience Cloud page should be audited for the with sharing keyword. Any method that explicitly runs without sharing is a finding unless a reviewer can explain why.

#5. Shared records via related lists on public detail pages

The subtle one. An Experience Cloud page displays a public record (say, a support Knowledge Article). That page has a related list (say, "Cases" that referenced the article). The related list displays case data. Case data includes customer names, case descriptions, and sometimes PII in the case detail. The admin never realized the related list was rendering data the guest user wasn't supposed to see, because the related list got added through a page-layout change two years ago.

How to find it: Load every Experience Cloud page as the Guest User and inspect the page's full HTML/DOM for data that should not be there.

#The defender signals

#What you would see if you were under active exfiltration

1. Increased REST API call volume from the guest user identity. Salesforce Setup → System Overview → API Usage. Normal guest traffic is human pageviews. A 1000x spike over a 24-hour period is an attack.
2. Event Monitoring logs showing paginated reads against PII objects. Requires Event Monitoring license (Enterprise+). Without it, you cannot see this.
3. Unusual user-agent patterns. Guest user REST calls from Python's requests library instead of a browser are a red flag.

#What you would miss without the right configuration

Most organizations without Event Monitoring cannot detect this class of attack in progress. Salesforce's default audit logs only cover configuration changes, not data reads. Without Event Monitoring, you learn about the breach from the attacker or from a victim notification.

#Our Salesforce Experience Cloud audit

When we audit a Salesforce org for this pattern, the checklist is:

1. Enumerate every Experience Cloud site. Every one gets its own guest user profile.
2. Pull the guest user profile configuration. Field permissions, object permissions, tab visibility, system permissions, API access flag.
3. Enumerate public sharing rules. Every rule touching a guest user profile gets reviewed against "what data does this expose and is that intentional."
4. Fetch every Apex class reachable via Experience Cloud. Review for without sharing, CRUD/FLS bypass, DML in read-only contexts.
5. Run as the guest user against every Experience Cloud page. What objects return data? What fields? What record counts?
6. Test REST + SOQL API directly as guest user. Enumerate objects via /services/data/vXX.X/sobjects. Read each. Count records.
7. Review Event Monitoring setup. Is it licensed and enabled? Are anomalies going anywhere?
8. Verify IP restrictions on guest profile. Optional but strong control.

Typical Valtik engagement finds 2-5 issues. At least one is usually an object exposing PII to the guest user. The McGraw-Hill breach was the public version of this finding; we find private versions weekly.

#Specific fixes we recommend post-finding

• Lock down the guest user profile to the absolute minimum. Review every checked box. Most orgs can safely remove 80% of guest-user object access without breaking any public functionality.
• Disable API access for guest users. If your Experience Cloud site doesn't need programmatic API access from unauthenticated clients (most don't), turn off the API Enabled permission.
• Audit all Apex controllers exposed to Experience Cloud. Enforce with sharing unless there's a written justification for without sharing.
• Turn on Event Monitoring if you're on Enterprise Edition or above. Route anomalies to your SIEM or a simple Slack channel.
• Run the audit annually at minimum. Salesforce orgs grow. Every new custom object, every new permission set, every new Experience Cloud page is a potential new surface.

#The broader pattern

Salesforce is the highest-value enterprise SaaS target in 2026. It stores customer PII for hundreds of thousands of orgs. The guest-user attack is particularly attractive to extortion groups because:

• No authentication means no credential stuffing or phishing step required
• No login means no MFA to defeat
• Read-only access avoids the detection tripwires that come with write operations
• Pagination over REST is slow but steady, and doesn't require sophisticated tooling
• ShinyHunters have publicly documented the exact playbook, lowering the bar for copycats

Expect continued breaches of this shape throughout 2026. If your org runs Salesforce Experience Cloud and you haven't audited the guest user configuration in the last 12 months, you're overdue.

#What Valtik can help with

Salesforce Experience Cloud guest user audit: fixed-price $3,500. Takes roughly 5 business days from kickoff to final report. Includes the full checklist above, exploit-validated findings, and fix-ranked remediation.

Contact: hello@valtikstudios.com

Request a quote: /contact

Related reading:

• April 2026 breach wave: Vercel, McGraw-Hill, Adobe, Rockstar, Drift Protocol
• SaaS vendor security audit checklist

#Sources

1. Salesforce: Securing Experience Cloud Sites
2. Salesforce: Guest User Access and Experience Cloud
3. OWASP API Security Top 10
4. SharkStriker, April 2026 breach roundup