Reviewed by: Mansoor Ali, Technical Editor, PenPonder | Last Updated: July 2026
In May 2024, hackers stole 1.3 terabytes of data from Ticketmaster. The breach exposed the personal information of approximately 560 million customers worldwide. Names, addresses, phone numbers, email addresses, order histories, and partial payment card information were all compromised.
By July 2026, class action lawsuits are ongoing, settlement negotiations are underway, and Ticketmaster’s parent company Live Nation faces regulatory scrutiny across multiple jurisdictions.
The breach is significant not just for its scale but for its cause. It did not start with a sophisticated zero-day exploit. It started with a third-party cloud vendor and missing multi-factor authentication. Both of these failures are common. Both are preventable.
What Actually Happened
The Timeline
May 20, 2024: Ticketmaster’s IT team detected unauthorized activity in a third-party cloud database hosted by Snowflake, a cloud data services provider used by Ticketmaster for storing and analyzing customer data.
May 27, 2024: Hacker group ShinyHunters claimed responsibility for the breach. They announced they had stolen 1.3 terabytes of data containing records for approximately 560 million Ticketmaster customers. They attempted to sell this data on dark web forums for $500,000.
May 29, 2024: Ticketmaster publicly confirmed the breach through a filing with the U.S. Securities and Exchange Commission. The filing came nearly two weeks after detection, drawing immediate criticism for delayed disclosure.
Late June 2024: Ticketmaster began notifying affected customers. The notification came approximately five weeks after Ticketmaster first confirmed the breach publicly, and nearly six weeks after detection. Under GDPR requirements for EU customers, notification should occur within 72 hours of discovering a breach. The timeline drew regulatory scrutiny in multiple jurisdictions.
Mid-2025 to present: Multiple class action lawsuits proceed through discovery phases. Settlement negotiations are underway but no formal agreement has been reached as of July 2026.
How the Attackers Got In
The entry point was not Ticketmaster’s own systems. It was Snowflake, the third-party cloud vendor Ticketmaster used for data storage and analytics.
Snowflake itself was not hacked in the traditional sense. The attackers obtained legitimate credentials for Ticketmaster’s Snowflake account through infostealer malware that had previously infected devices used by Ticketmaster employees or contractors. These stolen credentials were then used to log into the Snowflake environment directly.
The critical failure: Ticketmaster’s Snowflake account did not have multi-factor authentication enabled. If MFA had been in place, the stolen credentials alone would not have been sufficient to access the account. The attacker had a valid username and password. Without MFA, that was all they needed.
Snowflake confirmed that the attack pattern was consistent across multiple customers who were similarly targeted during the same period. The common factor in every victim was the same: no MFA on their Snowflake accounts.
What Was Stolen
The 1.3TB of stolen data included:
- Full names
- Home addresses
- Email addresses
- Phone numbers
- Order histories dating back years
- Partial payment card information including card numbers and expiration dates
- Encrypted credit card data
560 million customer records. At that scale, the breach ranks among the largest in history by number of affected individuals.
The Three Core Failures
Failure 1: No MFA on a System Containing 560 Million Customer Records
This is the most important lesson from the Ticketmaster breach. A cloud account storing the personal data of 560 million people had no multi-factor authentication.
MFA is not optional. It is the single most impactful security control available. Microsoft’s data shows that MFA blocks 99% of automated credential attacks. Stolen credentials with MFA enabled are nearly useless to an attacker. Stolen credentials without MFA are a direct path into your systems.
The credentials used to access Ticketmaster’s Snowflake account were likely stolen months before the breach through infostealer malware. MFA would have stopped the attack even after credentials were compromised.
Failure 2: Inadequate Third-Party Vendor Security Management
Ticketmaster stored 1.3TB of customer data with a third-party vendor. The question every organisation should ask about every vendor handling their data is: what security controls does this vendor require, and what controls do we apply to our access of their systems?
Ticketmaster’s Snowflake account was a business asset containing some of the most sensitive customer data in their possession. The security applied to it should have reflected that sensitivity.
Third-party risk management means more than signing a contract with a vendor. It means actively managing security controls across every system where your data lives, regardless of whether that system belongs to you or a vendor.
29% of all data breaches involve third-party attacks. The Ticketmaster breach is one of the clearest examples of why this number is significant.
Failure 3: Slow Breach Notification
Ticketmaster detected unauthorised activity on May 20. They publicly confirmed the breach on May 29. Customer notifications began in late June. That is approximately six weeks between detection and customer notification.
Under GDPR, organisations must notify supervisory authorities within 72 hours of becoming aware of a breach. Under the HIPAA Breach Notification Rule, affected individuals must be notified within 60 days of discovery. Many US states have their own notification timelines, several shorter than 60 days.
The delay in notification gave affected customers less time to take protective action. It also created legal exposure across multiple regulatory frameworks. Plaintiffs in class action lawsuits specifically cite the delayed notification as evidence of negligence.
The Legal Consequences
Multiple class action lawsuits are proceeding through US courts as of July 2026. Plaintiffs allege:
- Negligence in implementing adequate cybersecurity measures
- Failure to safeguard customer data entrusted to Ticketmaster
- Delayed breach notification that increased harm to affected customers
- Failure to implement basic security controls including MFA
Settlement negotiations are ongoing. Given the scale of the breach and the number of affected individuals, legal experts anticipate significant settlements.
Regulatory scrutiny continues in multiple jurisdictions. Australian authorities opened an investigation given the significant number of Australian customers affected. UK and EU regulators have also examined notification timelines under their respective data protection frameworks.
The lawsuit is also notable for naming Snowflake as a defendant alongside Ticketmaster and Live Nation. This reflects an emerging legal pattern: when third-party vendors are involved in data breaches, plaintiffs increasingly pursue both the organisation holding the customer relationship and the vendor that held the data.
What the Snowflake Connection Reveals About Cloud Security
The Ticketmaster breach was part of a wider pattern of attacks targeting Snowflake customers during the same period. Multiple organisations using Snowflake were targeted through the same method: stolen credentials used against accounts without MFA.
This reveals something important about cloud security that many organisations still get wrong.
Cloud providers like Snowflake operate on a shared responsibility model. Snowflake secures its own infrastructure. You secure your access to it, your data within it, and the credentials used to authenticate to it.
Snowflake did not fail. Ticketmaster failed to apply appropriate security controls to its Snowflake account. The cloud provider’s security being strong is irrelevant if the customer’s access credentials are compromised and no MFA is in place to block unauthorised use of those credentials.
For a full breakdown of cloud security shared responsibility and compliance requirements, see our Cloud Security Compliance guide.
What Your Business Should Do Differently
The Ticketmaster breach is not a cautionary tale about sophisticated nation-state attackers or novel zero-day exploits. It is a cautionary tale about missing basics applied at the wrong scale. Every lesson from it translates directly to businesses of any size.
Enable MFA on Every Cloud Account — Today
Start with the accounts that hold the most sensitive or largest volumes of data. Cloud storage, cloud databases, SaaS platforms, analytics tools. Every account that holds customer data or business-critical information needs MFA enabled.
Use an authenticator app rather than SMS where possible. SMS-based MFA can be bypassed through SIM swapping. Authenticator app codes cannot.
Audit Your Third-Party Vendors
Make a list of every third-party vendor that has access to your customer data or business-critical systems. For each one, answer three questions: what data do they hold? what security controls protect that data? what controls do we apply to our own access of their systems?
Vendor contracts are not security controls. A vendor saying they are SOC 2 certified is not the same as verifying that your specific account with that vendor has MFA enabled and access logs reviewed.
Implement Continuous Monitoring for Credential Threats
Infostealer malware specifically targets saved credentials in browsers, password managers, and applications. Employees visiting compromised websites or downloading malicious software can have credentials stolen without any obvious signs.
Monitor for credential exposure through tools like Have I Been Pwned for business or dedicated dark web monitoring services. When stolen credentials are detected, reset them immediately and audit what those credentials had access to.
Have a Tested Breach Notification Process
One of Ticketmaster’s most criticised failures was notification timing. Know your notification obligations before a breach occurs. Under GDPR: 72 hours to notify supervisory authorities. Under various US state laws: timelines vary from 30 to 90 days depending on the state and the data involved.
Have templates for customer notifications prepared. Know who needs to be notified, in what order, and within what timeframes. Assembling this under pressure during an active breach incident is far harder than preparing it in advance.
Review Access Permissions Regularly
The principle of least privilege applies directly to vendor accounts. If Ticketmaster’s Snowflake account had access limited to only the specific data needed for specific analytics functions, the blast radius of a credential compromise would have been smaller.
Every quarter, review who and what has access to your most sensitive systems. Remove permissions that are no longer needed. Tighten scopes where they are broader than necessary.
The Broader Context: Supply Chain and Third-Party Attacks Are Increasing
The Ticketmaster breach fits a pattern that has accelerated significantly. Attackers increasingly target not the large, well-defended organisations themselves but the smaller vendors and tools those organisations rely on.
29% of all data breaches now involve third-party attacks according to security research. The SolarWinds attack, the MOVEit attack, and now Ticketmaster all demonstrate that a compromise of a trusted third-party tool can give attackers access to dozens or hundreds of organisations simultaneously.
This is why third-party risk management has moved from a compliance checkbox to an operational security requirement. Your security is only as strong as the weakest link in your vendor chain.
For more on how to structure a third-party security programme within a broader cybersecurity framework, see our Cybersecurity Frameworks 2026 guide and our Cybersecurity for Small Businesses guide.
Final Verdict
The Ticketmaster breach did not require sophisticated attackers. It required stolen credentials and a missing MFA toggle.
560 million customers had their data exposed. Class action lawsuits continue two years later. Regulatory investigations span multiple continents. Settlement costs have yet to be finalised but will be significant.
The remediation cost for the controls that would have prevented this breach is negligible compared to the legal, regulatory, and reputational costs of the breach itself. Enabling MFA on a cloud account takes five minutes. The Ticketmaster breach will cost years to resolve.
If your organisation holds customer data in cloud systems, check one thing today: does every account that accesses that data have MFA enabled? If the answer is no for any of them, fix it before anything else.
Frequently Asked Questions
What happened in the Ticketmaster data breach?
In May 2024, hackers accessed a cloud database hosted by Snowflake that Ticketmaster used to store customer data. The attackers used stolen credentials to log in to Ticketmaster’s Snowflake account, which had no multi-factor authentication enabled. They stole 1.3TB of data containing personal information for approximately 560 million customers including names, addresses, phone numbers, email addresses, order histories, and partial payment card details.
How many people were affected by the Ticketmaster breach?
Approximately 560 million customers worldwide were affected. The stolen data totalled 1.3 terabytes, making it one of the largest data breaches in history by number of affected individuals.
Who was responsible for the Ticketmaster hack?
A hacker group called ShinyHunters claimed responsibility for the breach. They announced the attack in late May 2024 and attempted to sell the stolen data on dark web forums for $500,000. The attack exploited stolen credentials used against a Snowflake account that lacked multi-factor authentication.
Is there a Ticketmaster data breach lawsuit?
Yes. Multiple class action lawsuits are proceeding through US courts as of July 2026. Plaintiffs allege negligence, failure to implement adequate security measures, and delayed breach notification. Settlement negotiations are underway but no formal agreement has been reached. Snowflake has also been named as a defendant alongside Ticketmaster and Live Nation.
What should I do if I was affected by the Ticketmaster breach?
If you had a Ticketmaster account before May 2024, your data may have been compromised. Monitor your financial accounts and credit reports for unusual activity. Consider placing a credit freeze if you are concerned about identity theft. Change any passwords you used on Ticketmaster, particularly if you reused that password on other sites. Contact Ticketmaster’s dedicated breach hotline (1-800-653-1840) with questions about your specific account.
Could the Ticketmaster breach have been prevented?
Yes. Enabling multi-factor authentication on the Snowflake account that was compromised would have prevented the attack even after credentials were stolen. The attackers had valid usernames and passwords obtained through infostealer malware. MFA would have blocked their access. This is why MFA is consistently cited as the single most impactful security control available.
Facts about the Ticketmaster breach sourced from Live Nation SEC filing May 2024, Snowflake incident analysis, FBI IC3 public statements, and class action lawsuit court filings as of July 2026. PenPonder does not provide legal advice. Affected individuals should consult qualified counsel regarding their rights in any ongoing litigation.
