Unauthorized Data Access in Salesforce Published Applications

Salesforce has started notifying customers after it detected unusual activity involving Gainsight-published applications connected to Salesforce orgs. According to the security advisory, this activity may have enabled 𝗽𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹 𝘂𝗻𝗮𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗲𝗱 𝗮𝗰𝗰𝗲𝘀𝘀 𝘁𝗼 𝗰𝗲𝗿𝘁𝗮𝗶𝗻 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀’ 𝗦𝗮𝗹𝗲𝘀𝗳𝗼𝗿𝗰𝗲 𝗱𝗮𝘁𝗮 through those apps’ OAuth connections rather than any flaw in the core Salesforce platform.

Salesforce revoked all active access and refresh tokens associated with Gainsight-published apps, pulled those apps from the AppExchange, and stressed that the “unusual activity” appears related to the apps’ external connection, not to a Salesforce vulnerability.  Meanwhile, multiple threat-intel teams and SaaS security vendors now link this activity to the same broader OAuth-abuse ecosystem that powered the Salesloft Drift Salesforce campaign earlier this year widely attributed to ShinyHunters and related clusters. 

For defenders, this incident reinforces a hard truth: once you grant a third-party connected app broad OAuth scopes into a CRM, that app effectively becomes an extension of your data perimeter. If attackers compromise the app or its tokens, they inherit that trust.

𝗪𝗵𝗮𝘁 𝗛𝗮𝗽𝗽𝗲𝗻𝗲𝗱 𝗶𝗻 𝗧𝗵𝗶𝘀 𝗦𝗮𝗹𝗲𝘀𝗳𝗼𝗿𝗰𝗲–𝗚𝗮𝗶𝗻𝘀𝗶𝗴𝗵𝘁 𝗖𝗮𝘀𝗲

In the latest status message, Salesforce explains that it identified unusual activity on integrations that customers set up using applications published by Gainsight. Those apps sit inside customer-managed orgs and connect back into Salesforce via OAuth.

Salesforce’s investigation indicates that this activity may have enabled attackers to access certain customers’ Salesforce data through those connected apps. As a direct containment step, Salesforce:

• revoked all active access and refresh tokens tied to Gainsight-published apps, and

• temporarily removed those apps from the AppExchange while the investigation continues.

At the same time, Gainsight has confirmed that it is working with Salesforce to investigate and has published its own FAQ for affected customers. Neither company has yet published a final object-level impact assessment, and they have not publicly named specific tenants beyond describing “certain customers” and hundreds of potentially affected orgs in related briefings.

𝗪𝗵𝗲𝗿𝗲 𝗢𝗔𝘂𝘁𝗵 𝗙𝗶𝘁𝘀 𝗜𝗻𝘁𝗼 𝗧𝗵𝗶𝘀 𝗖𝗮𝗺𝗽𝗮𝗶𝗴𝗻

In modern SaaS environments, OAuth scopes often quietly become the most powerful keys in the ecosystem. Gainsight-published apps typically request broad access to Salesforce objects so they can provide customer-success analytics, health scores, and usage insights. Those capabilities require read or read-write access to Accounts, Contacts, Cases, Opportunities, and custom objects.

Threat-intel reporting around this incident and the broader 2025 Salesforce breach wave suggests attackers now actively hunt for over-privileged OAuth integrations. In the Salesloft Drift / UNC6395 campaign, for example, attackers stole OAuth tokens from a third-party integration and then used those tokens to access hundreds of Salesforce orgs, exfiltrating CRM data and even cloud secrets embedded in support data.

In this Gainsight case, investigators and vendors describe a similar pattern:

• threat actors obtain or abuse OAuth tokens issued to Gainsight apps;

• those tokens grant access into customer Salesforce orgs with whatever scopes the admins originally approved;

• attackers use that foothold to list objects, query records, and pull data at scale.

Salesforce, for its part, continues to emphasize that it has not found evidence of an exploit in the core platform. Instead, the issue lives in the trust chain between customer orgs, their installed Gainsight apps, and the OAuth tokens that bind them together.

𝗪𝗵𝗮𝘁 𝗗𝗮𝘁𝗮 𝗦𝗰𝗼𝗽𝗲 𝗜𝘀 𝗔𝘁 𝗦𝘁𝗮𝗸𝗲?

Public reporting around this campaign and neighboring ones paints a consistent picture of the type of data that attackers target when they land inside Salesforce via OAuth:

• core CRM records such as Accounts, Contacts, Opportunities, and Cases;

