A sales tool's breach exposed pricing, contacts, and deal notes at dozens of companies

In June 2026, attackers compromised the integration infrastructure behind Klue, a competitive-intelligence platform that plugs into Salesforce and Gong for a lot of B2B sales teams. The entry point wasn’t a zero-day or a phishing email that tricked an executive — it was a legacy credential, created years earlier for a prototype integration, that was never revoked after the prototype was abandoned. That one dormant key was enough to push malicious code into Klue’s backend, harvest OAuth tokens for every customer’s connected Salesforce instance, and run roughly 1,000 API queries in fifteen minutes to pull data out at scale.

By mid-July, dozens of companies — including Huntress, Recorded Future, Tanium, Jamf, Sprout Social, and Gong itself — had confirmed impact. Trade-press coverage from the following weeks put the total number of exposed organizations at roughly 200, with the list of publicly named victims continuing to grow well past the initial disclosure. This is one of those incidents where the headline number keeps moving for weeks after the story first breaks, because affected companies notify on their own timelines.

What actually left the building

Most breach coverage defaults to counting Social Security numbers or credit card digits. This one is worth reading closely because what got exfiltrated was different: not identity documents, but the operational contents of a sales pipeline.

Reported categories of exposed data include business contact records — names, email addresses, phone numbers, job titles — plus pricing quotes, sales account notes, CRM records, and internal sales communications. In plain terms: not just who your prospects are, but what you told them, what you offered them, and what they told you back.

For anyone running B2B outbound or managing pipeline through Salesforce, this is the closest a breach has come recently to leaking the thing you actually protect for a living: not just contact info, but context — who’s close to closing, what price they were quoted, what objection they raised last call.

Not the first time. Not the last.

The attack pattern here — a legacy, unscoped credential inside a connected integration, quietly compromised and used to pull CRM data through a trusted API — isn’t new. It’s close kin to the account-takeover mechanics documented in other recent breaches this year: the initial compromise is small and boring, the damage comes from what that small compromise had access to.

It’s also not the first time a sales-adjacent SaaS integration has been the way into hundreds of companies’ Salesforce data. A comparable supply-chain attack against a different sales-engagement integration hit hundreds of organizations in 2025, using the same basic shape: a trusted OAuth connection into Salesforce, compromised once at the vendor level, used to reach every customer downstream without touching Salesforce’s own infrastructure at all. Two incidents, roughly a year apart, both rooted in the same mechanism, are enough to call this a pattern rather than a fluke — attackers have found that it’s more efficient to compromise one well-connected integration vendor than to individually target hundreds of companies’ CRMs, and the economics of that trade only get better as more sales teams connect more tools to their CRM.

That’s the uncomfortable part for anyone running a modern sales stack. A typical outbound team today connects a CRM to an enrichment tool, a competitive-intelligence platform, a calling tool, a scheduling app, a Slack bot, and increasingly an AI agent with its own API key — and every one of those connections is a credential someone has to actually remember exists. Klue wasn’t a careless company; it was a mid-sized SaaS vendor with a real security program that still had one forgotten key sitting active for years. That’s the median case, not the exception, across the industry right now.

Why this specific data has a longer shelf life than a password

Stolen passwords lose value fast once a breach is disclosed — the affected accounts get forced to reset, and the leaked credentials become mostly worthless within days. Pricing quotes and deal notes don’t expire on the same schedule. A competitor who obtains a leaked pricing sheet can use it in a bid six months from now just as easily as six days from now. A prospect whose specific objections and internal budget discussion got exposed doesn’t get to “reset” that the way they’d reset a password. That’s the uncomfortable asymmetry with this category of breach: the operational data has a longer useful life to whoever holds it than almost anything else that typically gets stolen, which is exactly why it’s worth treating differently in how you think about what your own connected tools have access to — not just “could this leak PII,” but “could this leak the substance of a live negotiation.”

What to actually do about it

If you run a CRM-connected sales stack, this incident is worth an afternoon of housekeeping regardless of whether Klue specifically is in your stack:

• Inventory every OAuth-connected app touching your CRM. Most CRM admin panels have a “connected apps” page nobody has opened since setup. Open it.
• Kill anything you don’t recognize or don’t remember approving. A credential that’s been silently sitting there for two years is exactly the profile of the one that got Klue’s customers hit.
• Ask new vendors, before you connect them, what data their integration can actually read. Scoping any API key to the narrowest permission it needs is the single highest-leverage habit here — a token that can only read contact names can’t leak pricing and deal notes even if it’s compromised.
• Treat “we revoked the credential” as step one, not step done. Rotating a key after a breach stops the bleeding; it doesn’t undo what already left through it.

Where Norbelys draws the line differently

The pattern behind the Klue breach is a general lesson about integration sprawl, and it’s exactly why Norbelys keeps campaign data, audience management, and sending in one system instead of asking you to wire together a pile of point tools each holding their own copy of your pipeline. Fewer connected surfaces means fewer forgotten keys to eventually go stale.

Mailbox and integration credentials on Norbelys are encrypted at rest and never returned by the API once stored — a design choice made specifically so that a compromised third-party tool downstream can’t turn into a way to read your sending credentials back out. If you’re consolidating your outbound stack after reading something like this, see what’s actually included at each pricing tier — warmup, DMARC monitoring, and verified analytics ship on every plan rather than living behind a separate integration you’d have to grant yet another OAuth token to. Start sending from a stack with fewer doors to leave unlocked.

The Klue breach — quick answers

What is Klue and why did a breach there affect other companies?+

Klue is a competitive-intelligence platform that connects to sales tools like Salesforce and Gong to pull in deal context. Because it held OAuth tokens for each customer's connected CRM, a breach of Klue's own infrastructure gave attackers a path into every customer's Salesforce data, not just Klue's own systems.

What data was exposed in the Klue breach?+

Reported categories include business contact records (names, emails, phone numbers, job titles), pricing quotes, sales account notes, CRM records, and internal sales communications, pulled from customers' connected Salesforce accounts via the compromised integration.

How many companies were affected?+

Reporting through July 2026 put the number of exposed organizations at roughly 200, with several dozen publicly named, including Huntress, Recorded Future, Tanium, Jamf, Sprout Social, and Gong. The list of named victims continued to grow for weeks after the initial disclosure.

What's the practical takeaway if I don't use Klue?+

Audit every OAuth-connected integration touching your CRM, remove anything unused, and scope every remaining integration's permissions as narrowly as possible. The specific vendor changes each time this kind of breach happens; the root cause — a forgotten, over-permissioned credential — repeats.