Salesforce industry clouds empower leaders across sectors like healthcare, financial services, and telecoms to innovate faster with a secure, low-code platform with industry-specific solutions. Its low code design and ease of use enables both technical and non-technical teams to build powerful solutions rapidly. However, that flexibility also comes with customer responsibility: to keep security front and center in configuring and using the platform as organizations rapidly evolve their digital strategies.
In my latest research, I uncovered over 20 configuration related risks in addition to the discovery of multiple Zero-day vulnerabilities. These findings revealed how default settings and some insecure patterns that are the responsibility of the customers to configure and use correctly, can lead to unauthorized access to encrypted fields, session stealing, credentials, and business logic. I notified Salesforce to address these findings with Salesforce collaborating with AppOmni to issue updates. Salesforce has issued CVEs for five of my findings – fixing three and issuing configuration guidance for the other two that require customer action. The remaining sixteen configuration risks are the responsibility of customers to address.
With over a quarter of AppOmni’s customers leveraging Salesforce industry clouds, we’ve seen firsthand how quickly the ecosystem is evolving, and how important it is to stay ahead of emerging risks. Our goal is to help organizations maximize the benefits of Salesforce’s industry clouds while ensuring robust, ongoing protection for their most sensitive data.
These findings impacted core components like FlexCards, Data Mappers, and Integration Procedures. For organizations using Salesforce industry clouds, these findings underscore an urgent need to assess and secure your configuration before attackers can exploit any misconfigurations.
For a detailed analysis and step-by-step remediation guidance, security administrators should read the research paper on this topic.

The convenience—and consequence—of low-code
Salesforce’s industry clouds provide rapid workflow development. As with any powerful platform, thoughtful configuration and regular reviews are key to maintaining a secure environment. Low code is a powerful tool for non-developers, and allows non-technical users to build logic that touches critical systems and sensitive customer and internal data. But this empowerment can come at a cost with respect to security, drastically increasing the risk of misconfigurations by customers. 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. The research identifies opportunities where organizations should consider hardening their deployments in industry clouds. These misconfigurations can have serious security impact if left unaddressed by customers, including but not limited to:
- Low-code components not enforcing access control checks or respecting encrypted data by default
- By default, code written to enhance workflows may be at risk of execution by unintentional parties such as external or unauthenticated users
- Misuse of caching mechanisms can be used to bypass access controls and even leak data between individuals
- Poorly developed off-platform OmniOut applications may result in API token theft, exposing the data of 3rd party users
- Sensitive data embedded directly in components, like API keys, can be read without needing permission to run them
- Exported and imported component packages can be accessed to circumvent permissions on the components themselves
- Insecure permissions on saved workflows allows other users to view open sessions, leaking saved data
The essential steps that customers need to take to remove these security risks include:
- Lock-down sharing rules and field-level access for industry clouds’ objects, especially for external identities
- Harden powerful components by requiring additional permissions
- Update default configuration settings that introduce risk where possible
- Use private caching mechanisms rather than public ones to maintain the confidentiality of user-specific data
- Applying regular updates, as Salesforce provides patches and CVEs in response to new research
Five CVEs that were issued for the risks
My disclosures led Salesforce to classify five of the findings as vulnerabilities, and a CVE was issued for each. All of which are associated with core components, FlexCards and Data Mappers. Each one highlights how seemingly minor configuration decisions by the customer or unpatched vulnerabilities can have major security consequences. As of May 19, 2025, all Salesforce customers (administrators) received notification of these vulnerabilities.
FlexCard 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 Mapper CVE
- CVE-2025-43697: ‘Extract’ and ‘Turbo Extract’ actions do not enforce FLS by default, and return plaintext data of encrypted values to users without permissions to see them.
What AppOmni found: Key security risks by feature
While the CVEs are only one component, below is a comprehensive list of risky configurations discussed in detail in the paper.
FlexCards
Used to fetch Salesforce data via SOQL, SOSL, and Data Mappers.
- Lack of FLS Enforcement for SOQL
- Data Leakage from Test Responses and Session Variables
Data Mappers
Server-side components to extract, transform, or load data.
- FLS Disabled by Default
- Decryption of Encrypted Data by Default without Checking Permissions
- Bypassing Permissions using the Scale Cache
Integration Procedures (IProcs)
Server-side orchestration engine for APIs, Apex, and logic.
- Nested Actions Skip Permission Validation
- Hardcoded Credentials are Readable by Users Unauthorized to Run the IProc
- Callable Apex Exposed to Unauthorized Users by Default
- Bypassing Permissions Using the Scale Cache
- Insecure Use of Organization Cache Leaks Results Between Users
Data Packs
Used for migrating OmniStudio components between orgs.
- Reading Imported / Exported Data Packs to Bypass Permissions of Contained Components
- ‘Hidden’ Exported Data Packs Persistently Expose Data
OmniOut
Embeds components off-platform using OAuth.
- API Token Theft from Client-Side Storage
- Insecure Credential Storage through Direct Code Embedding
- Controllable API Paths Grant Access to Unauthorized APIs
- API Token Tied to Over Privileged User
OmniScript Saved Sessions
Stores in-progress user sessions.
- Session Data Leaks through Broad Permissions
- Session Fixation-Style Phishing to Steal Information
This isn’t just misconfiguration; it’s a maturity gap
For organizations subject to compliance mandates such as HIPAA, GDPR, SOX, or PCI-DSS, these gaps can represent real regulatory exposure. And because it is the customer’s responsibility to securely configure these settings, a single missed setting could lead to the breach of thousands of records, with no vendor accountability.
Security is not optional, and default settings prioritize usability. These vulnerabilities weren’t bugs. They were design decisions made for usability. But in industries where data sensitivity is high, that usability needs to be rebalanced with security rigor.
The solution isn’t panic; it’s discipline. Apply the same scrutiny to industry cloud components that you would to any production code. Test, audit, and configure defensively.
How AppOmni helps
At AppOmni, the focus is straightforward: to help organizations secure their SaaS environments by surfacing the risks that often go unnoticed.
Based directly on the findings from this research, AppOmni built and released over 20 targeted insights designed to detect misconfigurations in Salesforce industry cloud environments. These insights are tightly aligned to the findings outlined in the research paper.
These detections are based on real-world scenarios we’ve observed firsthand across customer environments. Our goal is to equip security and platform teams with immediate visibility and a clear path to remediation.

Want to go deeper?
Explore the over 20 issues in detail, with technical proof-of-concepts in the full research report, learn the basics of securing Salesforce in our workshops, or learn more when Aaron presents his research in our upcoming webinar.