On November 20, 2025, Salesforce disclosed that threat actors had compromised OAuth tokens associated with Gainsight-published applications, potentially accessing data from over 200 customer Salesforce instances. The attack was attributed to ShinyHunters, the same group behind the August 2025 Salesloft Drift breach that hit 700+ organizations.
But before we pile on Gainsight, let's be clear about what actually happened—because the reality is more nuanced and more concerning than "vendor didn't secure their tokens."
What Actually Happened: A Supply Chain Cascade
The attack chain reveals something important:
-
March–June 2025: ShinyHunters compromised Salesloft's GitHub account, established persistence, and eventually accessed Drift's AWS environment where OAuth tokens were stored
-
August 2025: Using those tokens, attackers exfiltrated data from 700+ Salesforce instances connected to Drift, including support case contents containing embedded secrets (AWS keys, Snowflake tokens, passwords)
-
The key detail: Gainsight was one of the organizations breached through Drift. Attackers found Gainsight's own credentials in that exfiltrated data.
-
November 2025: ShinyHunters used those stolen Gainsight credentials to access Gainsight's systems and obtain OAuth tokens for ~285 additional Salesforce instances
This wasn't Gainsight having poor security hygiene in isolation—it was a cascading supply chain attack where one breach enabled the next. Gainsight was both a victim (of Drift) and a vector (to their customers).
The Uncomfortable Reality for ISVs
Here's what makes this genuinely hard: Gainsight is a customer success platform that needs ongoing access to customer Salesforce data to function. Unlike a one-time installer like MetaDeploy (which I helped build at Salesforce.org), Gainsight can't simply "revoke tokens immediately after use." Their entire product depends on maintaining persistent connections to sync customer data.
This is true for most AppExchange products that provide ongoing value—they need ongoing access. The question isn't whether to hold tokens, but how to hold them securely and what happens when that security fails.
The Connected App Settings That Matter
Salesforce provides a setting on Connected Apps that many organizations don't enable: Refresh Token Rotation.
By default, a refresh token can be used indefinitely—the same token works forever until explicitly revoked. But Salesforce offers policies including:
- "Refresh token is valid until revoked" (the default—and the riskiest)
- "Expire refresh token if not used for X amount of time"
- "Expire refresh token after X amount of time"
- Refresh token rotation (issues a new token with each refresh)
With rotation enabled, each time a refresh token is exchanged for an access token, the old refresh token is invalidated and a new one is issued. This means a stolen token has a limited window of usefulness—if the legitimate application refreshes before the attacker uses the stolen token, the attacker's copy becomes worthless.
The catch: This requires the application to properly handle token rotation, storing the new refresh token each time. Not all applications are architected for this. And if you're an ISV customer, you may not have visibility into whether your vendors have enabled these settings.
What We Warned About Still Applies
In September 2024, I published 5 Critical Security Questions to Ask Your SI Partner before Dreamforce. The core message applies equally to AppExchange vendors:
"The Salesforce user accounts you provide for your partner are the keys to all your org's configuration and all its data. Every consultant and every tool they use with that user has the keys to everything."
And Question #3:
"How do you handle secure credential management and rotation, especially for API access?"
The Gainsight breach shows why these questions matter for every Connected App you authorize—not just consulting partners.
The Shield Gap: Investigation Requires a Paid Add-On
Here's an uncomfortable truth that Salesforce doesn't advertise: the tools you need to investigate a breach are behind a paywall.
Event Monitoring logs—the primary mechanism Salesforce recommends for investigating unauthorized access—require Salesforce Shield, a paid add-on that most small-to-mid-sized organizations don't have.
Gainsight's own guidance to customers? "We strongly recommend that you focus your investigation on the Salesforce logs that show authentication attempts and API calls originating from the Gainsight Connected App."
Great advice—if you have Shield. If you don't, you're largely dependent on the breached vendor and Salesforce to tell you what happened.
What This Means for ISVs
If you're building products that integrate with customer Salesforce orgs:
1. Enable refresh token rotation on your Connected Apps Yes, it requires architectural changes to handle rotating tokens properly. Do it anyway.
2. Implement IP restrictions Salesforce allows you to restrict which IP addresses can use your Connected App. This won't prevent all attacks, but it raises the bar.
3. Request minimum necessary scopes
Don't request full access if you only need to read Accounts and Contacts. Principle of least privilege applies to OAuth scopes too.
4. Assume your infrastructure will be targeted You're holding keys to hundreds or thousands of customer orgs. That makes you a high-value target. Plan accordingly.
5. Have an incident response plan When (not if) something goes wrong, how quickly can you identify affected customers, revoke compromised tokens, and communicate transparently?
What This Means for Customers
1. Audit your Connected Apps Go to Setup → Connected Apps OAuth Usage and review what has access to your org. When did you last look at this list?
2. Ask vendors about their token policies
- Do they enable refresh token rotation?
- What's their token expiration policy?
- How do they secure stored credentials?
- What's their breach notification process?
3. Consider IP restrictions If a Connected App only needs to access your org from known IP ranges, restrict it.
4. Monitor for the IOCs Salesforce published indicators of compromise including the user agent string "Salesforce-Multi-Org-Fetcher/1.0" and specific IP addresses. Check your logs if you have Event Monitoring.
5. Recognize the supply chain risk Your security depends not just on Salesforce, not just on your vendors, but on your vendors' vendors and their security practices.
The Bigger Picture
The Salesloft → Gainsight cascade demonstrates something the security industry has been warning about: in a world of interconnected SaaS applications, a breach at any point in the supply chain can cascade to everyone downstream.
Salesforce's platform wasn't compromised. Neither was Gainsight's Connected App code. The attack exploited the trust relationships between systems—the OAuth tokens that make integrations work are also what attackers exploit when they gain access.
This isn't a problem unique to Gainsight or even to Salesforce. It's the fundamental challenge of the modern SaaS ecosystem, where productivity gains from integration come with security tradeoffs that we're only beginning to understand.
Need Help Assessing Your Exposure?
At Muselab, we've spent 10+ years thinking about secure credential management in the Salesforce ecosystem. We can help you:
- Audit your Connected App exposure
- Review OAuth policies and configurations
- Design more secure integration architectures
- Prepare for security reviews and M&A due diligence
Book a free consultation to discuss your specific situation.