In June 2026, a hacking group known as ShinyHunters published a large trove of data taken from Madison Square Garden Entertainment. Among the files was what WIRED later described as a talent database tracking close to 40,000 public figures who had attended events at the venue, alongside a second and far larger set of roughly 10.5 million customer records drawn from the company's Salesforce system (Source: WIRED; Source: Digital Music News). WIRED reported that some entries carried "risk" ratings, notes on individuals' social media activity, and sensitive demographic categories such as race and sexual orientation (Source: WIRED). Madison Square Garden has disputed that characterization and filed a defamation lawsuit, arguing the fields were part of ordinary customer relationship management rather than any discriminatory list (Source: Fox News).
The public conversation has focused on the celebrity angle and the legal fight. For technology leaders, a different story sits underneath it, in how the data was taken and what it reveals about the risk any organization carries inside its CRM.
How did the breach happen?
The intrusion did not rely on a flaw in Salesforce itself. Google's Threat Intelligence Group has been direct on this point, attributing the wider campaign to social engineering rather than any vulnerability in the platform (Source: Google Threat Intelligence Group). ShinyHunters ran a sustained operation from mid-2025 into mid-2026 that reached dozens of large organizations, and the method was consistent. Attackers placed phone calls to employees while impersonating internal IT support, a technique known as voice phishing or vishing, and walked those employees through approving a malicious connected application inside their Salesforce environment (Source: Microsoft). Once an employee granted consent, the attacker's app received OAuth tokens that allowed it to query and export CRM records with that employee's own permissions (Source: Rescana).
That design is what makes the attack so difficult to catch. Because the access arrives through a real user who approved a legitimate-looking app, the activity reads as ordinary use, and conventional sign-in and authentication monitoring barely registers it (Source: The Hacker News). What matters is what the connected app does once it is inside, and most CRM logging was never built to surface that behaviour.
A second path made the problem larger. Several victims were reached through trusted third-party integrations, where attackers abused OAuth tokens from compromised vendor tools that already held standing access to customer Salesforce data (Source: Microsoft). Every integration connected to a CRM becomes part of that system's security perimeter, and a token issued to a vendor carries as much power as the access it was granted.
One detail matters for anyone relying on multi-factor authentication as a backstop. The vishing used in this campaign is effective against the second factors most organizations depend on, including SMS codes and authenticator prompts, because the attacker persuades the employee to complete the approval in real time. Microsoft's guidance points organizations toward phishing-resistant methods such as hardware security keys and passkeys, which hold up where those weaker factors fail (Source: Microsoft).
Why this is an enterprise problem, not just a celebrity row issue
Every organization running a CRM holds a version of the same risk. The Madison Square Garden case is vivid because of who was in the database, and the underlying exposure is universal. CRMs accumulate far more than names and contact details. Over years they gather behavioural notes, internal commentary, risk flags, and demographic information, entered by many hands and rarely reviewed. When that system is breached, everything inside it becomes public at once, including fields whose existence the organization may have forgotten, and internal notes never meant to be read outside the company.
This is where the social dimension becomes a business dimension. WIRED's reporting drew attention because the records reportedly included sensitive demographic categories and subjective judgments about individuals (Source: WIRED). Whether or not one accepts that framing, and Madison Square Garden strongly disputes it, the reputational and legal consequences arrived the moment the data was exposed. The defamation suit, a separate class action already filed over the breach, and the ongoing news cycle are all downstream of two decisions that predated the attack by years, which are what the company chose to record and how loosely that record was governed (Source: Digital Music News).
For any enterprise, the lesson is that data you collect is data you can be forced to defend. A field that felt harmless when someone added it to a customer record can become the center of a public controversy if the system is ever compromised.
What should enterprises do about it?
The organizations that came through this campaign intact were the ones watching for the activity that authentication logs miss. Closing this exposure takes work across governance, identity, and detection.
Govern what goes into the CRM. Review the fields your CRM captures and remove sensitive or subjective categories that serve no operational purpose. Data that is never collected cannot be leaked, and demographic or opinion fields carry a risk that rarely justifies their value.
Verify identity before acting on IT requests. Because the entry point was an employee approving a request over the phone, a simple out-of-band verification rule closes most of it. Any request to install a connected app, change an integration setting, or modify permissions should be confirmed through a second known channel before anyone acts.
Govern OAuth and connected apps. Maintain an allowlist of approved connected applications, require review before new ones are authorized, and revoke tokens for integrations no longer in use. A vendor integration with CRM access deserves the same scrutiny as a privileged internal account.
Adopt phishing-resistant authentication. Move privileged and administrative access to hardware security keys or passkeys, since a convincing phone call can defeat the second factors most organizations rely on today.
Watch behaviour, not just logins. Because this attack looks like normal use at the authentication layer, detection must focus on what accounts and apps do after they are inside. Unusual query volumes, bulk exports, and access patterns that deviate from an established baseline are the signals that expose an approved app quietly pulling millions of records.
Where Quick Intelligence fits
Our Managed Threat Detection and Response service exists for exactly the gap this breach exploited. It correlates behaviour across your environment, including CRM and connected SaaS platforms, establishes a baseline for normal activity, and escalates the behaviour that looks legitimate right up until it is not to our 24/7 Canadian-based SOC.
If you want to understand where your own environment has visibility gaps before an attacker does, our complimentary Security Infrastructure Resilience Assessment maps your current controls and shows you where the exposure sits. Start at quickintel.com/assessment/security-infrastructure-resilience-assessment or reach us at sales@quickintel.com.
