shinyhunters Salesforce Breach | SalesforceTutorial

ShinyHunters Salesforce Breach: What Salesforce Confirmed

The most useful reading of this incident is configuration-focused. Salesforce said the campaign involved public-facing Experience Cloud sites where guest user access was configured too broadly. In that model, unauthenticated visitors share a site guest user profile, and that profile can become a data exposure path when object permissions, field permissions, record sharing, or API access allow more than the site requires.

Salesforce’s March 2026 security guidance describes a known threat actor campaign using a modified Aura Inspector tool to scan public Experience Cloud sites and identify exposed access paths. Salesforce also states that the activity relates to customer-configured guest user settings rather than a flaw in the core platform. Read the official Salesforce guidance here: Protecting Your Data: Essential Actions to Secure Experience Cloud Guest User Access.

Shinyhunters salesforce breach: what is confirmed and what is claimed

The phrase shinyhunters salesforce breach appears in search results because public reports and sector alerts attributed the activity to ShinyHunters. Salesforce’s own post uses the broader phrase known threat actor group. Treat claims about victim counts, company names, or exploit details as unverified unless they come from Salesforce, a regulator, or the affected organization. FINRA separately warned member firms about ShinyHunters exploiting misconfigured Salesforce Experience Cloud instances in its cybersecurity alert, which makes the risk relevant for regulated teams that store customer data in Experience Cloud-connected objects.

Salesforce breach shinyhunters september 2025: timeline questions

The search phrase salesforce breach shinyhunters september 2025 refers to public claims that scanning and data collection began months before the March 2026 Salesforce guidance. For an internal review, do not stop at March 2026 logs. If your retention period allows it, review Experience Cloud traffic, Aura events, API access, and guest user permission changes from September 2025 onward. If your org has shorter retention, preserve what you still have and document the gap.

Experience cloud news: why this matters to admins

The important experience cloud news is that guest user exposure is usually not visible from page design alone. A public page might display only a form or a small catalog, but the guest profile can still have broader backend permissions. Admins need to review the profile, sharing model, field-level security, guest user sharing rules, self-registration, and public API settings for each site.

Salesforce hack news: separate actor claims from control work

Search traffic around salesforce hack news often mixes confirmed guidance with attacker statements. In enterprise orgs, the response should be boring and evidence-based: freeze risky changes, audit every public site, remove unnecessary guest permissions, review logs, rotate exposed integrations where needed, and contact Salesforce Support if indicators point to unauthorized access.

Why shinyhunters Searches Point to Experience Cloud Guest User Risk

An Experience Cloud site can allow unauthenticated access through a site guest user. That user is a real Salesforce user record with a profile. The profile controls object permissions, field permissions, system permissions, Apex class access, Visualforce page access, and other capabilities. Record access then depends on external org-wide defaults and explicit sharing mechanisms.

Salesforce documents guest profile configuration as a per-site task, not a one-time org-level task. Review the Salesforce Help page on guest user profile best practices before changing production permissions.

For a broader security refresher, see our related guides on Salesforce security model, Salesforce sharing rules, and Salesforce Experience Cloud setup.

How to Audit Experience Cloud Guest User Access

Run the audit in a sandbox first when possible, then repeat the read-only review in production. The goal is not to remove every guest capability; it is to prove that each remaining permission supports a public use case.

Step 1: Inventory every public site

1. Open Setup.
2. Go to Digital Experiences or All Sites, depending on your org navigation.
3. Open each active site, including older sites that no team currently owns.
4. Record the site name, domain, template, owner, guest user profile, self-registration status, and business owner.

Step 2: Review the guest user profile

From the site settings, open the Guest User Profile. Remove object access that does not support a public page. Pay extra attention to objects that contain personal, support, commercial, or authentication-adjacent data. If a page only needs to create a lead, the guest profile should not also read existing Lead or Contact records.

Salesforce’s guidance says to start from least privilege. In practice, that means you should disable broad permissions, test the site journey, and restore only the precise access that the journey needs.

Step 3: Confirm external org-wide defaults and secure guest record access

Open Setup > Sharing Settings. For external access, set organization-wide defaults to Private wherever the data is not intended for all external users. Salesforce Help documents Secure Guest User Sharing Settings and Record Access, including the secure guest user record access control.

