Salesforce Fixes Critical OAuth Flaw Allowing Persistent Data Access
Key Takeaways A critical flaw in Salesforce’s OAuth implementation allowed attackers to gain persistent access to sensitive customer data. The vulnerability, while not an inherent software bug,...
Key Takeaways
- A critical flaw in Salesforce’s OAuth implementation allowed attackers to gain persistent access to sensitive customer data.
- The vulnerability, while not an inherent software bug, stemmed from the abuse of trusted OAuth relationships and connected applications.
- Threat actors, including those associated with ShinyHunters, leveraged voice phishing and compromised SaaS integrations to exploit this weakness.
- The attacks enabled persistent CRM access, data exfiltration, and potential lateral movement to other cloud services, often bypassing standard security monitoring.
- Salesforce has addressed the issue, and organizations are urged to review connected applications, revoke unnecessary permissions, and enhance monitoring.
A significant vulnerability within Salesforce’s OAuth framework has been identified and patched, which, when exploited, could grant attackers enduring access to highly sensitive customer information. This flaw, though not a traditional software bug, leveraged the misuse of legitimate, trusted application connections, providing a stealthy pathway for extensive data theft and persistent unauthorized access.
Table Of Content
Observations by Microsoft spanning from mid-2025 to mid-2026 revealed a series of campaigns, linked to the threat group ShinyHunters, targeting diverse sectors including retail, education, and manufacturing. These attacks exploited the trust inherent in OAuth relationships, allowing malicious applications to operate with the permissions of an authorized employee, thereby blending seamlessly into normal business operations.
The attackers utilized various tactics, including voice phishing, compromising SaaS integrations, and exploiting overly permissive guest access configurations. These methods facilitated unauthorized entry into Salesforce environments, enabling them to query CRM data and exfiltrate information without triggering typical suspicious login alerts, as Microsoft said in a report shared with Cyber Security News (CSN).
The danger of such an intrusion extends beyond a single compromised account. Once a malicious application gains approval, it can systematically map a victim’s Salesforce instance, execute API calls under the user’s identity, maintain long-term access, and potentially uncover credentials that open doors to other cloud services. Microsoft emphasized that these activities were not due to a direct vulnerability in Salesforce’s core platform but rather the exploitation of existing, albeit misconfigured or abused, trusted relationships within organizations.
Exploiting OAuth for Persistent Access
The attack methodology typically began with sophisticated voice phishing campaigns. Threat actors impersonated IT support personnel, convincing employees to authorize an attacker-controlled application. This application was often disguised as a legitimate Salesforce Data Loader tool. The crucial step involved the employee granting OAuth scopes to this deceptive application through a consent screen, effectively bestowing it with the user’s full privileges without requiring continuous password re-authentication.
In documented incidents, this single, mistaken approval allowed threat actors to enumerate Salesforce instances, search and query records extensively, and establish persistent access to critical CRM data. A significant challenge in detecting these intrusions is that the resulting API traffic originates from an approved application, making it difficult for standard sign-in monitoring systems to flag it as malicious activity.
This persistent access facilitated the collection of vital information, including accounts, contacts, and service case data. Furthermore, if exploitable credentials were discovered, attackers could pivot to other interconnected SaaS services, broadening the scope of their compromise. This technique bypasses the need for malware installation on employee devices or repeated account takeover attempts, instead transforming a seemingly innocuous authorization step into a durable foothold with legitimate operational permissions.
The ramifications of such an attack are not limited to the individual who granted approval. Salesforce data often underpins sales, support, partner interactions, and internal business processes. Therefore, broadly granted permissions can expose a much larger operational landscape to adversaries. This underscores a vital security lesson: an OAuth consent prompt represents a critical security decision, not merely a routine setup procedure, especially when an external party is guiding the employee through the process in real-time.
Supply-Chain and Guest Access Vulnerabilities
Microsoft’s findings also highlighted supply-chain vulnerabilities involving third-party SaaS vendors integrated with Salesforce. For instance, compromised Salesloft Drift credentials in August 2025 exposed connection secrets, enabling the use of OAuth tokens across various customer instances. Similarly, a November campaign exploited Gainsight-published applications to maintain API access. A Klue incident in June 2026 followed an analogous pattern. Separately, attackers exploited Salesforce Aura endpoints where guest-user permissions were inadequately configured. By crafting and chaining GraphQL-based Aura requests, threat actors could retrieve significantly more information than guest users should typically access. These methods leverage accepted identities or application pathways, making large-scale data exfiltration appear as routine integration activity.
What You Should Do
- Review All Connected Applications: Conduct a comprehensive audit of all applications connected to your Salesforce instance. Remove or revoke approvals for any unused or suspicious applications.
- Implement Least Privilege: Scrutinize the permissions granted to all connected applications and ensure they align precisely with legitimate business requirements. Remove any overly broad permissions.
- Secure Guest User Access: Carefully configure and monitor Salesforce Experience Cloud guest-user access settings to prevent unauthorized data retrieval.
- Proactive Monitoring: Enhance monitoring of Salesforce event logs for unusual API volume, suspicious report exports, unfamiliar application IDs, new network locations, and anomalous guest-user behavior.
- Educate Employees: Provide regular security awareness training, particularly on recognizing and reporting social engineering attempts like voice phishing, and the importance of scrutinizing OAuth consent prompts.
- Manage Dormant Integrations: Treat dormant integrations as potential security risks, especially after 90 days of inactivity, and consider revoking their access.
- Improve Telemetry: Implement faster event telemetry to better attribute actions to specific connected applications and understand the identities, sessions, and API calls involved in any suspicious activity.
- Review Third-Party Connections: Regularly audit all third-party connections to Salesforce to ensure they adhere to security best practices and do not introduce undue risk.
Indicators of Compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| IP address | 138[.]226[.]246[.]94 | Used by the Klue integration to call the Salesforce API for CRM queries on June 11. Previously disclosed by Klue in its breach notification. |
| IP address | 212[.]86[.]125[.]24 | Not specified in source material. |
| IP address | 213[.]111[.]148[.]90 | Not specified in source material. |
| IP address | 94[.]154[.]32[.]160 | Not specified in source material. |
| IP address | 103[.]75[.]11[.]78 | Used to target the Aura framework through guest access from June 19 to 22; identified by Microsoft during a novel campaign. |
| IP address | 103[.]75[.]11[.]110 | Used to target the Aura framework through guest access from June 19 to 22; identified by Microsoft during a novel campaign. |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.