• business contact information names, corporate emails, phone numbers, titles, and account hierarchies;

• support-case content, licensing data, usage telemetry, and in some cases secrets or tokens embedded in notes and attachments.

In the Salesloft Drift driven campaign earlier this year, ShinyHunters claimed to have stolen roughly 1.5 billion records across hundreds of Salesforce instances and focused specifically on credentials and cloud tokens buried in CRM objects. Early commentary around Gainsight-linked access now suggests a smaller but still significant cohort on the order of a few hundred orgs experienced some level of unauthorized data access before Salesforce revoked tokens.

For most organizations, that kind of exposure does not necessarily involve credit-card data or regulated secrets. However, it does expose dense relationship graphs and account intelligence that adversaries can weaponize in subsequent phishing, extortion, and supply-chain operations.

𝗛𝗼𝘄 𝗧𝗵𝗶𝘀 𝗘𝗰𝗵𝗼𝗲𝘀 𝘁𝗵𝗲 𝗪𝗶𝗱𝗲𝗿 𝗦𝗮𝗹𝗲𝘀𝗳𝗼𝗿𝗰𝗲 𝗕𝗿𝗲𝗮𝗰𝗵 𝗪𝗮𝘃𝗲

This incident does not exist in a vacuum. Throughout 2025, ShinyHunters and related clusters (UNC6040, UNC6395) have repeatedly targeted Salesforce tenants via either third-party integrations or fake tooling. In one track, they convinced employees to install a trojanized variant of Salesforce’s Data Loader and then abused OAuth to export data from compromised orgs.

In another track, they stole OAuth tokens from integrations like Salesloft Drift and reused them at scale against hundreds of Salesforce environments. Analysts now view the Gainsight-linked access as part of the same strategic playbook: target integration points that sit between large SaaS platforms, compromise one partner, and inherit trust into many customer orgs at once.

As a result, the “Salesforce breach wave of 2025” increasingly looks like an ecosystem problem, not a series of isolated accidents. The connective tissue OAuth, connected apps, and shared APIs has become the primary attack surface.

𝗜𝗺𝗺𝗲𝗱𝗶𝗮𝘁𝗲 𝗦𝘁𝗲𝗽𝘀 𝗙𝗼𝗿 𝗢𝗿𝗴𝘀 𝗧𝗵𝗮𝘁 𝗨𝘀𝗲 𝗚𝗮𝗶𝗻𝘀𝗶𝗴𝗵𝘁 𝗪𝗶𝘁𝗵 𝗦𝗮𝗹𝗲𝘀𝗳𝗼𝗿𝗰𝗲

If your organization connects Salesforce to Gainsight, you should treat this as a live security incident until you prove otherwise. Salesforce already revoked Gainsight app tokens, yet that action only stops further OAuth use; it does not retroactively remove any data that attackers may have pulled.

At a minimum, you should:

• identify all Gainsight-published apps that ever connected to your Salesforce orgs and confirm which business units own them;

• review login history, connected-app usage, and API request logs around the advisory timeframe for anomalous queries, bulk exports, or large report runs;

• rotate credentials and tokens associated with integration users, related service accounts, and any secrets that might appear in Salesforce cases or attachments;

• tighten OAuth scopes for all third-party apps, ensuring they align with strict least-privilege rather than convenience

While you complete that work, you should assume that attackers could have pulled contact-level data and other business metadata. That assumption helps you plan realistic downstream controls, such as heightened phishing detection against exposed accounts and extra scrutiny around account-takeover attempts that leverage leaked details.

𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗰 𝗟𝗲𝘀𝘀𝗼𝗻𝘀: 𝗧𝗿𝗲𝗮𝘁 𝗖𝗼𝗻𝗻𝗲𝗰𝘁𝗲𝗱 𝗔𝗽𝗽𝘀 𝗮𝘀 𝗣𝗿𝗶𝘃𝗶𝗹𝗲𝗴𝗲𝗱 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲

Beyond immediate response, this incident underscores a broader mindset shift. Many organizations still view Salesforce connected apps as “just business tooling,” not as privileged infrastructure that needs the same governance as VPNs or identity providers. In reality, any app that holds a broad OAuth token into Salesforce effectively becomes an extension of your identity plane.

Therefore, security teams should:

• classify high-privilege Salesforce connected apps as Tier-1 assets with named owners and explicit risk acceptance;

• audit those apps regularly for scope creep, dormant integrations, and misaligned permissions;

