Salesforce Industry Cloud riddled with configuration risks

Salesforce Industry Cloud customers can easily misconfigure their deployments to enable attackers to access encrypted customer information, session data, credentials, and business logic, security researchers have found.

The Salesforce Industry Cloud suite of vertical-aligned solutions includes a low-code platform that provides pre-built digital transformations tools for specific industries, such as financial services and manufacturing.

Aimed at non-developers, low-code tools can allow “non-technical users to build logic that touches critical systems and sensitive customer and internal data,” said Aaron Costello, chief of SaaS security research at AppOmni, in a report that identified 20 misconfiguration risks associated with Salesforce Industry Cloud’s OmniStudio low-code offering.

“But this empowerment can come at a cost with respect to security, drastically increasing the risk of misconfigurations by customers,” Costello noted. “This combination of flexibility and implicit trust means that a customer misconfiguring one component, or overlooking one setting, can lead to system-wide data exposure.”

Among the risks identified by Costello and AppOmni were:

• Low-code components that do not enforce access control checks or respect encrypted data fields by default
• Workflow code that is executable by external or unauthenticated users
• Caching mechanisms that can lead to bypassed access controls
• Poorly developed off-platform applications that can result in API token theft
• Sensitive API keys and other data embedded directly into components that can be read without permissions
• Insecure permissions on saved workflows

Of the 20 misconfiguration risks identified by AppOmni, Salesforce has issued CVEs and guidance to prevent five. The rest have been left to customers to avoid.

Salesforce issues five CVEs

The five CVEs Salesforce issued involve problems discovered in OmniStudio’s FlexCards and Data Mappers components. Salesforce notified customers on May 19 about the issues.

FlexCards, which fetch data from Salesforce and third-party sources for use in workflows or for display in customer-facing web views, accounted for four of the CVEs:

• CVE-2025-43698: The SOQL data source ignores field-level security (FLS), exposing all field data for records.
• CVE-2025-43699: The “Required Permissions” field can be bypassed due to the check being performed client-side.
• CVE-2025-43700: The “View Encrypted Data” permission is not enforced, returning plaintext values for data that uses Classic Encryption to unauthorized users.
• CVE-2025-43701: Allows Guest Users to access values for Custom Settings.

Data Mappers is a feature available as an option for FlexCards datasources or as an action as part of back-end Integration Procedures (IProcs) for server-side data processing. Data Mappers read and transform data into formats suitable for use in APIs or Salesforce objects.

Costello found that two of the four Data Mapper types — Extract and Turbo Extract — do not enforce FLS by default and return plaintext data of encrypted values to users without permissions to see them. Salesforce assigned CVE-2025-43697 to this issue.

Additional configuration risks

Fifteen other configuration patterns can also have serious security implications for Salesforce Industry Cloud customers.

For example, Data Mappers and IProc metadata are cached using a mechanism known as Scale Cache to speed up execution in the future. While users need Sharing Rules configured in order to execute Data Mappers or IProcs, Costello found that once they’re cached, these components become executable by any user regardless of permissions.

“Unfortunately there is no configuration setting that allows for the use of the Scale Cache while also respecting Data Mapper security controls,” Costello said. “After thorough testing, including the enablement of the CheckCachedMetadataRecordSecurity OmniStudio setting, it was revealed that the only way to enforce authorization checks for Data Mappers is to turn the Scale Cache off completely.”

Integration Procedures also don’t respect the “Required Permission” setting nor the Sharing Rules of any Data Mapper or other IProc they call as part of their actions. This behavior is documented by Salesforce but is extremely risky, because users only need to satisfy the access control of the initial IProc to call any Data Mapper or IProc involved in its process flow.

“Organizations may have widely accessible IProcs that call upon powerful actions under the misconception that the permission requirements of all of an IProc’s actions will be evaluated for the calling user,” Costello said.

Another common configuration risk involves HTTP actions commonly used as part of IProcs to communicate with external APIs. If those APIs require authentication, organizations might decide to hardcode usernames and passwords or API access tokens directly into the body of the IProc. Anyone who can execute an IProc can also see the hardcoded values stored within. In many cases, this includes external users or even guest users who can execute IProcs in debug mode.

FlexCards and IProcs support a data source type called Remote Actions that allows the execution of Apex classes. Apex is Salesforce’s Java-like object-oriented language for building applications on its platform.

When an OmniStudio component attempts to execute an Apex class through Remote Actions, the request is proxied through the BusinessProcessDisplayController Apex class, which includes a GenericInvoke2NoCont method. This method does not validate whether the calling user has permission to access the Remote Action.

“This results in an authorization bypass which may allow for both internal and external users to execute powerful Apex code that runs without sharing or does not implement security measures such as FLS,” Costello said, adding that this is the default behavior.

Another feature that can generate sensitive information exposure is Data Packs, which can export and import components to other Salesforce instances. This feature leaves artefacts in the form of JSON definition files that can contain dependent objects such as IProcs that further contain Data Mappers.

“A user with read access rights to this object and excessively broad Sharing Rules will have the ability to download the Data Pack component JSON files that are stored within the ‘Attachment’ sObject,” Costello said. “Notably, since these attachments solely rely on access checks on the OmniDataPack’s ‘Id’ field, users do not need any field-level permissions on the ‘OmniDataPack’ sObject to access these files, only permissions at the object and Sharing Rule level.”

Data Packs can also become orphaned, for example, if the user creating them presses the cancel button during the process. In this case, their attachments get created and never removed. Worse, they are not listed on the Data Packs inventory page in OmniStudio, making it harder for admins to detect them.

When embedded in an external website, FlexCard or OmniScript components need an access token to access Salesforce. These tokens must be created using an OmniOut app. However, a website’s end-user can inspect the API requests locally in their browsers and extract this token, which can then be misused. Costello recommends that companies use a proxy for communication between external OmniStudio components and Salesforce.

A proxy, however, won’t help when the token itself is embedded in OmniOut code that has been compromised or stored in public version control systems like GitHub. Furthermore, a proxy could introduce risks if it’s poorly configured to forward requests without validation, as users could attempt to tamper with parameters and values.

“Since OmniOut typically relies on authenticated Salesforce APIs, this account requirement is satisfied by providing the OmniOut component with a Connected App access token which will be used to make requests on behalf of all external users,” the researcher noted. “While not explicitly stated in the Salesforce documentation that details the Connected App creation process, it’s imperative that organizations do not generate an access token for OmniOut that is tied to a privileged account such as System Administrator.”

Finally, OmniScripts, which tie together multiple back-end operations through IProcs, Data Mappers, and FlexCards, have a feature called Saved Session that allows users to save their progress and return to the script later. When such sessions are generated, a record is created in the OmniScript Saved Session sObject along with any data entered or returned by the script until being saved. By default there is no expiration time for these saved sessions.

“Although Guest and/or Community Site users do not have the ability to save their own sessions, it does not prevent them reading the data of other user sessions if they are granted the permissions to do so, making this attack vector a risk that could be taken advantage of by both internal and external identities,” the researcher found.

Mitigation

For the insecure configurations that Salesforce has not already fixed, AppOmni provides mitigation recommendations in its paper, including a list of objects that should have their object, field, and Sharing Rule configurations routinely audited. Reducing the access level for OmniStudio sObjects and their records to only what’s necessary is the first line of defense, the company said.