In Short
The Salesforce advisory checklist is not exhaustive. It focuses on configuration management rather than auditing distinct control layers such as sharing rules. As a result, guest profiles can appear fully locked down while unauthenticated users still access Contact and other CRM records. This gap is most reliably identified using external auditing tools such as Mandiant's open-source AuraInspector.
Many affected environments lack native visibility into this attack vector due to licensing requirements. Aura Event Monitoring logs require a separate Salesforce Shield or Event Monitoring license, which mid-market organizations routinely lack. License status must be confirmed before assuming any log visibility.
Self-registration introduces an underappreciated escalation path. Data harvested at the guest tier can be used to create credentialed accounts with far broader access unless all three conditions are met simultaneously: a sharing-enforced registration handler, assignment of the most restrictive profile, and mandatory email verification.
Remediation is not a one-time checklist exercise. Organizations should integrate external scans into change-management processes that affect guest access or sharing logic, establish quarterly joint admin-security audits, and formally document any remaining detection gaps as accepted risks.
Security In Practice | CyOps Consulting Team
Following Salesforce's published advisory is not the same as being protected. ShinyHunters, an extortion group with a documented history of targeting Salesforce environments, has claimed breaches of several hundred organizations since September 2025, including approximately 100 high-profile companies (BleepingComputer 2026; The Register 2026). The attack requires no stolen credentials: a misconfigured guest user profile on a Salesforce Experience Cloud (formerly Community Cloud) site is sufficient for an attacker to query Customer Relationship Management (CRM) objects without authentication (Salesforce 2026; Help Net Security 2026).
The campaign is ongoing. Confirmed victims include Loblaw, which disclosed a breach on March 10, 2026, and Infinite Campus, which notified customers on March 24 (Salesforce Ben 2026; BleepingComputer 2026). Many affected organizations followed the advisory. The evidence suggests many may remain exposed.
Flawed Thinking
The prevailing assumption among organizations that responded to the advisory runs as follows: disable API access on the guest profile, set org-wide defaults to Private for external users, turn off self-registration where it is not needed, and the exposure is closed. That assumption does not hold.
Salesforce's permission model does not work this way. Access to data is controlled across five distinct layers: profiles, permission sets, sharing rules, org-wide defaults, and field-level security (Salesforce 2026; Mandiant 2026). Each layer can grant or restrict access independently of the others. Exposure may exist wherever those layers conflict, not only where an administrator made an obvious mistake. Locking down one layer does not close the exposure if a subordinate layer contradicts it.
The concrete illustration: a guest profile can show no dangerous object permissions at all, with every advisory checklist item marked complete. At the same time, a sharing rule independently grants guest users access to Contact records. That rule sits on a separate layer and requires a separate audit step. The advisory checklist does not include that step (Salesforce 2026). The profile is clean. The exposure is not.
This is not primarily a failure of individual administrators. The advisory reflects the same orientation that administrators were trained to apply enabling functionality—not auditing it from the vantage point of an unauthenticated external user. Completing a checklist designed for configuration management does not produce a verified remediation. It produces a completed checklist.
The question that closes the risk is different: can an unauthenticated user reach data you did not intend to expose, tested from outside your organization right now?
Three Failure Modes the Checklist Doesn't Catch
The layered structure described above creates three operational failure modes where the advisory checklist falls short. Each is a distinct mechanism; each persists for a reason; and each maps to a corrective action.
The Audit Scope Is Too Narrow
Most organizations audited their guest profile's object permissions, confirmed those permissions were restricted, and marked the remediation task complete. That is exactly what the advisory checklist asked them to do. It is also why many could remain exposed.
The advisory is sequenced for Salesforce administrators, not for security testing. It instructs teams to review the guest user profile's object permissions and confirm that org-wide defaults are set to Private for external users (Salesforce 2026). It does not instruct teams to audit sharing rules as a separate control layer because sharing rules require a different vantage point entirely.
The consequence is precise. A sharing rule granting guest users access to Contact records operates independently of the guest profile's object permissions. An administrator who restricts the profile and confirms org-wide defaults has followed the checklist correctly. The sharing rule remains active. Contact records remain reachable by unauthenticated users. Nothing in a standard administrative review surfaces this gap. The profile is clean on paper; the exposure is open in practice (Mandiant 2026).
What most current coverage misses is the verification step that closes this gap. AuraInspector, the open-source audit tool released by Mandiant (Google Cloud) in January 2026, was built for exactly this purpose: it queries the Aura endpoint without authentication and returns which objects and records are reachable from an unauthenticated external position (Mandiant 2026; Help Net Security 2026). Running it against your own instance from outside the organization is a same-day, zero-cost action. It is the only method that confirms whether the actual exposure surface matches the assumed one. The step has not been widely executed in the affected population.
The Detection Capability Is Near Zero for Most Affected Environments
Salesforce's advisory instructs organizations to review their Aura Event Monitoring logs for anomalous guest activity: object queries targeting records not intended to be public, unexpected volume spikes from unfamiliar IP addresses, and access outside normal business hours (Salesforce 2026). For a significant portion of the affected population, this guidance cannot be acted on. The logs do not exist.
Accessing those logs requires a Salesforce Shield subscription or a separately purchased Event Monitoring add-on (Salesforce n.d.). It is routinely deprioritized in license negotiations, particularly in mid-market environments. Security teams outside large enterprise deployments typically do not know this gap exists until an incident forces them to look (Help Net Security 2026).
In a documented 2025 incident, attackers moved from initial access to data extraction in under 60 seconds (The Hacker News 2026). For an organization without Event Monitoring enabled, post-incident forensics has no log data from which to determine scope of exposure, identify affected records, or establish extraction volume. Breach notification timelines extend as a direct result. Regulatory exposure increases in parallel.
The prerequisite that makes log review viable is also consistently absent. Confirming whether Event Monitoring is licensed and enabled in your environment should be the first step in any post-advisory response, not an assumed baseline. For teams that have not done this check, their detection posture for this attack vector is blind, regardless of what the advisory checklist records.
The Self-Registration Escalation Path Is Underappreciated
Most post-incident coverage treats guest-tier data theft as the terminal event of this campaign. In configurations where self-registration is enabled, it is frequently an intermediate step.
An attacker who extracts names and email addresses via an unauthenticated guest endpoint can, in many configurations, use that harvested data to create a credentialed portal account within minutes. The scope of data accessible at the authenticated tier is substantially broader than at the guest tier. The advisory's binary instruction, "disable self-registration if not required," may not fully account for organizations for whom it is a legitimate operational requirement (Salesforce 2026).
For those organizations, three conditions must hold simultaneously. Those conditions appear in the advisory (Salesforce 2026). What the advisory does not do is prompt teams to verify all three at once or make clear that failing any single condition creates the escalation pathway even when the other two are correctly configured.
One mandatory scope qualification: this failure mode applies only to a specific configuration intersection. Not all Experience Cloud sites with self-registration enabled are exposed to this escalation path, and organizations that have disabled self-registration entirely are not affected by this mechanism. The risk is real and underrepresented in current coverage, but it is not universal.
Each failure mode above is correctable with actions that can be taken this week.
Tactical Adjustments
Immediate Actions
Run AuraInspector against your own Salesforce instance from outside your organization, without authenticating (Mandiant 2026; Help Net Security 2026). Running it yourself answers the question your internal configuration review cannot: does what an unauthenticated visitor can actually reach match what you believed they could reach? The test takes a single day and costs nothing. If your security team cannot execute it today, that inability is the correct trigger for escalating to them now, not after the next internal review cycle.
Before treating log review as a detection control, confirm whether Event Monitoring is licensed and enabled in your org. Event Monitoring requires a Salesforce Shield or Event Monitoring add-on license, purchased separately from your base Salesforce contract (Salesforce n.d.). If that license is not in place, your detection capability for this attack vector may be significantly compromised or non-existent. State that plainly, internally, now. The immediate action is not to purchase the license; that is a near-term budget decision. The immediate action is to confirm your current status and stop counting an absent control as an active one.
Audit your sharing rules as a distinct step, separate from your guest profile review. As Mandiant notes, sharing rules can be configured at multiple levels in Salesforce, which complicates misconfiguration identification. They operate on a separate control layer from the object permissions set in the guest profile. Review specifically for any rule that explicitly extends object or record access to guest users. No additional tooling is required. What is required is a deliberate scope extension that the advisory checklist does not prompt (Salesforce 2026).
Near Term
If self-registration is enabled on any of your Experience Cloud sites, map the escalation path it opens. Three conditions must hold simultaneously for self-registration not to become a risk:
The registration handler runs with sharing enforced.
The most restrictive available profile is assigned at the point of registration.
Email verification is required before account activation.
Validate all three conditions together, as the combination is commonly missed. This is a configuration review task, not a development task. It requires a Salesforce administrator and a security engineer working from the same audit scope; neither can close this review reliably alone.
For organizations processing customer personally identifiable information (PII) or financial data through Experience Cloud, evaluate whether the cost of an Event Monitoring license is proportionate to the sensitivity of what your site exposes (Salesforce 2026). This is a risk-proportionate decision with a specific trigger condition, not a universal recommendation. If your Experience Cloud site surfaces PII or financial records to any user tier, the detection gap this license closes is material. Mid-market organizations commonly deprioritized this license in procurement, and the budget barrier is real. Revisiting that decision in the context of an active campaign is operationally justified.
Structural Shifts
Build external verification into your Salesforce change management process. The trigger condition is specific: any configuration change that touches guest profiles, sharing rules, or self-registration handlers should require a post-change external scan as a defined, required step before the change is closed (Mandiant 2026). This is a process change. It requires your Salesforce administration team and your security team to agree, in writing, on what constitutes a triggering change, and to embed that requirement into your existing change management procedure.
Establish a joint review cadence for Experience Cloud sites between the Salesforce administration team and the security team. A full audit requires cross-functional expertise: the administrator understands the configuration model; the security engineer understands what exposure looks like from the outside (Mandiant 2026; Salesforce 2026). Neither can conduct the full audit reliably alone. A quarterly review using a shared checklist that includes an external verification run is a defensible baseline. In some mid-market organizations, these two teams rarely work together on Salesforce configuration. Building that working relationship has a real coordination cost. Plan for it explicitly.
Organizations without Salesforce Shield have a detection gap they cannot close with configuration changes alone. This must be documented as a known, accepted risk, with a formal decision recorded in writing. An undocumented known risk is a governance failure, not a resource constraint.
Decision Framework
The evaluation test is one question: "Can we demonstrate that an unauthenticated user cannot reach data we did not intend to expose?" If answering it requires more than a ten-minute external verification run to establish, the risk is not closed. That is not a high bar. It is the minimum one.
Salesforce is not a cloud service secured once. It is a layered permission model that requires continuous audit. The March 7 advisory specified which settings to check (Salesforce 2026). That scope boundary is the accountability gap security leads need to name in board and audit committee reporting. A checklist you cannot verify externally is a risk you have accepted, not a risk you have closed.
The configuration model in Experience Cloud has multiple control layers that interact in ways the advisory does not fully address. Your guest profile can be clean. Your sharing rules may not be.
Forward Risk Signal
ShinyHunters' targeting of Salesforce infrastructure predates this campaign. Prior operations in August and November 2025 exploited OAuth tokens from Salesloft's Drift integration and Gainsight-connected apps before pivoting to guest user misconfigurations (BleepingComputer 2026). This is a sustained, focused pattern against a single platform, not opportunistic scanning. The campaign will continue until the attack surface is closed or the group shifts focus.
Salesforce updated its advisory on March 11, 2026, after identifying exposure paths not covered in the March 7 version (Salesforce 2026). That revision signals the vendor's understanding of the attack surface was still developing two weeks into public disclosure. Treat the current advisory as a minimum baseline, not a complete specification of the risk.
Watch three signals: further victim claims, particularly those identifying new verticals or attack path variations; additional advisory revisions from Salesforce; and any new public AuraInspector variants following the January 2026 weaponization (Mandiant 2026; BleepingComputer 2026). Security prioritisation tracks incident cadence. That cadence is currently high.
Special thanks to Coursera for supporting today’s content.
Brought to by the CyOps Consulting Team.
