Salesforce tags 5 CVEs after SaaS security probe uncovers misconfig risks – Source: go.theregister.com

Salesforce has assigned five CVE identifiers following a security report that uncovered more than 20 configuration weaknesses, some of which exposed customers to unauthorized access and session hijacking.

The vulnerabilities were made public this week after admins were notified of the flaws in May. Aaron Costello, AppOmni chief of SaaS security research who made the findings, said all five CVEs were associated with Flexcards, Data Mappers, and other core components of Salesforce Industries.

Salesforce did not deem the other 16 flaws Costello reported worthy of CVEs, but instead classified them as misconfigurations, placing the responsibility for addressing them on the customer.

“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,” he said.

“For organizations using Salesforce industry clouds, these findings underscore an urgent need to assess and secure your configuration before attackers can exploit any misconfigurations,” Costello added.

Salesforce issued four CVEs related to the Flexcard UI-building tools, none of which have been assigned severity scores:

• CVE-2025-43698: The SOQL data source exposes field data by ignoring field-level security permissions
• CVE-2025-43699: Client-side checking means the Required Permissions field can be bypassed
• CVE-2025-43700: Flexcard returns plaintext data stored using Classic encryption for unauthorized users because it fails to enforce the View Encrypted Data permission
• CVE-2025-43701: Guest Users are allowed to access values for Custom Settings

The final CVE relates to Data Mappers, which allow customers to read, transform, and write Salesforce data:

• CVE-2025-43697: Underprivileged users can be sent encrypted data in plaintext because the Extract and Turbo Extract actions fail to enforce field-level security by default

Salesforce’s industry clouds offer both technical and non-technical users a low-code platform to build business logic that can make use of the company’s most sensitive data. It increases the potential pool of innovators within a workplace, but it also means that these platforms can be misconfigured in one way or another, exposing security gaps.

• Microsoft warns of 66 flaws to fix for this Patch Tuesday, and two are under active attack
• Critical Wazuh bug exploited in growing Mirai botnet infection
• Chinese spy crew appears to be preparing for conflict by backdooring 75+ critical orgs
• IBM Cloud login breaks for second time this week and Big Blue isn’t saying why

The misconfigurations in other components that did not have CVEs assigned related to Flexcards and Data Mappers, but also Integration procedures, Data Packs, OmniOut, and OmniScript Saved Sessions.

The exact details of these are listed in Costello’s research paper, but broadly the consequences of these include the decryption of data, unauthorized accesses to credentials and APIs, and session data leaks.

The researcher said the responsibility for securing these settings falls to the customer, and even a single misconfiguration “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,” he added.

“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.”

Salesforce admins are advised to read AppOmni’s recommended actions, which can be found in its report, but they essentially boil down to ensuring field-level security is enforced, increasing components’ permission requirements, applying regular updates, and using private – not public – caching mechanisms to protect user data. ®