LastPass Data Breach 2026: the Klue OAuth Attack That Hit 12 Companies at Once

LastPass has confirmed yet another data breach, its second major incident in four years.

On June 12, 2026, a hacking and extortion group called Icarus gained access to Klue, a market intelligence platform used by enterprise sales and marketing teams, using a credential that had been sitting dormant in the system since 2022. The credential was created for a third-party integration prototype that was never shipped. Nobody cleaned it up. Four years later, it became the entry point for a supply chain attack that simultaneously breached the Salesforce environments of at least 12 organisations, including LastPass, HackerOne, Recorded Future, Tanium, Huntress, ReliaQuest, Jamf, Sprout Social, Gong, Insurity, OneTrust and Snyk.

The headline went to LastPass, because LastPass has history. But framing this as a LastPass breach misses the more important story: this was a Klue breach, and LastPass was one of twelve organisations that were collateral damage in a single supply chain attack built on a ghost credential that should have been revoked years ago.

How it happened: one credential, twelve breaches

Klue is an AI-powered market intelligence platform that integrates with customers’ Salesforce environments via OAuth, the standard protocol that allows one SaaS platform to act on behalf of another. When an organisation connects Klue to Salesforce, they grant Klue an OAuth token: a digital key that allows Klue to query, read and in some cases write to their Salesforce data on their behalf, without requiring a password at each interaction.

The attackers gained initial access to Klue’s backend infrastructure using a legacy API credential created in 2022 for a prototype integration that was never launched. The integration was abandoned. The credential was not. It sat in Klue’s systems for four years, valid and unmonitored, until Icarus found it and used it to authenticate into Klue’s infrastructure. From there, they accessed the OAuth tokens Klue held on behalf of its customers and used those tokens to query customer Salesforce environments directly.

The exfiltration was methodical. Investigators observed a slow initial pull designed to blend with routine integration traffic, followed by a concentrated surge of nearly 1,000 queries in a single 15-minute window using automated Python scripts. The activity ran for approximately 24 hours, a window that is invisible to organisations without API-layer logging. Huntress and ReliaQuest, two of the affected organisations, identified the anomalous activity and notified Klue, triggering the wider investigation.

What OAuth tokens actually are and why they are dangerous

When you connect two SaaS platforms, the authorisation flow produces an OAuth token: a long-lived credential that the first platform stores and uses to authenticate its API requests to the second, without requiring a password at each interaction. Unlike a password, this token does not expire when an employee leaves or require re-authentication when a vendor’s staff changes — it persists until someone explicitly revokes it, which most organisations never do because they do not maintain an inventory of the tokens they have granted. When Icarus breached Klue, they did not attack LastPass or HackerOne directly. They inherited the OAuth tokens Klue held on behalf of its customers and used them to query twelve Salesforce environments simultaneously, presenting each token as if they were the authorised integration. No phishing, no cracked passwords, no MFA to bypass — just standing access that had never been cleaned up.

What data was taken and from whom

LastPass confirmed that customer password vaults, products and core infrastructure were not affected. What was accessed from its Salesforce environment was contact and support data:

• Customer names, email and postal addresses, phone numbers
• Support case contents and history
• Sales-related CRM records

No payment card data and no passwords were stolen across any of the twelve affected organisations. The risk is not credential compromise. It is targeted phishing. Attackers who know your name, email address and the specific details of a previous support conversation are significantly more convincing than generic phishing templates, and that is exactly the data they now hold.

The victim list makes one thing clear: this attack class does not spare sophisticated security teams. HackerOne, a platform built specifically to manage security vulnerability disclosures, and Recorded Future, a threat intelligence company, were both caught through the same Klue OAuth integration. Supply chain OAuth exposure does not discriminate by security maturity.

Who is the Icarus group

Icarus is a relatively new hacking and extortion group, believed to have launched in April 2026, that formally listed Klue on its dark web leak site on June 19 and threatened to release stolen data unless a ransom was paid. The group’s extortion emails arrived under the alias “mr bean” and directed victims to a Session Messenger ID for negotiation, with the subject line on Huntress’s email reading “top secret email” and the closing line “Do the right decision. xoxo.”

Salesforce temporarily disabled the Klue Battlecards integration entirely while the breach was investigated, warning customers that “unusual activity involving the app may have resulted in unauthorized access to a subset of customer data” — a rare and significant platform-level response that underlines how seriously the incident was taken across the ecosystem.

