A third-party supplier becomes an entry point
On 12 June 2026, Klue detected unauthorized activity in part of its integration infrastructure. According to its investigation, an attacker compromised an old credential associated with an integration service and then obtained OAuth tokens used to connect Klue to some customers’ environments.
On 23 June, LastPass confirmed that systems connected to Klue were affected. The tokens enabled access to customer data in its Salesforce environment: names, phone numbers, email and physical addresses, as well as support and sales data.
The distinction matters: LastPass says its products, infrastructure, and customer vaults were not affected. The incident still shows how data can leave an ecosystem through a peripheral tool with legitimate access.
OAuth is a relationship of trust to review
OAuth often avoids sharing a password between two services. That is useful, but the token given to the application becomes an authorization that can be used. Its security therefore also depends on the supplier that stores it, its rotation process, and the scope of the permissions granted.
In the Klue case, the token did not open a password vault. It provided access to what the integration could reach in connected business tools. For an SMB, that distinction leads to better questions: which data is accessible, from which account, for how long, and with what audit trail?
Practical lessons for a small team
- Inventory applications connected to CRMs, support tools, email, and file storage.
- Remove unused integrations and reduce permissions to what is strictly necessary.
- Plan token revocation and rotation, with a procedure known before an incident.
- Monitor unusual connections and large data exports.
- Do not put critical secrets in shared documents or multiple uncontrolled copies.
An integration is not just a feature: it is another access path. Reviews should focus on the data that can actually be reached, not only on the service considered primary.
Reduce copies around sensitive credentials
This incident does not mean a local vault eliminates the risk from a compromised third-party supplier. It reinforces the need to avoid adding unnecessary copies and dependencies around secrets.
Soclyde follows this local-first approach: generate a unique credential for each service, keep it in a local encrypted vault, and share only what authorized people need. This does not protect a compromised SaaS integration, but it limits reuse and duplication that can widen the consequences of a breach.
What to remember
A supply-chain attack can bypass an organization’s visible boundaries: the attacker does not necessarily break the service being watched, but exploits trust granted to a connected supplier.
For an SMB, the response combines regular integration mapping, least-privilege permissions, rapid revocation, and unique credentials kept in an environment under control. Talk to Soclyde about your password strategy.
