Attackers who breached Klue in June stole customer OAuth tokens and used them to query Salesforce data directly. The incident reached companies including Huntress, HackerOne and OneTrust without requiring a separate compromise of their Salesforce accounts.
Klue is a market intelligence platform whose integrations connect to customer systems. According to an investigation published by Huntress, the intruder entered Klue through a credential that had been created for a prototype integration, abandoned and left active. The intruder then installed code that collected OAuth tokens used by Klue customers.
Those tokens carried existing permission to customer data. Once the attacker held them, Salesforce processed the resulting API calls as requests from an authorized integration. This turned one old vendor credential into a route across several customer environments.
A forgotten credential found a live path
Huntress said the first signs of the Klue compromise appeared on June 11 in a system that handled connections to other software. Klue found unusual remote connections to its backend servers and code capable of collecting customer OAuth tokens. The company disabled remote access, removed the code and deactivated customer OAuth credentials while it investigated.
The abandoned prototype credential is a significant detail, though it comes from Huntress’s account of information shared during the investigation rather than a public Klue root cause analysis. Huntress described it as long disused but still active. The original project had ended without the credential being revoked.
That gap gave the attacker a foothold inside a service that stored credentials belonging to other organizations. It also explains why credential retirement needs to cover prototypes and test integrations. An unused account can retain access to production systems long after its owner has stopped thinking about it.
Figure details
A prototype credential that remained active provides remote access to Klue's backend. The attacker installs code in the integration path to collect customer OAuth tokens. Those valid tokens are then used in direct Salesforce API queries against separate customer tenants, including Huntress, HackerOne, and OneTrust. Because Salesforce accepts the integration tokens, useful detection signals come from the request source, user agent, objects queried, and request volume.
The API accepted the stolen tokens
Huntress reviewed its Salesforce logs and found that nearly all malicious requests targeted the version 59 query endpoint. Almost 900 queries carried Python user-agent strings. The activity was visible in API logs, but the authentication itself succeeded because the stolen tokens were valid.
That changes what defenders need to look for. A failed login rule will miss a request made with an authorized token. Useful detection comes from the behavior around the token: a new source network, an unfamiliar user agent, unusual objects being queried or a sharp increase in record retrieval.
The vendor also has a role in that baseline. Customers may know what data an integration should read, while the vendor knows where its service normally runs and how it calls the API. Incident response becomes slower when either side lacks the logs needed to compare the attack with ordinary use.
CRM data crossed company lines
The exposed records varied by customer, but public notices put the impact inside CRM and sales systems. Huntress confirmed that copied Salesforce data included business contacts, subscription details, pricing, sales communications and opportunity notes. It found no impact to its products, infrastructure, telemetry, passwords or payment card data.
HackerOne reported access to business contact information and sales account and opportunity records. Its products and infrastructure were unaffected, and its CRM controls prohibit customer vulnerability data from being stored there.
OneTrust said the activity took place on June 11 and 12. Its investigation found exposure limited to Salesforce business records and support-email data. OneTrust reported no access to passwords, payment cards, customer tenants or data processed in the OneTrust platform.
That scope is narrower than a compromise of each company’s core products, but sales data can still support convincing phishing and extortion. Names, deal details and internal notes give an attacker context that ordinary breach lists rarely contain.
Build an inventory that reaches the token
An application inventory is useful only when it records the access behind each name. For every connected app, security teams should know who owns it, which account and OAuth scopes it uses, whether it can issue refresh tokens, and where its API requests normally originate. The inventory should also show the last legitimate use and the steps required to revoke access.
This work needs an owner beyond procurement. Vendor approval says little about the current permissions of a service account or whether a prototype credential still functions. A quarterly review of connected apps should reach the underlying grants and sessions, with stale access removed rather than merely marked inactive in a spreadsheet.
Containment has to reach active sessions
Disconnecting an affected integration stops future use through that path, but it may leave sessions created from stolen credentials alive. Huntress advised affected organizations to consider revoking active sessions for services connected through Klue. OneTrust said it reviewed and revoked integration access, including service accounts and connected applications.
During a vendor incident, responders should capture the relevant API logs before retention windows expire, then revoke the app grant and any sessions or refresh tokens tied to it. Credentials shared with the vendor need rotation. Access should remain disabled until the expected source networks and query behavior are understood well enough to monitor.
The Klue breach reached several companies through access they had intentionally granted to one vendor. Defenders can reduce that exposure by tracing every integration down to its live credentials and watching how those credentials use the API. The work is tedious, but it is far cheaper than discovering an abandoned token inventory during an active breach.