Remember that sharing rules open access; they do not make access stricter. If the default is too broad, a sharing rule cannot repair that baseline. Trailhead’s Data Security module is a useful review for admins who need to explain object, field, and record access to stakeholders.

Step 4: Disable public API access unless reviewed

In site settings, turn off Allow guest users to access public APIs unless a named application owner can defend the need. In the guest user profile, remove API Enabled unless Salesforce Support or an approved architecture decision says otherwise. This control matters because a public Experience Cloud page can expose backend access beyond what the visible page suggests.

Step 5: Restrict user visibility and profile discovery

In Sharing Settings, review Portal User Visibility and Site User Visibility. Salesforce Help explains how Experience Cloud user visibility controls affect which users site users can see: Control Which Users Experience Cloud Site Users Can See. For public sites, the safer default is to avoid exposing internal users, profiles, names, and user metadata unless a reviewed use case requires it.

Step 6: Review self-registration and registration handlers

Open Workspaces > Administration > Login & Registration. If the site does not need anonymous visitors to create accounts, remove the self-registration page assignment. If it does need registration, inspect the Apex registration handler. It should assign a restrictive profile, avoid copying sensitive guest-visible fields into the new account, and require verification before any broader access becomes available.

Step 7: Query setup permissions for a second review

The following Execute Anonymous script gives admins a quick read-only snapshot of object access assigned through guest-profile permission set parents. It is not a replacement for Setup review, but it helps find permissions that are easy to miss in the UI. Run it as an admin in a sandbox first.

List<PermissionSet> guestParents = [
    SELECT Id, Name, Profile.Name
    FROM PermissionSet
    WHERE Profile.Name LIKE '%Guest%'
    LIMIT 200
];

Set<Id> parentIds = new Map<Id, PermissionSet>(guestParents).keySet();

System.debug('Guest permission parent count: ' + parentIds.size());

for (ObjectPermissions perm : [
    SELECT ParentId, SObjectType,
           PermissionsRead, PermissionsCreate, PermissionsEdit,
           PermissionsDelete, PermissionsViewAllRecords, PermissionsModifyAllRecords
    FROM ObjectPermissions
    WHERE ParentId IN :parentIds
    AND (
        PermissionsRead = true OR PermissionsCreate = true OR
        PermissionsEdit = true OR PermissionsDelete = true OR
        PermissionsViewAllRecords = true OR PermissionsModifyAllRecords = true
    )
    ORDER BY SObjectType
    LIMIT 2000
]) {
    System.debug(
        perm.SObjectType +
        ' read=' + perm.PermissionsRead +
        ' create=' + perm.PermissionsCreate +
        ' edit=' + perm.PermissionsEdit +
        ' delete=' + perm.PermissionsDelete +
        ' viewAll=' + perm.PermissionsViewAllRecords +
        ' modifyAll=' + perm.PermissionsModifyAllRecords
    );
}

Governor limit note: this script uses two SOQL queries and no DML. It limits returned rows because setup-heavy orgs can have many permissions. If your guest profile names do not contain the word Guest, change the profile filter to the exact profile names from All Sites.

How Developers Should Secure Guest-Facing Apex

Guest profile cleanup is only part of the work. Developers also need to review Apex controllers, Aura-enabled methods, custom REST endpoints, Flows, and Visualforce pages that the public site can reach. A secure page should not rely on obscurity, URL structure, or the assumption that users only click visible buttons.

Use user-mode SOQL for guest-readable data

Salesforce Developer Docs recommend user-mode operations for enforcing object and field permissions in Apex queries where appropriate. See Secure Apex Classes and Set an Access Mode for Database Operations.

