Klue has publicly acknowledged a security incident in which attackers used a compromised legacy integration credential to obtain OAuth tokens and access data inside connected customer environments, including Salesforce. The breach, identified by Klue on June 12 and described publicly by CEO Jason Smith on June 19, has already prompted disclosures from affected security companies and forced a closer look at how much access SaaS integrations quietly hold inside enterprise systems.
The incident did not begin with a Salesforce platform vulnerability. It began in Klue’s integration infrastructure, where a long-lived credential associated with an integration service gave an attacker a way to reach tokens used by customers to connect Klue with third-party platforms. Klue says it revoked affected credentials and tokens, removed unauthorized code, disabled potentially affected integrations, notified law enforcement, and brought in CrowdStrike to support the investigation.
The practical risk is larger than one vendor. OAuth integrations between sales, marketing, customer-support, analytics, and security tools often run with persistent access to CRM records, call notes, files, messaging platforms, and workflow data. When those integrations are treated as invisible background plumbing, a single compromised token can look less like a break-in and more like normal API traffic from a trusted app.
What Klue says happened
Klue’s public incident update says the company identified unauthorized activity affecting part of its integration infrastructure on June 12. Its investigation found that the attacker gained access through a compromised legacy credential tied to an integration service, then used that access to obtain OAuth tokens connecting Klue to certain third-party platforms.
Those tokens were then used to reach data in connected customer environments. Klue’s update names Salesforce as one of the affected third-party platforms and states that, based on the investigation so far, customer content stored inside Klue itself was not affected. The company has been sharing remediation guidance directly with impacted customers rather than publishing a universal checklist for every environment.
Salesforce separately disabled the Klue Battlecards app integration after detecting unusual activity involving the app. In coverage of the Salesforce status notice, The Hacker News reported that Salesforce characterized the issue as limited to Klue’s app connection, not a vulnerability in Salesforce’s own platform.
What data was exposed
The public impact statements so far point to sales and relationship data rather than product telemetry or customer credentials, but that still matters. CRM systems often hold names, emails, phone numbers, pricing conversations, opportunity records, contract context, renewal notes, and partner communications. That kind of data can support phishing, vendor impersonation, competitive intelligence theft, and follow-on extortion.
Huntress wrote that the copied data from its Salesforce account included business contacts, price quotes, sales-related data, messaging, product pricing data, and competitive market reports. It found no indication that threat data, customer credentials, payment card information, engineering data, or product telemetry were affected. Huntress also described the incident as a chain reaction from one compromised integration credential into token theft and then CRM data exfiltration.
HackerOne disclosed that an unauthorized party accessed and copied a set of CRM data through Klue’s OAuth integration with its Salesforce instance. The company says the impact was isolated to Salesforce data about business relationships and sales activity, and that its product and infrastructure remained secure. HackerOne disconnected the Klue integration, audited credentials and access logs, and continued a forensic review.
How the Salesforce access worked
The most useful technical detail comes from ReliaQuest, which analyzed the integration abuse and updated its report on June 22. Its researchers observed attackers authenticating through a Klue integration service account, generating OAuth tokens, and using automated Python scripts to query Salesforce through the REST API.
The activity began by enumerating Salesforce objects through /services/data/v59.0/sobjects, then looping queries through /services/data/v59.0/query and paginating results with QueryMore. ReliaQuest described extraction lasting nearly 24 hours in some activity, including one burst of almost 1,000 queries in 15 minutes and other sustained extraction windows lasting more than six hours.
That pattern matters because it is not malware-driven in the usual endpoint sense. A trusted integration account can make high-volume API calls without tripping controls built mainly around employee login anomalies, suspicious executables, or external IP reputation. If a security team cannot quickly see which connected apps have refresh tokens, what scopes they hold, and how much data they normally query, the first clear sign may be an extortion email or a vendor notification.
Why this is becoming a SaaS security problem
The Klue incident fits a broader pattern in which attackers target the connective tissue between cloud applications rather than the core platform directly. Salesforce-connected app abuse has already appeared in prior Salesloft Drift and Gainsight-related incidents, and the shared lesson is uncomfortable: non-human identities often carry durable permissions into systems that contain some of a company’s most useful business data.
These integrations are attractive because they are designed to be trusted. A competitive-intelligence tool, call-recording service, marketing platform, support system, or analytics connector may need access to accounts, opportunities, contacts, notes, files, and activity history. Over time, permissions expand, abandoned integrations linger, and old credentials remain active because disabling them risks breaking a workflow no one fully owns anymore.
The breach also shows why vendor risk reviews that stop at questionnaires are not enough. The real control question is operational: can the organization list every third-party app with OAuth access to Salesforce and other core SaaS platforms, identify the owner, justify the scopes, monitor the API behavior, rotate or revoke tokens quickly, and prove what data was reachable if the integration is abused?
What teams should check now
Organizations that use Klue should follow the company’s direct remediation guidance first, because exposure depends on the connected platforms and scopes in each customer environment. Teams that do not use Klue should still treat the incident as a useful test case for their own SaaS integration controls.
- Inventory connected apps in Salesforce and other core SaaS systems, especially integrations with refresh tokens or broad read access.
- Confirm whether each integration still has a business owner and whether abandoned pilots, prototypes, or legacy connectors remain enabled.
- Review OAuth scopes against actual need, then reduce access where the app does not require broad CRM, file, call, or messaging data.
- Search Salesforce API logs for unusual query volume, unfamiliar user agents, long-running extraction windows, unexpected QueryMore pagination, and integration-account access from unfamiliar infrastructure.
- Rotate credentials and revoke OAuth tokens for integrations that are no longer needed or cannot be confidently explained.
- Ask vendors for missing API logs when their integration could have touched sensitive records and local logs are incomplete.
- Prepare phishing and impersonation monitoring for exposed contacts, because CRM data can make follow-on social engineering more convincing even when passwords were not stolen.
Security teams should also decide where SaaS integration monitoring belongs. Identity teams may own connected apps, sales operations may own CRM workflows, and security operations may own detection rules. The Klue case cuts across all three. Without a shared owner for third-party app tokens, companies can end up with powerful machine accounts that everyone depends on and no one watches closely enough.
The takeaway
The Klue breach is a reminder that enterprise data risk increasingly lives in the links between SaaS products. Salesforce did not need to be compromised for Salesforce data to be pulled. A connected app, an old integration credential, and reusable OAuth tokens were enough to turn trusted access into an exfiltration path.
For companies with dozens or hundreds of cloud apps, the lesson is immediate: treat SaaS integrations like privileged accounts. They need ownership, least-privilege scopes, rotation, logging, anomaly detection, and a fast way to cut access when a vendor incident spills into customer environments.
