Misconfigured guest permissions in Experience Cloud risk your data

Salesforce recently warned about an increase in malicious activity that targets public sites built with Experience Cloud. The technique described does not exploit a service failure itself, but rather too permissive configurations in the guest user profile that many organizations maintain to publish public pages - and that, if not properly adjusted, can allow attackers to obtain information that should not be open to the public.

At the center of the news is a modified version of an open source tool called AuraInspector, developed to audit configurations within the Aura framework of Salesforce. The original tool, launched by Mandiant, serves to identify objects and points exposed by public endpoints such as / s / sfsites / aura. The worrying thing is that, according to Salesforce, malicious actors adapted that utility to automate mass sweep and move from mere detection to data extraction when too laxa configurations are found.

This means that it is not a "vulnerability" on the per se platform, but configurations that allow non-authenticated users to consult on CRM objects. Salesforce has been explicit in pointing out that, so far, they have not detected a system-inherent failure: attempts are directed at adjustments of customers who do not follow the safety recommendations published by the company itself. The official statement and indications can be read on the Salesforce blog and in your public notice on the matter Here. and on your status page Here..

To understand mechanics: Experience Cloud's public sites use a special "guest user" profile to show public content such as help entries, FAQs or landing pages. That profile must have strictly limited permits. If read or access to public APIs are mistakenly granted to this profile, an automated scanner could list objects and even extract fields with sensitive data without authentication.

The practical risk is not only the immediate exfiltration of names or phones; Salesforce warns that such information may be the raw material of subsequent attacks. Apparently harmless data serve to refine social engineering campaigns and voice attacks (vishing), which are often more effective when the attacker already has verifiable details about employees or customers. In this sense, the reported activity fits what the company qualifies as a broader pattern of "identity-based" attacks.

Salesforce has recommended several mitigation measures that any administrator should review immediately: restricting the access of the guest user, establishing the default visibility of the objects in private, disabling public access to APIs from guest profiles and controlling self-registration if not strictly necessary. The company has published guides with concrete steps to audit and strengthen these configurations in their resources.

The original tool on which these attacks are based was published by Mandiant; the existence of a modified version by malicious actors shows how the utilities designed to improve safety can also be reused for offensive purposes if they fall into the wrong hands. Those who want to review the public tool can consult the official repository and the publication notes by Mandiant in GitHub and on Mandiant's website Here..

Salesforce attributes the campaign to a group of known threats without expressly naming it, opening up the possibility of relationship with operations that have already directed previous attacks on CRM ecosystems through third-party applications. In any case, the message for managers and security officials is clear: review access policies, monitor unusual consultations and apply the principle of minimum privileges on all publicly exposed profiles.

For technical and security equipment that need to prioritize actions, it is not necessary to wait for an intrusion to react. An audit of guest profile permissions, the deactivation of public APIs for that profile and the revision of access loops are often high-impact technical measures. In addition to following Salesforce's recommendations, it is appropriate to integrate specific alerts into detection systems to capture mass scanning patterns or consultations that attempt to list CRM objects.

In short, this incident is a reminder that security is not only a matter of patches and vendor updates: it also depends on local policies and configurations. Automated tools can help identify weaknesses, but they can also be reused by adversaries, "so a careful configuration and constant monitoring remain the best barriers to such campaigns.