public with sharing class PublicFaqController {
    public class PublicFaqDto {
        @AuraEnabled public Id id;
        @AuraEnabled public String question;
        @AuraEnabled public String answer;

        public PublicFaqDto(Public_FAQ__c record) {
            id = record.Id;
            question = record.Name;
            answer = record.Answer__c;
        }
    }

    @AuraEnabled(cacheable=true)
    public static List<PublicFaqDto> findPublishedFaqs(String searchText) {
        String trimmed = String.isBlank(searchText) ? '' : searchText.trim();
        String pattern = '%' + trimmed + '%';

        List<Public_FAQ__c> rows = [
            SELECT Id, Name, Answer__c
            FROM Public_FAQ__c
            WHERE Published__c = true
            AND Name LIKE :pattern
            WITH USER_MODE
            ORDER BY Name ASC
            LIMIT 50
        ];

        List<PublicFaqDto> results = new List<PublicFaqDto>();
        for (Public_FAQ__c row : rows) {
            results.add(new PublicFaqDto(row));
        }
        return results;
    }
}

This example uses with sharing, a selective query, a LIMIT, bind variables, and WITH USER_MODE. The method returns a DTO instead of the raw sObject so the component receives only the fields intended for the page. It also avoids dynamic SOQL, which reduces injection risk. If your use case needs optional fields to be removed rather than throwing an exception, review Security.stripInaccessible() in the official Apex security docs.

Do not expose broad Apex methods to anonymous users

• Do not return Account, Contact, Lead, Case, User, or custom object records unless those records are intended for public access.
• Do not use without sharing on guest-facing controllers unless a security architect approves the exact reason.
• Do not accept object names, field names, or raw WHERE clauses from the browser.
• Do not use guest user access to work around missing sharing design.
• Do not trust client-side checks in LWC or Aura as security controls.

For more developer patterns, see our internal guides on Apex security in Salesforce and SOQL query examples.

What to Do Now if Your Org Matches the Risk Pattern

If your org has public Experience Cloud sites, run this checklist even if you have not seen an alert. The shinyhunters discussion is a reminder that internet-facing Salesforce configuration needs recurring review.

Immediate containment checklist

1. Identify public sites: include active, inactive, legacy, sandbox-preview, and branded domains.
2. Export current settings: capture guest profile permissions, sharing rules, site settings, and registration settings before changing them.
3. Disable unneeded public API access: remove guest API capabilities unless an approved public integration requires them.
4. Remove broad object permissions: prioritize Contact, Lead, Case, User, Order, Asset, Contract, and custom objects containing personal or regulated data.
5. Set external defaults to Private: use narrow sharing rules for public records that must remain visible.
6. Review field-level security: remove guest access to phone, email, address, notes, identifiers, tokens, and internal status fields unless required.
7. Check self-registration: disable it or confirm the handler assigns the lowest-access profile and uses verification.
8. Review logs: check Aura events, API usage, site traffic, setup audit trail, and unusual access patterns.
9. Escalate evidence: contact Salesforce Support and your internal incident response team if logs show access to non-public data.

Evidence to collect for security and legal teams

Common errors with Experience Cloud hardening

Testing only as an admin: Admin testing hides guest access gaps. Use the actual site guest context and a low-permission external test user.

Fixing the visible page but not the profile: Removing a component from a page does not remove backend object access. Review profile permissions directly.

Leaving custom Apex untouched: A guest-facing Apex method can still expose data after profile cleanup if it runs in system context or returns broad data.

Ignoring old sites: Legacy Experience Cloud and Salesforce Sites implementations often remain reachable after teams move to a new portal.

Best Practices for Long-Term Experience Cloud Security

In enterprise orgs, guest user access should go through the same governance as integrations. Assign an owner, document the data contract, and review access after every release that changes objects, fields, flows, Apex, or page composition.

• Create a public data allowlist: maintain a short list of objects and fields approved for anonymous access.
• Use separate public objects where possible: publish sanitized records to a public object instead of exposing operational CRM records.
• Separate guest and authenticated journeys: avoid designs where anonymous users can see data that later becomes account-specific after login.
• Review metadata in CI/CD: flag guest profile changes, Apex class access, public API settings, and sharing changes before deployment.
• Monitor continuously: add alerting for spikes in guest requests, unexpected object access, and changes to guest profiles.
• Document exceptions: every guest permission should map to a page, component, API, owner, and expiry review date.

ShinyHunters may be the search term that brings teams to this issue, but the control work is standard Salesforce security hygiene: least privilege, private defaults, narrow sharing, secure Apex, and evidence-based monitoring.

Frequently Asked Questions