.webp)
On June 12, 2026, Klue - a market intelligence platform used by sales teams at hundreds of companies - discovered attackers had broken into their integration infrastructure. What makes this breach worth paying attention to isn't the scale. It's the method.
The attackers didn't breach a firewall or exploit some obscure zero-day. They used a forgotten password on a service account - one that still had access to OAuth tokens connecting Klue to its customers' Salesforce environments. Within 15 minutes, those tokens had been used to run nearly 1,000 Salesforce API queries, pulling out contact names, email addresses, price quotes, and sales communications from at least nine organizations.
Those nine organizations included Huntress, HackerOne, Jamf, OneTrust, and Recorded Future - companies that build and sell cybersecurity tools professionally.
If that attack vector can reach companies like those through a third-party integration, it can reach your business too. Here's what actually happened, and what you can do about it today.
What Happened at Klue
Klue sells competitive intelligence software. Sales teams use it to track competitor pricing and positioning, and it integrates with platforms like Salesforce, HubSpot, Google Drive, Slack, and Zoom to pull in relevant business data automatically. Those connections work through a system called OAuth.
OAuth is how software authorizes access without sharing passwords directly. When your team connects a new tool to Salesforce, instead of handing over your Salesforce login, OAuth generates a token - a cryptographic key - that gives the third-party app permission to access specific data. It's convenient, widely used, and when properly managed, reasonably secure.
According to Klue CEO Jason Smith, an attacker gained access through a "compromised legacy credential associated with an integration service." Plain translation: there was an old service account password that hadn't been rotated. Someone obtained it.
From there, the attacker pushed a malicious code update into Klue's integration infrastructure. That update harvested OAuth tokens already stored in Klue's systems - the authorization keys connecting Klue to customer platforms. Armed with those tokens, the attacker logged directly into affected Salesforce environments as if they were Klue itself, with full permissions Klue had been granted.
Reporting from The Hacker News confirmed that Salesforce detected unusual activity and disabled the Klue Battlecards app integration entirely. Salesforce noted the issue was not a vulnerability in Salesforce - the attacker simply had valid authorization tokens. Klue revoked affected credentials, disabled integrations, and engaged CrowdStrike for incident response.
The threat actor, a group called Icarus, has claimed responsibility and threatened to publish the stolen data unless a ransom is paid.
Why This Should Matter to Businesses Not Using Klue
The specific victim here was Klue. But the attack pattern - compromised service credential leads to OAuth token theft leads to third-party data access - is not specific to Klue at all. It describes a vulnerability class that affects any business with SaaS integrations.
Think about the software your business runs. A CRM connected to your email marketing tool. Accounting software synced to your bank. A project management app integrated with Slack. A help desk platform tied to your Google Workspace. Each of those connections is an OAuth relationship, and each one is a potential exposure point if the vendor on the other end handles their credentials poorly.
The nine organizations breached didn't choose to have a security dependency on Klue's credential hygiene. But by granting Klue's platform OAuth access to their Salesforce environments, they accepted that dependency whether they realized it or not.
That's the uncomfortable reality of a deeply integrated SaaS stack: your security posture is partly determined by the internal security practices of every vendor you've authorized. You control your own environment, but you don't control theirs.
Do You Know What's Connected to Your Business Accounts?
Most business owners would struggle to name every app that currently has OAuth access to their Google Workspace or Microsoft 365 tenant. That's not unusual - these permissions accumulate quietly. An employee tries a new tool, clicks "Authorize," and never revisits it. The tool might stop being used within a year. But the OAuth access often stays active indefinitely.
Here's how to audit what's connected to your key platforms right now:
Google Workspace
Open admin.google.com and navigate to Security > API Controls > Manage Third-Party App Access. You'll see every application with access to your organization's Google data, what permissions each app holds, and how many users authorized each one. Focus on apps you don't recognize, haven't used recently, or that have broader permissions than they need.
Microsoft 365
Go to the Entra admin center at entra.microsoft.com and navigate to Applications > Enterprise Applications. Filter by "Third-party" under Application type. Review each app's permissions and the "last used" date. Long-idle apps with broad permissions are the first ones to remove.
Salesforce
In Salesforce, go to Setup > Connected Apps OAuth Usage. You'll see which apps have active OAuth connections, how many users are using each, and the last activity date. Anything with a stale last-used date and significant data access permissions deserves a second look.
A full network security audit will surface OAuth connections and service accounts across your whole environment - not just the platforms you think to check manually.
The Problem with Legacy Credentials
The word "legacy" makes this sound like a problem for organizations running 20-year-old mainframes. It isn't. A credential becomes legacy the moment it stops being actively managed - and that can happen in any business within a couple of years.
Here's how it plays out. An IT admin or developer sets up a service account to integrate two platforms. That person changes roles, leaves the company, or just moves on to other priorities. The integration keeps running without issue, so nobody touches it. No one changes the password. No one reviews whether the account still needs the access level it was originally given. A year or two later, if that credential leaks - through phishing, a vendor breach, or a credential stuffing attack - the attacker has a working key to a live integration.
Service accounts are particularly vulnerable because they're often set up with broader permissions for convenience, and they may not have multi-factor authentication configured. They're also less likely to trigger account lockout policies, since they're expected to authenticate automatically and at high frequency.
Reviewing and rotating service account credentials on a regular schedule - and decommissioning accounts that are no longer needed - is one of the higher-value security maintenance tasks that consistently gets pushed aside. The Klue breach is a clear example of what happens when it does.
Five Practical Steps to Reduce Your Exposure
You don't need to overhaul your entire tech stack to address this meaningfully. These five steps are concrete and achievable for most small and mid-sized businesses.
1. Run an OAuth audit now, then schedule it quarterly. Use the steps above for Google Workspace, Microsoft 365, and Salesforce. Set a calendar reminder. Thirty minutes per quarter is enough for most organizations with fewer than 100 employees.
2. Rotate service account credentials on an annual schedule at minimum. Every account being used for automated integrations - regardless of whether it's been involved in any incident - should have a defined password rotation schedule. A vulnerability management program can track this across your environment so nothing falls through the cracks.
3. Enforce least-privilege access on every integration. When authorizing a third-party tool, grant the minimum permissions the integration actually requires. If a tool only needs to read contact names and emails, don't authorize full CRM write access. Periodically check whether existing integrations still need all the permissions they were originally granted.
4. Revoke OAuth access before closing accounts with connected tools. When your business stops using a SaaS tool, go to the OAuth settings in your connected platforms and revoke that app's access before canceling the subscription. If you've already canceled without revoking, check your OAuth audit for orphaned permissions.
5. Monitor vendor security disclosures. Every major SaaS vendor has a security status page and most will email affected customers when incidents occur. Make sure someone on your team is actually watching for these notifications - not letting them sit unread. In the Klue case, the company notified affected customers the same day the breach was detected, June 12. Organizations that acted quickly could revoke integrations before significant damage occurred.
When to Get Outside Help
Auditing OAuth permissions across Google, Microsoft, Salesforce, and whatever else your business uses - and then maintaining that visibility consistently over time - is more than most internal teams have bandwidth for. Most SMBs don't have a dedicated security person tracking this stuff full-time, and that's a reasonable reality, not a failure.
A managed cybersecurity service handles this as part of standard operations - keeping an inventory of connected apps, monitoring for unusual API activity, managing service account lifecycles, and flagging vendor security disclosures before they become your problem. It's the kind of ongoing hygiene work that prevents the Klue scenario from becoming your scenario.
If you're not sure where your current exposure stands, a security consultation is a practical first step. We can review your SaaS stack, identify high-risk integrations, and help you build a straightforward maintenance plan.
At Burgi Technologies, we work with businesses across Orange County - car dealerships, medical practices, legal firms, and general commercial businesses - on exactly this kind of security work. If you'd like to talk through what this looks like for your specific setup, we're happy to help. Reach us at (949) 381-1010 or through our contact page.
Frequently Asked Questions
What is an OAuth token and why can it be a security risk?
OAuth is an authorization standard that lets one application access data in another on your behalf - without sharing your actual password. When you click "Connect to Salesforce" or "Sign in with Google," you're creating an OAuth relationship. The token is what proves that authorization. If someone steals that token, they can access your data in the connected platform without ever needing your password, and without triggering MFA because they're using a pre-authorized credential. The risk grows when tokens are long-lived, broadly scoped, and not actively monitored.
How do I know if my business was affected by the Klue breach specifically?
If your business uses Klue and connected it to Salesforce or another platform via OAuth, you should have received direct notification from Klue - they contacted affected customers on June 12, the same day the breach was detected. If you're unsure, log into your Klue account and check Security Settings for connected integrations, and check your email for security notifications from Klue between June 12 and 22. You can also check your Salesforce Connected Apps OAuth Usage page for any recent activity from the Klue integration.
Does multi-factor authentication protect against this type of attack?
MFA helps protect your accounts from direct login attacks, but it doesn't protect against OAuth token theft from a vendor's infrastructure. Once an OAuth token has been issued and is stored on a third-party platform, an attacker who compromises that platform can steal the token itself - bypassing MFA entirely, because they never need to log into your account directly. The right defenses here are limiting what tokens can access (least privilege), monitoring unusual API activity, and revoking tokens from vendors who experience breaches.
How often should small businesses audit their connected apps?
Quarterly works well for most SMBs and doesn't require significant time once you know where to look. Beyond the quarterly schedule, run an audit whenever an employee leaves, when you stop using a software tool, or when a vendor notifies you of a security incident. The point is making it a routine rather than waiting for a reason to check.
What's the difference between a supply chain attack and someone hacking us directly?
A direct attack targets your systems specifically. A supply chain attack targets a vendor, partner, or software provider you rely on - and uses that access to reach you indirectly. In the Klue case, attackers didn't target Huntress or HackerOne directly. They compromised Klue, and then used Klue's pre-authorized access to those companies' Salesforce environments. Supply chain attacks are harder to block purely through your own controls because the initial compromise happens somewhere outside your environment.
