Skip to content
HACKTECH
Cloud & identityReported Published 6 sources

Klue breach: stolen integration OAuth tokens used to pull customers' Salesforce data

Competitive-intelligence vendor Klue said it identified unauthorised activity affecting part of its integration infrastructure on 12 June 2026, and disclosed the incident publicly in an 18 June statement. According to a CrowdStrike investigation summarised by Klue, an attacker used a previously compromised GitHub personal access token on 11 June to insert code into Klue's integration service and collect OAuth access and refresh tokens for Salesforce, which were used to pull CRM data from connected customer environments. Huntress, Recorded Future, Tanium, Jamf, Sprout Social, Gong and Insurity were among the organisations that disclosed impact, and Huntress attributed the attack with high confidence to an extortion group calling itself Icarus.

  • OAuth
  • Salesforce
  • SaaS-to-SaaS access
  • third-party risk
  • token theft
  • GitHub personal access tokens
  • Icarus

What the sources report

  • Klue's summary of the CrowdStrike investigation, completed 30 June 2026, says the attacker used a previously compromised GitHub personal access token on 11 June to introduce unauthorised code into the integration service; CrowdStrike did not identify how the token was initially obtained.
  • Huntress said the threat actor seems to have used a 'long-disused but still active credential' that Klue originally created to prototype a third-party integration it later abandoned.
  • Klue says Salesforce notified it on 12 June of suspected unauthorised activity originating from Klue's API integration service and that, the same morning, Klue disabled the affected GKE pods and the compromised GitHub PATs and rotated OAuth credentials; CSO Online reported that Salesforce disabled the Klue Battlecards integration and said the issue 'does not arise from a vulnerability within the Salesforce platform'.
  • Huntress reported that Klue temporarily disabled integrations with Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive and Slack App while it investigated.
  • Huntress said effectively all malicious Salesforce requests targeted /services/data/v59.0/query/ and nearly all carried a User-Agent of '5238' or a blank value, and it listed 811 'Python-urllib/3.12' and 58 'Python-urllib/3.14' requests; ReliaQuest, which published its analysis on 17 June, reported automated scripts pulling CRM records through the Salesforce REST API over roughly 24 hours.
  • According to Huntress, Icarus listed Klue on its leak site on 19 June and listed data for Huntress and several other Klue-affected companies on 22 June.

What it means for your organisation

Klue held OAuth access and refresh tokens into its customers' Salesforce orgs, so one long-disused but still active credential at the vendor became a route into multiple customers' CRM tenants through access those customers had legitimately granted. Huntress, as reported by CSO Online, said the activity matched the OAuth-abuse pattern behind the 2025 Salesloft Drift and Gainsight compromises, and ReliaQuest drew the same comparison with Salesloft Drift. Each connected app is effectively a privileged identity: it needs an owner, least-privilege scopes, limits on where its tokens can be used from, and API-level logging that can tell a bulk export from routine sync.

What we check

  • Inventory connected apps and OAuth grants in Salesforce, Microsoft 365, Google Workspace and Slack, recording scopes, owner, token age and last use, and remove or re-scope anything dormant.
  • Verify integration users run with least-privilege profiles and that connected apps enforce IP restrictions, so a stolen refresh token fails when replayed from attacker infrastructure.
  • Review Salesforce API and event logs for bulk /query activity, scripted user agents such as Python-urllib, and volume spikes from integration accounts, and turn these into alerts.
  • Ask SaaS vendors how they store customer OAuth tokens, whether long-lived personal access tokens are blocked in their CI/CD, and how quickly they can revoke tokens per customer.
  • Rehearse a third-party token-theft scenario: token and session revocation order, log requests to the vendor, notification duties, and warnings about follow-on phishing using stolen contact data.
  • An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.