Beginning September 29, 2025, executives at numerous organizations received extortion emails claiming attackers had stolen data from their Oracle E-Business Suite (EBS) environments. Google initially said it could not verify the claims. Later analysis by Google Threat Intelligence Group (GTIG) and Mandiant found genuine exploitation of multiple customer EBS environments and evidence of significant data theft in some cases.
That does not mean Oracle’s corporate network was breached, or that every email recipient was compromised. The incident involved attacks against individual organizations’ EBS deployments and should be handled as a possible data breach until forensic review establishes otherwise.
What happened
Investigators observed suspicious activity targeting Oracle EBS environments as early as July 10, 2025. Google later identified an exploitation chain involving the EBS SyncServlet component in August. In some cases, attackers allegedly accessed files and exfiltrated data.
On September 29, the campaign escalated into executive-facing extortion. Messages sent from hundreds, and possibly thousands, of compromised third-party email accounts claimed that the recipients’ EBS data had been stolen and threatened publication unless the organization negotiated and paid.
Recommended Free Tools
GTIG described multiple exploitation chains, including activity involving /OA_HTML/configurator/UiServlet, /OA_HTML/SyncServlet, and malicious templates stored in the EBS database. Oracle issued emergency patches on October 4 and October 11 addressing CVE-2025-61882 and CVE-2025-61884. Oracle’s July 2025 Critical Patch Update had already listed nine EBS security patches, including three remotely exploitable without authentication.
Because investigators observed more than one chain, it is inaccurate to reduce the entire campaign to a single “Oracle zero-day.” GTIG also said it could not confidently map every intrusion to one vulnerability.
Were the extortion emails real?
The emails were initially unverified, but later investigation found real exploitation of Oracle EBS environments and evidence that data was stolen from at least some victims. That is a materially different conclusion from saying every email was genuine.
Some messages reportedly included legitimate file listings from victim EBS environments, with data dating back to mid-August 2025. Recipients should treat accurate internal filenames, EBS module references, or nonpublic data samples as leads for investigation—not as a substitute for forensic confirmation.
Claims are weaker when messages contain generic language, recycled screenshots, public information, incorrect product terminology, or no independently verifiable sample. Neither a convincing email nor a suspiciously generic one proves what happened.
At the time of GTIG’s October 9 report, investigators had not observed victims from this campaign on the CL0P leak site. That was a time-specific observation, not proof that no data had been stolen or that publication would not occur later.
What the emails said
The messages claimed that sensitive Oracle EBS documents had been exfiltrated and used contact addresses associated with the CL0P data-leak site. The campaign reportedly used addresses linked to pubstorm.com and pubstorm.net, while demands were often expected to follow after an authorized negotiator made contact.
Reported ransom demands ranged from seven- or eight-figure amounts. One demand reportedly reached $50 million, according to figures attributed to Halcyon and reported by Reuters-linked coverage. That was not a standard price or a confirmed demand for every recipient.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchSending messages from compromised legitimate accounts can make them appear more credible and evade ordinary spam controls. It also means blocking one sender address is unlikely to stop the campaign.
Was Oracle itself breached?
The available evidence concerns compromises of multiple Oracle EBS customer environments. It does not establish a breach of Oracle’s corporate network or one centralized “Oracle data breach.”
Oracle E-Business Suite is an enterprise software suite used for functions such as financials, procurement, human resources, customer information, and related business operations. The risk to an organization depends on its EBS release, internet exposure, installed components, patch status, supporting Oracle Database and Fusion Middleware versions, and access controls.
Do not automatically combine this incident with activity involving other Oracle products:
- Oracle EBS is a distinct enterprise suite, commonly operated in customer-controlled or customer-managed environments.
- Oracle Fusion Cloud Applications use a different cloud application and deployment model.
- Oracle PeopleSoft is a separate product family.
- Oracle Database may support EBS, but a database vulnerability is not synonymous with an EBS compromise.
A separate Google report in 2026 described a PeopleSoft campaign attributed to UNC6240/ShinyHunters. That activity should not be merged with the 2025 EBS campaign.
Was this ransomware?
It was primarily data-theft extortion, not conventional ransomware centered on encrypting systems. The cited reporting does not establish that encryption or a widespread operational outage was the defining action.
That distinction does not make the incident less serious. Stolen payroll records, tax identifiers, customer information, financial documents, credentials, or integration data can create privacy, fraud, regulatory, contractual, and reputational consequences even when applications continue operating normally.
What data could be exposed?
The answer depends on the organization’s EBS modules and configuration. Potential categories include:
- employee, payroll, and benefits information;
- names, addresses, contact details, and tax identifiers;
- customer and supplier records;
- financial, procurement, and internal business documents;
- credentials, tokens, and integration information accessible through the environment.
A Washington Post breach-notification filing provides one documented example. The organization said attackers accessed and acquired certain information between July 10 and August 22, 2025, including names and Social Security numbers or tax IDs. That is evidence about one victim’s findings—not proof that the same data was exposed at every EBS customer.
What an organization should do after receiving an email
- Preserve the message. Save the original email, full headers, attachments, and relevant mailbox records. Do not delete or alter evidence.
- Do not click links or open attachments. Do not reply from the executive’s normal mailbox.
- Escalate through the right channels. Notify security leadership, legal counsel, the incident-response lead, cyber insurer, and an approved DFIR or extortion-negotiation provider where appropriate.
- Contact Oracle Support. Confirm the exact EBS release, installed components, patch status, and applicable emergency patches.
- Identify exposed systems. Inventory internet-facing EBS servers, web tiers, databases, middleware, remote-access paths, and third-party integrations.
- Patch urgently. Patching limits additional exploitation but does not determine what attackers already accessed.
- Preserve logs. Retain EBS application logs, web and Java logs, database audit records, proxy and firewall data, identity logs, endpoint telemetry, and outbound-network records before routine retention overwrites them.
- Investigate access and exfiltration. Look beyond malware and persistence. A data theft incident may leave limited endpoint evidence while appearing in application, database, memory, or network telemetry.
- Review privileged access. Reset credentials and investigate administrator, service, integration, and cloud-connected accounts if compromise is suspected.
- Assess obligations. Counsel should evaluate privacy and regulatory notifications, contractual duties, securities or board reporting, insurance requirements, sanctions rules, and law-enforcement coordination.
Organizations should not publicly confirm the email prematurely, assume it is fake because systems are functioning, or assume it is genuine solely because it contains an internal filename.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Technical hunting guidance
Google recommended database hunting, restricting unnecessary outbound access, monitoring suspicious EBS endpoints, and memory forensics for Java processes. As an investigative starting point, administrators can review recently created or modified templates:
SELECT * FROM XDO_TEMPLATES_B ORDER BY CREATION_DATE DESC;
SELECT * FROM XDO_LOBS ORDER BY CREATION_DATE DESC;Investigate unexpected templates whose TEMPLATE_CODE begins with TMP or DEF, and inspect associated LOB_CODE content. Do not immediately delete suspicious records; preserve them under the organization’s evidence-handling process.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Review unusual requests involving:
/OA_HTML/configurator/UiServlet
/OA_HTML/SyncServlet
/OA_HTML/OA.jsp?page=/oracle/apps/xdo/oa/template/webui/TemplatePreviewPG...The TemplatePreviewPG pattern is especially suspicious when TemplateCode begins with TMP or DEF. IP addresses and command-and-control indicators should be checked against current GTIG intelligence before becoming permanent blocking rules.
Why the campaign matters
Mass exploitation of internet-facing enterprise applications gives attackers access to highly concentrated business data. Unlike an attack that encrypts endpoints, data-theft extortion can remain invisible to employees and customers until the demand arrives.
The delay between observed access in July and executive emails in late September also illustrates why patching alone is not an incident investigation. A fix may close the entry point while leaving unanswered questions about historical access, database changes, credentials, and outbound transfers.
What remains unknown
- the definitive number of compromised EBS environments;
- whether every email recipient was actually breached;
- the complete set of stolen data;
- which exploit chain and vulnerability corresponded to each intrusion;
- the identity of the actor behind the campaign;
- whether and when additional victim data was published.
The attackers used the CL0P/Clop brand and contact infrastructure associated with its leak site. Google also noted that one compromised sending account had previously been used by FIN11. Those facts are attribution clues, not conclusive proof that one specific group conducted every intrusion; GTIG did not formally attribute the campaign to a particular threat actor.
If an executive receives one of these emails
- Preserve the email and full headers.
- Do not click, open, reply, or negotiate independently.
- Notify security, legal counsel, incident response, and the cyber insurer.
- Begin EBS, web-tier, database, identity, memory, and network review.
- Do not equate normal operations with no breach.
- Do not equate a convincing internal filename with confirmed compromise.
For the primary technical timeline and indicators, consult Google’s GTIG/Mandiant analysis. For the initial reporting and uncertainty around the claims, see TechCrunch’s account.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
