ShinyHunters listed Alcon Inc. on its extortion portal on August 2, 2026, claiming it had exfiltrated 25 million Salesforce records containing personally identifiable information.
Alcon is a Swiss-headquartered eye care company with roughly $9.9 billion in annual revenue and operations in over 60 countries. The claim was posted alongside two other victims: Questel SAS, a Paris-based intellectual-property software provider where ShinyHunters alleged 21 million Salesforce records and 147 GB of internal data, and Lumenis Ltd., an Israeli medical-technology firm where the group claimed 1.1 million records and 176 GB. ShinyHunters gave each organisation until August 4 to make contact before threatening public release. As of publication, Alcon has not issued a public statement on the claim.
The attack technique is consistent with a campaign Microsoft documented in July 2026. ShinyHunters abuses Salesforce Connected Apps through two paths. The first is vishing: threat actors impersonate IT support and guide employees through an OAuth consent flow that authorizes a malicious app disguised as Salesforce Data Loader. The second is supply chain compromise: by breaching third-party SaaS vendors that integrate with Salesforce via OAuth, the group obtains refresh tokens that grant persistent API access to downstream customer Salesforce instances. Once inside, bulk SOQL queries export accounts, contacts, and service case records without triggering sign-in anomalies, because the API calls are indistinguishable from legitimate integrations. Two things are worth pulling out of the reporting.
What scanners would have missed
The vulnerability here is not in source code. It is in the trust relationships between Salesforce and the applications connected to it.
A SAST scanner running on Alcon's internal codebase would find nothing. The exfiltration path did not pass through Alcon's own code. A DAST scanner probing Alcon's web applications would also find nothing. The attacker did not send malformed HTTP requests to Alcon's servers. A dependency scanner checking for CVEs in Alcon's libraries would find nothing. There is no CVE for this class of attack.
The failure modes fall into four patterns that scanners miss consistently:
- Overprivileged Connected Apps that can bulk-query CRM data with no additional user verification.
- Third-party OAuth integrations inheriting high-privilege Salesforce user contexts from compromised vendors.
- No rate limiting or anomaly detection on bulk record exports via the API.
- OAuth consent flows that any authenticated employee can complete without a secondary approval step.
Severity rankings are meaningless here because there is no CVE to score. The attack surface exists entirely in a configuration layer that SAST, DAST, and SCA tools do not model. A CVSS score divorced from your actual OAuth trust graph tells you nothing about whether your Salesforce instance is safe.
What Sekura would have shown
Phase 3 of Sekura's pipeline is dynamic probing. The agent in that phase is not running a web vulnerability scanner. It is actively probing the application's attack surface at runtime, including identity flows, OAuth endpoints, and third-party integration touchpoints.
For an Alcon-style environment, the dynamic probing agent would have enumerated the Salesforce Connected Apps registered in the org. It would have identified which apps held refresh tokens with broad API scope. It would have tested whether the OAuth consent flow for a newly registered Connected App could be completed without secondary verification. And it would have queried the Salesforce API under a constrained test-user context to confirm whether bulk record export was rate-limited or flagged.
The finding would have shown a Connected App with full or api scope that any authenticated employee can authorize, combined with a third-party integration carrying a long-lived refresh token with no expiry policy, combined with no transaction security policy on bulk exports. That combination is not a theoretical risk. It is a demonstrable exfiltration path.
What we would not claim is that this analysis would have stopped the attack. The dynamic probing agent would have produced a proof showing the path was open, and given Alcon a concrete remediation target: scope-restrict Connected Apps, rotate long-lived OAuth tokens, enable Salesforce Event Monitoring with bulk export alerts.
The bigger pattern
This is an OAuth trust chain attack. The category is not new. The scale is.
ShinyHunters has tallied over 1.5 billion stolen Salesforce records across victims in the past several months. The reason is that Salesforce is a concentration point. One well-connected CRM instance holds more customer and employee PII than most internal databases. And the trust model, Connected Apps with broad scope and long-lived refresh tokens, was designed for developer convenience in environments where credential theft of a third-party vendor now means instant access to the downstream CRM.
Most organisations can name their internet-facing web applications. Fewer can enumerate which third-party integrations hold active OAuth tokens against their Salesforce org, what scope those tokens carry, and when those tokens last rotated. That gap is where this campaign runs.
If you want to see what proof-first coverage of your SaaS trust graph looks like, book a POC.