# Salesforce Disables Klue Integration After OAuth Token Abuse Exposes Customer CRM Data


Salesforce has pulled the plug on the Klue Battlecards competitive intelligence app integration following a sophisticated OAuth token theft attack that gave threat actors unauthorized access to customer Salesforce environments. The incident, which began with a compromised legacy credential at Klue, represents a concerning escalation in supply chain attacks targeting enterprise SaaS ecosystems.


## The Threat


On June 11, 2026, Klue discovered unauthorized activity affecting its integration infrastructure—specifically, attackers had gained access to a long-dormant but still-active credential used for prototype development. The threat actor, operating under the name Icarus, leveraged this access to inject malicious code that harvested OAuth tokens from Klue's platform. Those stolen tokens subsequently provided direct access to connected third-party systems, including Salesforce instances of multiple Klue customers.


Among the confirmed victims is Huntress, a prominent cybersecurity company. On June 16, 2026, Huntress employees received extortion emails with the subject line "top secret email" demanding contact within 48 hours, claiming that "Your Salesforce data has been downloaded."


The attack exposed sensitive business information including:

  • Business contact information
  • Price quotes and sales data
  • Internal messaging and communications

  • Huntress confirmed that the breach was limited to Salesforce-connected data and did not compromise threat intelligence, passwords, payment card information, or any engineering data related to its security products.


    ## Background and Context


    Third-party app integrations have become a critical backbone of modern enterprise operations, allowing platforms like Salesforce to connect seamlessly with specialized tools. However, this interconnectedness creates what security researchers call the "OAuth supply chain risk"—when a single integration platform is compromised, the fallout extends to every connected customer.


    Klue, which provides competitive intelligence and battlecard generation features within Salesforce, serves dozens of enterprise organizations. The company's integration infrastructure acts as a trusted conduit between its platform and customer CRM systems, making it an attractive target for sophisticated threat actors.


    The Root Cause: The attack exploited what Klue described as a "long-disused but still active credential" originally created for internal prototyping of a third-party integration that the company later abandoned. This illustrates a persistent hygiene problem in modern security: legacy credentials from deprecated projects often remain active, creating dormant backdoors.


    ## Technical Details


    The attack unfolded in distinct phases:


    ### Initial Compromise

    The threat actor used the abandoned credential to gain initial access to Klue's integration service. This entry point provided limited but sufficient permissions to move laterally within the infrastructure.


    ### Token Harvesting

    Once inside, the attacker injected code designed to intercept and exfiltrate OAuth tokens generated by Klue's platform. These tokens are the cryptographic keys that allow Klue to act on behalf of customers within their Salesforce environments—making them extraordinarily valuable to attackers.


    ### Customer Environment Access

    Using the stolen tokens, the attacker executed automated Python scripts (identifiable by Python-urllib user-agent strings) to query customer Salesforce instances directly. This allowed them to enumerate available data and perform targeted exfiltration.


    ### Data Exfiltration

    The threat actor selectively accessed sales and business data from multiple customer environments, focusing on high-value business intelligence rather than technical or security-related data.


    Timeline:

    | Date | Event |

    |------|-------|

    | June 11, 2026 | Salesforce security teams detect unusual Klue app activity |

    | June 12, 2026 | Klue detects unauthorized activity in its integration infrastructure |

    | June 16, 2026 | Huntress and other victims receive extortion demands |

    | June 19, 2026 | Salesforce disables Klue app integration platform-wide |


    ### Response Measures


    Both Klue and Salesforce have implemented immediate containment:

  • Credential revocation: All affected OAuth tokens and legacy credentials have been revoked
  • Code removal: Unauthorized code injection has been eliminated
  • Access termination: Remote access utilized by the threat actor has been disabled
  • Integration suspension: Affected third-party integrations have been disabled pending comprehensive investigation
  • Platform-wide disable: Salesforce has disabled the Klue integration entirely until further notice

  • ## Implications for Organizations


    This incident carries several troubling implications for enterprises relying on SaaS integrations:


    ### Supply Chain Vulnerability at Scale

    When a single integration platform is compromised, the blast radius extends to all downstream customers simultaneously. Organizations using Klue had no direct way to detect or prevent access to their Salesforce data—the compromise occurred at the integration provider level, bypassing customer-side security controls.


    ### OAuth Token Abuse as an Attack Pattern

    The attack mirrors recent campaigns targeting Salesforce environments through other integration compromises, including the Salesloft and Drift incidents documented by ReliaQuest. This represents a deliberate shift in threat actor tactics: rather than targeting Salesforce directly, attackers are systematically compromising trusted integration partners to gain OAuth token access.


    ### Persistence of Legacy Credentials

    The use of an abandoned prototype credential highlights a critical operational security gap. Many organizations fail to properly decommission credentials associated with deprecated projects, leaving dormant backdoors in their infrastructure. This is particularly dangerous in integration services, where these credentials may retain broad permissions.


    ### Extortion and Data Monetization

    The Icarus group's shift from data theft to extortion represents an evolution in threat actor business models. Rather than selling stolen data on underground forums, groups are increasingly demanding ransoms directly from victims, using the threat of data publication as leverage.


    ## HackWire Analysis


    This incident exemplifies a dangerous blind spot in enterprise security: the assumption that third-party integrations operate within the security perimeter of the vendor, not the customer. In reality, OAuth-based integrations create a shared trust model where the vendor's security posture directly determines customer exposure.


    The broader pattern is clear. Over the past 18 months, we've seen repeated successful attacks following the OAuth integration playbook: compromise a trusted SaaS provider, harvest OAuth tokens from their infrastructure, then systematically access downstream customer environments. Salesloft, Drift, and now Klue. Each incident affects hundreds or thousands of customers simultaneously, yet many organizations treated them as isolated events rather than symptoms of a systemic vulnerability.


    What makes this particularly insidious is that customers had zero visibility into the attack. Security teams at Huntress and other victims couldn't have detected this compromise through their own Salesforce audit logs or access controls—the breach happened upstream, at the integration provider. This is supply chain risk at its most consequential: you cannot fully control your own security posture when third-party vendors control critical data access channels.


    The use of a legacy credential—one associated with an abandoned prototype—points to another endemic problem: credential lifecycle management at most organizations remains abysmal. In the rush to build and deploy, teams create service accounts for experiments, then forget to disable them when those experiments conclude. These dormant credentials accumulate over time, creating an expanding attack surface that nobody properly inventories.


    For defenders, the practical lesson is uncomfortable: assume your integrations will eventually be compromised, and architect accordingly. This means implementing OAuth token rotation policies, enabling integration-specific audit logging, requiring multi-factor authentication for integration setup, and regularly reviewing which third-party platforms have access to your CRM. Most importantly, organizations should demand that vendors implement mandatory credential decommissioning for deprecated projects—treating this as a contractual requirement, not a suggestion.


    The Icarus group's relatively low profile (only two claimed victims as of mid-June) suggests they may be opportunistic actors who discovered this vulnerability independently. What matters now is whether other groups replicate their success. Betting against it would be naive.


    — HackWire Editorial


    ## Recommendations


    For Salesforce Customers:

  • Immediately audit all installed integrations and verify they're actively maintained by their vendors
  • Review Salesforce's audit logs for unusual API activity from third-party integrations, particularly around June 11-12
  • Confirm that all legacy or experimental OAuth tokens have been revoked from integrated applications
  • Implement integration-specific alerts for bulk data access or unusual query patterns
  • Consider enabling Salesforce Shield or equivalent for enhanced audit and monitoring capabilities

  • For Integration Vendors:

  • Implement mandatory credential decommissioning for all deprecated projects, with enforcement through automated tooling
  • Rotate OAuth tokens on a regular schedule (quarterly minimum) for all active integrations
  • Deploy code integrity verification to detect unauthorized injection of malicious code
  • Maintain a comprehensive inventory of all service credentials, their creation date, and last usage date
  • Require multi-factor authentication for any code deployment to integration infrastructure

  • For Security Teams:

  • Conduct an immediate review of all third-party OAuth integrations in your environment
  • Map the permissions granted to each integration and assess whether they align with current business needs
  • Implement granular logging for integration-based access to sensitive data
  • Establish incident response protocols specifically for OAuth token compromise scenarios
  • Consider network segmentation to limit what compromised integrations can access

  • ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)