CVE-2025-61882: Critical Oracle E-Business Suite Zero-Day Under Active Exploitation

Overview

In August 2025, security researchers and multiple incident-response teams began tracking active exploitation of a critical zero-day vulnerability affecting Oracle E-Business Suite (EBS). Now assigned CVE-2025-61882, this flaw allows unauthenticated remote code execution (RCE) through a pre-authentication attack chain targeting the BI Publisher and Concurrent Processing components of Oracle EBS 12.2.x.

With a CVSS v3.1 score of 9.8 (Critical), CVE-2025-61882 ranks among the most severe Oracle vulnerabilities to date. The attack requires no valid credentials and can be launched directly over HTTP. Oracle confirmed the bug affects versions 12.2.3 through 12.2.14, and the company has issued an emergency security alert and patch outside the regular Critical Patch Update (CPU) cycle.

The discovery comes amid reports from CrowdStrike, Rapid7, and WatchTowr Labs linking the exploit to financially motivated threat actors associated with Cl0p and Graceful Spider. Exploitation has been observed in enterprise environments as early as August 9, 2025.

How It Works

CVE-2025-61882 is not a single coding error - it’s a multi-stage exploit chain that abuses several weaknesses within the Oracle EBS architecture to achieve full system compromise.

The sequence typically begins with a Server-Side Request Forgery (SSRF) that coerces the application into fetching attacker-controlled resources. By abusing parameters in servlets such as /OA_HTML/SyncServlet and /OA_HTML/RF.jsp, an attacker can instruct the EBS server to connect outbound and retrieve a malicious XSLT template.

The second stage exploits CRLF injection and HTTP connection reuse, allowing manipulation of HTTP headers and bypassing authentication boundaries. Once the malicious XSLT template is processed by Oracle’s BI Publisher engine, it triggers arbitrary Java execution through the XSLT javax.script.ScriptEngine interface. At this point, the attacker can invoke Runtime.getRuntime().exec() to execute operating-system commands directly from the EBS application server.

In practical terms, the exploit chain flows like this: the attacker sends a crafted POST request to /OA_HTML/SyncServlet, embedding a reference to an external payload hosted on their own server; the Oracle EBS instance retrieves and parses the attacker’s template via SSRF; within the template, embedded JavaScript or XSLT code invokes native Java APIs, leading to arbitrary command execution; the attacker uploads a secondary loader or web shell (often a modified .jsp file) to maintain persistence and move laterally across the environment.

This method abuses legitimate Oracle EBS features - template previewing, XSLT rendering, and concurrent processing—so the activity often blends with normal system operations. Because the attack happens before authentication, it completely bypasses Oracle Access Manager or SSO controls.

Risks

The consequences of exploitation are severe. Once code execution is achieved, attackers gain the same privileges as the application-tier process owner, typically the applmgr account. From there, they can deploy additional payloads, access sensitive financial data, exfiltrate credentials, or pivot into connected systems such as Oracle Database or WebLogic Server.

Oracle EBS environments often contain payroll, supply-chain, and HR modules; compromise of these systems can expose vast amounts of confidential business information. In multiple cases analyzed by Rapid7, attackers deployed PowerShell-based downloaders and ransomware droppers immediately after achieving shell access.

Because the exploit chain uses outbound HTTP requests, defenders may see traffic from EBS servers to unfamiliar external IPs - a strong indicator of compromise. CrowdStrike reports that in several breaches, outbound connections were established to 185[.]181[.]60[.]11 and 200[.]107[.]207[.]26, both linked to known Cl0p infrastructure.

CISA has since added CVE-2025-61882 to its Known Exploited Vulnerabilities (KEV) catalog, requiring U.S. federal agencies to patch immediately. Oracle’s own telemetry confirms exploitation in at least four geographic regions across government, finance, and manufacturing verticals.

Real-Life Example Usage

In a campaign disclosed by CrowdStrike Falcon OverWatch, the threat group Graceful Spider (affiliated with Cl0p) targeted exposed Oracle EBS servers belonging to manufacturing and logistics firms. Attackers initiated a wave of POST requests to /OA_HTML/SyncServlet, each containing an obfuscated base64 string that resolved to an external URL hosting a malicious XSLT file named invoice_template.xsl.

Once executed, the payload opened a reverse shell back to the attacker’s command-and-control (C2) server. For persistence, the intruders planted modified Java classes - FileUtils.java and Log4jConfigQpgsubFilter.java - inside the EBS application’s /OA_HTML directory. They then compressed selected financial documents and uploaded them via HTTPS to a remote C2.

In one confirmed case, the attackers used the foothold to exfiltrate Oracle DB credentials and pivot laterally to an internal Windows Domain Controller, eventually deploying ransomware across the environment. The dwell time before detection was less than 48 hours, underscoring how quickly this exploit can escalate into a full-scale breach.

The initial detection signal came from egress logs: the EBS host initiated TLS sessions to unfamiliar IPs shortly after the template preview operation.

Recommendations

Oracle has released an out-of-band security alert and patch for CVE-2025-61882. Administrators should prioritize remediation without delay.

Patch Immediately. Apply Oracle’s patch set for EBS 12.2.3–12.2.14 and ensure prerequisite CPUs are installed (October 2023 CPU or newer). Restart the application tier after deployment to clear in-memory classes that may have been tampered with.

Verify Compromise Indicators. Search web server logs for suspicious access to /OA_HTML/SyncServlet, /OA_HTML/OA.jsp, and /OA_HTML/RF.jsp. Review outbound HTTP connections from EBS servers to unapproved domains. Scan for known file hashes associated with the exploit (exp.py, server.py, or related web shells).

Restrict Exposure. Oracle EBS should not be directly internet-facing. Place the application behind a VPN or reverse proxy, and apply WAF rules to detect anomalies in BI Publisher and XSLT processing.

Harden the Environment. Disable unused servlet endpoints. Apply strict egress filters to prevent outbound requests from the application tier. Rotate credentials for EBS users and database accounts if compromise is suspected.

Monitor and Respond. Implement deep visibility into EBS application logs, Java process creation, and network flows. SIEM rules should flag XSLT imports or outbound connections initiated by Oracle application servers. If exploitation is confirmed, isolate affected systems and engage IR teams immediately.