Early analysis flagged similarities with ShinyHunters y UNC6395, both of which have run OAuth token theft campaigns against Salesforce environments throughout 2025 and into 2026. The instinct was reasonable. The forensics did not fully support it. The Klue activity used a generic Python-urllib signature and ordinary data-centre hosting rather than the anonymising infrastructure and distinct toolchain associated with those groups. Huntress, whose own data was stolen, confirmed attribution to Icarus through two independent threads converging on the same Session Messenger ID: their internal extortion email logs and Icarus’s own public leak site, both pointing to the same identifiers at the same time. Whether Icarus has any connection to ShinyHunters remains unconfirmed.

The story got more complicated: a second hacking group emerged

The situation developed further after the initial disclosure. TechCrunch and The Next Web both confirmed the second group’s emergence through independent customer communications obtained from Klue. On June 25, Klue informed customers that Icarus appeared to be cooperating, appearing to delete the stolen data and taking down its leak site. However, simultaneously a second unnamed hacking group emerged claiming to have obtained the stolen Klue data from Icarus, reportedly by exploiting a mistake made by the Icarus operator.

This second group posted a list of allegedly affected companies on its own site, claimed 195 affected Klue customers in total, and issued its own ransom demands with significantly less professional framing: “Pay the ransom or we will leak everything if you no pay us”, suggesting a less sophisticated operation than Icarus. The group also alleged, without independent verification from TechCrunch, that Klue paid the original Icarus operator, who they described as a teenager in the UK.

Klue’s communication to customers included a striking detail: Icarus asked Klue to tell affected organisations not to pay the second group. The instruction from one extortion group to victims about another extortion group’s demands is an unusual operational dynamic that illustrates a pattern that has defined 2026 breach incidents. Stolen data does not stay with one actor. It moves between criminal groups, multiplies, and the extortion risk continues long after the original attacker is identified and contained.

Whether Icarus has genuinely deleted the data, whether the second group holds the full dataset or only samples, and whether Klue paid any ransom are questions that affected organisations cannot currently answer with confidence.

LastPass’s track record makes this harder to dismiss

LastPass has confirmed this is the eighth time customer data has been exposed since 2011. The most significant prior incident, in 2022, was a direct breach of LastPass’s own infrastructure in which attackers stole the entire store of customer password vaults. Security researchers later confirmed that vaults protected by weak master passwords were cracked offline, with stolen credentials linked to cryptocurrency thefts exceeding $150 million.

The 2026 incident is structurally different, LastPass’s own systems were not compromised and vaults were not accessed. But the pattern of repeated exposure, even through third-party vectors, makes the reassurance that “vaults are safe” harder to communicate credibly to customers who have heard variations of it before. LastPass emphasised that it will never ask for a master password and that all legitimate communications come through official channels only, a reminder that is directly relevant given that attackers now hold enough contextual information to build convincing LastPass-branded phishing campaigns.

What to do right now

Whether or not you were a Klue customer, the Klue breach is a prompt to act on OAuth credential hygiene that most organisations have deferred. Here is the priority sequence:

If you are a LastPass customer:

• Your password vault is safe. Do not change your LastPass master password out of panic, the risk is phishing, not vault compromise
• Be alert for phishing emails that reference your LastPass account, support history or the specific details of any previous support interaction. The attackers have that context
• Do not respond to or click links in communications from the domains baccarat.com.au, robinskitchen.com.au or house.com.au, these are confirmed extortion infrastructure used in this campaign
• Enable multi-factor authentication if you have not done so. LastPass vaults were not accessed in this breach, but MFA reduces exposure in any future incident
• Review your LastPass login history for any suspicious access events during June 2026

For security teams at any organisation using SaaS integrations:

• Conduct an immediate audit of all OAuth tokens your organisation has granted to third-party SaaS platforms. Most identity providers and Salesforce itself can generate a connected app and OAuth grant report
• Revoke any OAuth grants for integrations that are no longer active, were set up for prototypes or pilots that were not launched, or where the vendor relationship has ended
• Audit your legacy API credentials and service account credentials for any that are no longer actively monitored or associated with a current integration. The Klue entry point was four years old
• Implement a review cycle for OAuth grants, quarterly at minimum, that confirms each active grant is still required, still scoped appropriately, and still associated with a vendor whose security posture you are actively monitoring
• Ensure API-layer logging is active on your Salesforce and other CRM environments. The Klue exfiltration ran for 24 hours before it was flagged. Without API-layer logging, that window is invisible

Your security team has enough alerts. We send you the ones that count.

Preguntas frecuentes