• enforce conditional-access policies and IP restrictions on integration users where the platform allows it;

• integrate connected-app events into their SIEM so they can detect unusual query patterns or off-hours bulk exports.

If you already weathered the Drift-related Salesforce incidents earlier this year, you can treat the Gainsight incident as another signal that this threat model will persist. Attackers now specialize in OAuth abuse, and they will continue to probe any integration that yields high-value CRM data.

𝗪𝗵𝗮𝘁 𝗦𝗮𝗹𝗲𝘀𝗳𝗼𝗿𝗰𝗲 𝗮𝗻𝗱 𝗚𝗮𝗶𝗻𝘀𝗶𝗴𝗵𝘁 𝗡𝗲𝗲𝗱 𝘁𝗼 𝗗𝗼 𝗡𝗲𝘅𝘁

Salesforce has already taken important first steps: revoking tokens, removing Gainsight apps from AppExchange, and publishing a security advisory that clarifies the current view of platform impact. However, customers will expect more than emergency levers. They need granular answers to three questions:

• which objects and fields did attackers access through these Gainsight apps,

• how long did the unauthorized access persist, and

• what additional controls will Salesforce and Gainsight enforce to prevent re-use of this vector?

Gainsight, in particular, will need to show how it protects its own environment, secrets, and OAuth token handling, especially given reports that threat actors claim to have used stolen Gainsight tokens to reach hundreds of Salesforce instances. Transparency here directly influences whether enterprises continue to trust Gainsight as a CSM layer atop their CRMs.

For Salesforce, the long-term answer likely involves stronger default guardrails for connected apps: better discovery, richer built-in risk scoring for over-privileged integrations, and more prescriptive guidance for customers who lack dedicated SaaS security expertise. Until then, customers must treat OAuth governance as a first-class security practice rather than an afterthought.

𝗧𝗵𝗲 𝗥𝗲𝗮𝗹 𝗟𝗲𝘀𝘀𝗼𝗻 𝗙𝗿𝗼𝗺 𝗬𝗲𝘁 𝗔𝗻𝗼𝘁𝗵𝗲𝗿 𝗦𝗮𝗹𝗲𝘀𝗳𝗼𝗿𝗰𝗲 𝗘𝗰𝗼𝘀𝘆𝘀𝘁𝗲𝗺 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁

This Gainsight-linked incident reinforces a pattern that 2025 has already made painfully clear: attackers do not need a zero-day in Salesforce to steal Salesforce data. Instead, they compromise the ecosystem around it integrations, partner tools, and connected apps which often hold OAuth tokens with expansive scopes and weak oversight.

If your organization relies on Salesforce as a system of record, you now need a threat model that explicitly covers 𝗼𝘂𝘁𝘀𝗶𝗱𝗲 𝗮𝗽𝗽𝘀 𝗵𝗼𝗹𝗱𝗶𝗻𝗴 𝗶𝗻𝘀𝗶𝗱𝗲 𝗮𝗰𝗰𝗲𝘀𝘀. That means disciplined OAuth governance, active monitoring of connected-app behavior, and a clear, repeatable playbook whenever a third-party integration lands in the headlines.

𝗙𝗔𝗤𝗦

Q: Does this incident mean Salesforce’s core platform is insecure?
A: No. Salesforce stated there is no indication the issue resulted from a vulnerability in its core platform. The risk lies in third-party applications that integrate via OAuth and may misuse that trust.

Q: How can attackers use connected applications to access Salesforce data?
A: Attackers may gain or misuse OAuth tokens for a connected app, granting it substantial access rights. With that access the app can query objects like Accounts, Users, Cases, and Opportunities, and extract data without needing a platform exploit.

Q: Which organizations are most at risk in this scenario?
A: Companies that allow broad connected-app permissions, do not audit token usage, or have publicly exposed integrations. Particularly at risk are high-value cloud tenants, SaaS-hungry organizations, and businesses with multiple third-party Salesforce apps.

Q: What immediate actions should an org take following this threat?
A: Perform an immediate audit of connected apps, revoke suspicious OAuth tokens, enforce least-privilege scopes, monitor API usage for anomalies, and ensure token rotation and token lifetimes are enforced.

Q: How can companies reduce the risk of this type of incident in the longer term?
A: Maintain an inventory of all connected applications, require admin-approved user access for app installs, limit refresh token lifetime, apply network controls (IP restrictions, regional controls), and treat token misuse as part of vendor/supply-chain risk management.